Ssh daemon Sshd daemon это программа

Ssh daemon

Sshd daemon это программа, которая слушает сетевые подключения клиентов ssh, управляет авторизацией и выполняет запрошенную команду. Он имеет один основной файл конфигурации /etc/ssh/sshd_config и специальный файл, содержащий ключ, используемый при авторизации и шифровании. Каждый компьютер и каждый пользователь имеет собственный ключ.

Утилита ssh-keygen генерирует случайные ключи. Это обычно используется один раз при установке для генерации главного ключа, который администратор системы обычно хранит в файле /etc/ssh/ssh_host_key. Ключи могут иметь длину 512 бит или больше. По умолчанию ssh-keygen генерирует ключи длиной 1024 бита, и большинство людей использует значение по умолчанию. Чтобы генерировать ключ, вызовите команду ssh-keygen:

# ssh-keygen -f /etc/ssh/ssh_host_key

Вас спросят о фразе-пароле. Но ключи хостов такую фразу использовать не должны, так что оставьте ее пустой и нажмите Enter. Вывод программы будет выглядеть примерно так:

Generating RSA keys: ......oooooO...............................oooooO Key generation complete. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /etc/ssh/ssh_host_key Your public key has been saved in /etc/ssh/ssh_host_key.pub The key fingerprint is: 1024 3a:14:78:8e:5a:a3:6b:bc:b0:69:10:23:b7:d8:56:82 root@moria

В конце сказано, что два файла были созданы. Первый называется секретным ключом, и должен быть сохранен в тайне. Он попал в файл /etc/ssh/ssh_host_key. Второй называется публичным ключом и должен распространяться. Он хранится в файле /etc/ssh/ssh_host_key.pub.

Теперь нужно создать файл конфигурации. Пакет ssh очень мощный, и файл конфигурации может содержать много параметров. Следующий код показывает безопасный и минимальный файл конфигурации для sshd. Остальные опции детально описаны на man-странице sshd(8):

# /etc/ssh/sshd_config # The IP adddresses to listen for connections on. 0.0.0.0 means all # local addresses. ListenAddress 0.0.0.0 # The TCP port to listen for connections on. The default is 22. Port 22 # The name of the host key file. HostKey /etc/ssh/ssh_host_key # The length of the key in bits. ServerKeyBits 1024 # Should we allow root logins via ssh? PermitRootLogin no # Should the ssh daemon check users' home directory and files permissions? # are safe before allowing login? StrictModes yes

# Should we allow old ~/.rhosts and /etc/hosts.equiv authentication method? RhostsAuthentication no # Should we allow pure RSA authentication? RSAAuthentication yes # Should we allow password authentication? PasswordAuthentication yes # Should we allow /etc/hosts.equiv combined with RSA host authentication? RhostsRSAAuthentication no # Should we ignore ~/.rhosts files? IgnoreRhosts yes # Should we allow logins to accounts with empty passwords? PermitEmptyPasswords no

Очень важно правильно задать права доступа к файлу настроек. Используйте следующие команды для их задания:

# chown -R root:root /etc/ssh # chmod 755 /etc/ssh # chmod 600 /etc/ssh/ssh_host_key # chmod 644 /etc/ssh/ssh_host_key.pub # chmod 644 /etc/ssh/sshd_config

Заключительная стадия настройки sshd daemon это его запуск. Следует создать для него rc-файл или вписать вызов в уже существующий, чтобы сервис автоматически вызывался при начальной загрузке. Daemon выполняется автономно и не требует записи в файле /etc/inetd.conf. Он должен быть выполнен от имени пользователя root. Синтаксис очень прост:

/usr/sbin/sshd

sshd автоматически переходит в фоновый режим. Теперь он готов к приему соединений по протоколу ssh.

Стандарт MIME, или в нотации Internet...

Поле версии указывается в заголовке почтового сообщения и позволяет определить программе рассылки почты, что сообщение подготовлено в стандарте MIME. Формат поля выглядит как:

MIME-Version: 1.0

Поле версии указывается в общем заголовке почтового сообщения и относится ко всему сообщению целиком. Здесь уместно отметить, что в отличие от стандарта RFC822, стандарт MIME позволяет перемешивать поля заголовка сообщения с телом сообщения. Поэтому все поля делятся на два класса: общие поля заголовка, которые записываются в начале почтового сообщения и частные поля заголовка, которые относятся только к отдельным частям составного сообщения и записываются перед ними.

Стандартная база Linux Обширное

Каждый дистрибутив обеспечивает некоторые основные библиотеки, инструментальные средства конфигурации, прикладные программы системы и файлы конфигурации. К сожалению, различия в их версиях, именах и расположениях делают очень трудным выяснение вопроса, где и что в данной конкретной системе. Это делает трудным разработку двоичных программ, которые будут работать надежно на всех дистрибутивных базах Linux.

Чтобы помочь преодолеть эту проблему, создан новый проект "Стандартная база Linux" (Linux Standard Base). Его задача описать некую стандартную базу. Если разработчик ориентируется на нее, его программа будет корректно работать во всех дистрибутивах с поддержкой стандарта.

Подробности можно найти на соответствующем web-сайте: http://www.linuxbase.org.

Стандарты файловой системы В прошлом

Чтобы улучшать эту ситуацию, в августе 1993 несколько энтузиастов сформировали Группу по стандартизации файловой системы Linux (Linux File System Standard Group, FSSTND). После шести месяцев обсуждения, группа создала проект, который представляет собой последовательную структуру файловой системы, и определяет расположение наиболее существенных программ и главных файлов конфигурации.

Этот стандарт, как предполагалось, был поддержан основными дистрибутивами и пакетами Linux. Но принять-то стандарт приняли, а вот пунктуально ему следуют не так уж часто... В этой книге я предполагаю, что любые обсуждаемые файлы находятся там, где им предписано стандартом. Альтернативные расположения будут упомянуты только, когда имеется давняя традиция, которая противоречит этой спецификации.

Linux FSSTND продолжает развиваться, но в 1997 году у него появился конкурент: стандарт файловой иерархии Linux (Linux File Hierarchy Standard, FHS). FHS учитывает проблемы мультиархитектурных пакетов, чего FSSTND не делал. FHS может быть получен из документационного каталога Linux на всех основных FTP-сайтах Linux или с домашнего сайта http://www.pathname.com/fhs. Daniel Quinlan, координатор группы FHS, доступен как quinlan@transmeta.com.

Старение статей

Когда статьи принимаются сервером, они сохраняются на диске. Статьи должны быть доступными пользователям некоторое время. Но крупный сервер очень требователен к месту на диске. Для эффективного использования диска, надо удалять периодически устаревшие статьи. Можно это автоматизировать, что называется старение статей (article expiration). INN обеспечивает средства автоматического удаления старых статей.
Старение статей

Статическая IPXмаршрутизация Использование ipx_route

Имеются случаи, когда мы могли бы поставить жесткий IPX-маршрут. Точно как с IP, мы можем делать это с IPX. Команда ipx_route пишет маршрут в таблицы IPX-маршрутизации. Синтаксис очень прост (IPX не поддерживает множественные подсети):

# ipx_route add 203a41bc 31a10103 00002a02b102

Показанная команда добавила бы маршрут к удаленной IPX-сети 203a41bc через маршрутизатор на нашей локальной сети 31a10103 с узловым адресом 00002a02b102.
Статическая IPX-маршрутизация. Использование ipx_route

# ipx_route add 203a41bc 31a10103 00002a02b102

Показанная команда добавила бы маршрут к удаленной IPX-сети 203a41bc через маршрутизатор на нашей локальной сети 31a10103 с узловым адресом 00002a02b102.

Вы можете находить адрес узла маршрутизатора командой tcpdump с параметром -e, чтобы отобразить уровень связи в заголовках и найти трафик от маршрутизатора. Если маршрутизатор Linux-машина, Вы можете просто использовать команду ifconfig, чтобы отобразить это.

Вы можете удалять маршрут, используя команду ipx_route:

# ipx_route del 203a41bc

Вы можете просмотреть список маршрутов, которые являются активными в ядре, просмотром файла /proc/net/ipx_route. Наша таблица маршрутизации пока выглядит следующим образом:

# cat ipx_route Network Router_Net Router_Node 203A41BC 31A10103 00002a02b102 31A10103 Directly Connected

Маршрут к 31A10103 был автоматически создан, когда мы конфигурировали интерфейс IPX. Каждая из наших локальных сетей будет представляться в /proc/net/ipx_route подобной записью. Естественно, если наша машина должна действовать как маршрутизатор, ей будет нужно по крайней мере два интерфейса.

Режимы Linux Slip

Таблица 7-1. Режимы Linux Slip

Режим

Описание slip Обычный SLIP. cslip Сжатый SLIP (Van Jacobsen header compression). slip6 SLIP с шестибитным кодированием. Метод кодирования похож на применяемый программой uuencode и переводит пакеты SLIP в печатаемые символы ASCII. Удобно, если линия не способна передавать восемь бит. cslip6 Сжатый SLIP (Van Jacobsen header compression) с шестибитным кодированием. adaptive Выясняет параметры удаленной машины и устанавливает у себя такие же.

Заметьте, что Вы обязаны использовать такое же оформление, какое имеет удаленная машина. Например, если сервер cowslip использует CSLIP, Вы должны использовать его же. Симптомы рассогласования будут такие, что связь просто не работает. Один способ избежать этой неприятности: использовать adaptive SLIP.

Фактически, slattach позволяет Вам включить не только SLIP, но и другие протоколы, которые используют последовательную линию, как PPP или KISS (другой протокол, используемый в ham radio). Подробно это рассмотрено на man-странице slattach(8).

После передачи линии SLIP драйверу, Вы должны сконфигурировать сетевой интерфейс. Снова используются команды ifconfig и route. Предположим, что с машины vlager Вы соединились с сервером cowslip. Тогда Вы должны выполнить:

# ifconfig sl0 vlager-slip pointopoint cowslip # route add cowslip # route add default gw cowslip

Первая команда конфигурирует интерфейс как связь point-to-point с cowslip, в то время как вторая и третья команды добавляют маршрут к cowslip и задают маршрут по умолчанию, используемый cowslip как шлюз.

Два замечания относительно ifconfig: опция pointopoint, которая определяет адрес удаленной машины в соединении типа point-to-point, и использование vlager-slip как адреса локального SLIP-интерфейса.

Я упомянул, что Вы можете использовать тот же самый адрес, который назначили интерфейсу Ethernet машины vlager и для связи по SLIP. В этом случае, vlager-slip может быть псевдонимом для адреса 172.16.1.1. Однако, также возможно, что Вы должны использовать совсем другой адрес для SLIP. Один такой случай: Ваша сеть использует незарегистрированный сетевой IP адрес (для частных сетей), как Brewery. Это будет подробно рассмотрено чуть позже, а пока будем всегда использовать vlager-slip, чтобы обратиться к адресу локального интерфейса SLIP.

При завершении SLIP-связи Вы сначала должны удалить все маршруты cowslip, используя route c опцией del, убрать интерфейс и передать slattach сигнал hangup:

# route del default # route del cowslip # ifconfig sl0 down # kill -HUP 516

Здесь 516 надо заменить на process id (находится в списке, выводимом командой ps ax) процесса slattach.

Поля записей файла /etc/diphosts

Таблица 7-2. Поля записей файла /etc/diphosts

Поле Описание

user

Имя пользователя, по которому dip ищет запись для вошедшего в систему пользователя.

password Дополнительный пароль для защиты соединения. Здесь пароль хранится в зашифрованном виде (как в файле /etc/passwd). Если он указан, diplogin спросит у пользователя второй пароль после его входа в систему, но до предоставления ему сервиса SLIP. Этот пароль используется в дополнение к паролю для входа в систему. rem-addr Адрес, назначаемый удаленной машине. Можно вместо адреса задать имя, если оно есть у сервера имен, или IP-адрес. loc-addr IP-адрес для этого конца SLIP-связи. Тоже можно задать как имя, так и адрес. netmask Маска подсети для маршрутизации. Маска не применяется непосредственно для SLIP-связи, но используется в комбинации с rem-addr для построения маршрута к удаленному сайту. comments Просто текст для пояснения записи в /etc/diphosts. Программно не обрабатывается. protocol Задает протокол или line discipline для этой конкретной связи. Значения совпадают со значениями для параметра -p в команде slattach. MTU Задает максимальную длину пакетов при передаче по этой связи. Любой пакет, размером больше этого значения, будет фрагментирован (поделен на пакеты с длиной в пределах MTU).

Пример записи для dent:

dent::dent.beta.com:vbrew.com:255.255.255.0:Arthur Dent:CSLIP,296

Итак, пользователю dent будет предоставлен SLIP-сервис без запроса дополнительного пароля. Он получит IP-адрес, связанный с именем dent.beta.com с маской сети 255.255.255.0. Его маршрут по умолчанию должен быть нацелен на IP-адрес имени vbrew.com, и он должен использовать протокол CSLIP с длиной MTU в 296 байт.

Когда dent входит в систему, diplogin получает сведения о нем из файла diphosts. Если второе поле содержит некое значение, diplogin спросит внешний пароль соединения ("external security password"). Строка, введеная пользователем, будет зашифрована, а результат сверен с паролем в diphosts. Если не совпало, соединение будет запрещено. Если поле пароля хранит строку s/key, и dip откомпилирован с поддержкой S/Key, выполняется авторизация по этому алгоритму. S/Key описан в документации на dip.

После успешного входа diplogin настроит протокол линии, а также интерфейс и маршрутизацию. Когда пользователь отсоединится, и модем положит трубку, diplogin вернет линию в нормальное состояние.

diplogin требует привилегий администратора. Есои dip не объявлен как setuid к пользователю root, следует сделать diplogin отдельной копией dip вместо простой ссылки. Безопасней объявить diplogin как setuid без изменения статуса dip.

Распространенные значения бит сетевой маски

Таблица 9-1. Распространенные значения бит сетевой маски

Сетевая маска Биты

255.0.0.0	8
255.255.0.0	16
255.255.255.0	24
255.255.255.128	25
255.255.255.192	26
255.255.255.224	27
255.255.255.240	28
255.255.255.248	29
255.255.255.252	30

ipfwadm имеет одну полезную возможность, которая упрощает создание правил. Это опция -b, которая создает двунаправленное правило. Эта опция позволяет сворачивать команды для двух правил в одну:

# ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b

Типы пакетов ICMP

Таблица 9-2. Типы пакетов ICMP

Номер типа Обозначение iptables Описание

0	echo-reply	Echo Reply
3	destination-unreachable	Destination Unreachable
4	source-quench	Source Quench
5	redirect	Redirect
8	echo-request	Echo Request
11	time-exceeded	Time Exceeded
12	parameter-problem	Parameter Problem
13	timestamp-request	Timestamp Request
14	timestamp-reply	Timestamp Reply
15	none	Information Request
16	none	Information Reply
17	address-mask-request	Address Mask Request
18	address-mask-reply	Address Mask Reply

Использование TOSбитов

Таблица 9-3. Использование TOS-битов

TOS ANDmask XORmask Рекомендуемое использование

Minimum Delay	0x01	0x10	ftp, telnet, ssh
Maximum Throughput	0x01	0x08	ftp-данные, www
Maximum Reliability	0x01	0x04	snmp, dns
Minimum Cost	0x01	0x02	nntp, smtp

Тестирование настроек Команда

sendmail поддерживает "режим адресного теста" (address test mode), который позволяет проверять конфигурацию и идентифицировать любые ошибки. В этом режиме работы sendmail вызывается из командной строки и запрашивает определения правил и почтовые адреса назначения. Затем sendmail обрабатывает адреса, используя определенные правила и показывая вывод каждого правила. Чтобы перейти в этот режим, вызовите sendmail с указанием параметра -bt:

# /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter >

Заданный по умолчанию файл конфигурации /etc/mail/sendmail.cf. Вы можете определять альтернативу параметром -C. Чтобы проверить конфигурацию, надо выбрать ряд адресов, чтобы обработать их по правилам доставки почты. Для иллюстрации используем более сложную настройку для UUCP (пример 18-2).

Сначала проверим, что sendmail способен доставить почте локальным пользователям в системе. В этих тестах мы ожидаем, что все адреса будут переписаны для локального почтового агента этой машины:

# /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter > 3,0 isaac rewrite: ruleset 3 input: isaac rewrite: ruleset 96 input: isaac rewrite: ruleset 96 returns: isaac rewrite: ruleset 3 returns: isaac rewrite: ruleset 0 input: isaac rewrite: ruleset 199 input: isaac rewrite: ruleset 199 returns: isaac rewrite: ruleset 98 input: isaac rewrite: ruleset 98 returns: isaac rewrite: ruleset 198 input: isaac rewrite: ruleset 198 returns: $# local $: isaac rewrite: ruleset 0 returns: $# local $: isaac

Этот вывод показывает нам, как sendmail обрабатывает почту, адресованную isaac на этой системе. Каждая строка показывает информацию, переданную правилу, или результат, полученный из его обработки. Мы сообщили sendmail, что надо использовать наборы правил 3 и 0, чтобы обработать адрес. По умолчанию вызывается именно набор 0, поэтому набор 3 был вызван в принудительном порядке. Последняя строка показывает, что набор 0 направляет почту пользователю isaac.

Теперь проверим почту, адресованную по SMTP адресу isaac@vstout.vbrew.com. Должен получиться тот же самый результат, что и в предыдущем примере:

# /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter > 3,0 isaac@vstout.vbrew.com rewrite: ruleset 3 input: isaac @ vstout . vbrew . com rewrite: ruleset 96 input: isaac < @ vstout . vbrew . com > rewrite: ruleset 96 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 3 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 0 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 199 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 98 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 98 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 198 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 198 returns: $# local $: isaac rewrite: ruleset 0 returns: $# local $: isaac

Тест прошел успешно. Теперь проверим хождение почты на тот же адрес, но в UUCP-формате vstout!isaac.

# /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter > 3,0 vstout!isaac rewrite: ruleset 3 input: vstout ! isaac rewrite: ruleset 96 input: isaac < @ vstout . UUCP > rewrite: ruleset 96 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 3 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 0 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 199 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 98 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 98 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 198 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 198 returns: $# local $: isaac rewrite: ruleset 0 returns: $# local $: isaac

Тоже работает. Эти тесты подтверждают, что любая полученная почта для локальных пользователей на этой машине будет правильно доставлена, независимо от того, как форматируется адрес. Если вы определили любые псевдонимы для машины, например, виртуальные хосты, Вы должны повторить эти тесты для каждого из имен, соответствующих данной машине.

Теперь проверим хождение почты на другие хосты в домене vbrew.com по протоколу SMTP:

# /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter > 3,0 isaac@vale.vbrew.com rewrite: ruleset 3 input: isaac @ vale . vbrew . com rewrite: ruleset 96 input: isaac < @ vale . vbrew . com > rewrite: ruleset 96 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 3 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 0 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 199 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 199 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 98 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 98 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 198 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 198 returns: $# smtp $@ vale . vbrew . com . / $: isaac < @ vale . vbrew . com . > rewrite: ruleset 0 returns: $# smtp $@ vale . vbrew . com . / $: isaac < @ vale . vbrew . com . >

Письмо по SMTP было перенаправлено на хост vale.vbrew.com пользователю isaac. Этот тест подтверждает, что определение LOCAL_NET_CONFIG работает правильно. Для хождения почты таким способом, имя машины должно быть корректно связано с IP-адресом через файл /etc/hosts или сервис DNS. Если адрес найден не будет, произойдет следующее:

# /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter > 3,0 isaac@vXXXX.vbrew.com rewrite: ruleset 3 input: isaac @ vXXXX . vbrew . com rewrite: ruleset 96 input: isaac < @ vXXXX . vbrew . com > vXXXX.vbrew.com: Name server timeout rewrite: ruleset 96 returns: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 3 returns: isaac < @ vXXXX . vbrew . com > == Ruleset 3,0 (3) status 75 rewrite: ruleset 0 input: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 199 input: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 199 returns: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 98 input: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 98 returns: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 198 input: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 95 input: < uucp-new : moria > isaac rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac

Здесь результат совсем иной. Сначала набор 3 вернул сообщение об ошибке, показывающее, что имя хоста не может быть корректно преобразовано в адрес. Теперь интеллектуальный хост должен обработать любую почту, которая является недоставляемой, а данное письмо к ней как раз относится. Почта попадет на интеллекуальный хост moria через транспорт uucp-new. Этот хост может быть информирован лучше и знать, что делать с такой почтой.

Наш заключительный тест гарантирует, что любая почта, адресованная компьютеру не внутри нашего домена, будет доставлена интеллектуальному хосту:

# /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter > 3,0 isaac@linux.org.au rewrite: ruleset 3 input: isaac @ linux . org . au rewrite: ruleset 96 input: isaac < @ linux . org . au > rewrite: ruleset 96 returns: isaac < @ linux . org . au . > rewrite: ruleset 3 returns: isaac < @ linux . org . au . > rewrite: ruleset 0 input: isaac < @ linux . org . au . > rewrite: ruleset 199 input: isaac < @ linux . org . au . > rewrite: ruleset 199 returns: isaac < @ linux . org . au . > rewrite: ruleset 98 input: isaac < @ linux . org . au . > rewrite: ruleset 98 returns: isaac < @ linux . org . au . > rewrite: ruleset 198 input: isaac < @ linux . org . au . > rewrite: ruleset 95 input: < uucp-new : moria > isaac rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac

Результаты этого теста указывают, что имя хоста преобразовано в адрес, но сообщение все равно пойдет на интеллектуальный хост. Это доказывает, что определение LOCAL_NET_CONFIG работает правильно.

Типы пакетов ICMP Каждая из команд

Типы пакетов ICMP

Каждая из команд конфигурации firewall позволяет Вам определять типы пакетов ICMP. В отличие от портов TCP и UDP, не имеется никакого удобного файла конфигурации, который перечисляет типы пакетов и их значения. Типы пакетов ICMP определены в RFC-1700 (Assigned Numbers RFC). Они также перечислены в одном из стандартных библиотечных файлов C. Файл /usr/include/netinet/ip_icmp.h, который принадлежит обычной библиотеке GNU и используется C-программистами при написании сетевого программного обеспечения, работающего с протоколом ICMP, также определяет типы пакетов ICMP. Для Вашего удобства я привожу их в таблице 9-2. Интерфейс команды iptables позволяет Вам определять типы ICMP по их именам, так что я укажу и эти имена. Позже они пригодятся.

Transmission Control Protocol

Но, конечно, посылка пакетов от одного хоста к другому это не все, если Вы вошли на quark. Вы хотите иметь надежную связь между Вашим процессом rlogin на erdos и процессом оболочки на quark. Таким образом, информация, посылаемая туда и обратно, должна быть разбита на пакеты отправителем и повторно собираться в поток приемником. Хотя это кажется тривиальным, здесь появляется несколько достаточно сложных задач.
Transmission Control Protocol

Очень важно знать об IP, что он ненадежен. Предположим, что десять людей на Вашем Ethernet начали загружать самый последний выпуск XFree86 с GMU FTP-сервера. Такая активность может оказаться слишком большой для того, чтобы gateway переварил ее, потому что он слишком медленный и ограничен количеством памяти. Теперь если Вы пошлете пакет с quark, sophus может не хватить места в буфере, и поэтому он не сможет отправить этот пакет. IP решает эту проблему, просто забывая про данный пакет. Пакет безвозвратно потерян. Таким образом, ответственность за целостность данных перекладывается на поддерживающие связь хосты.

Это происходит в соответствии c другим протоколом, TCP (Transmission Control Protocol), который надстраивается над IP для создания связи с проверкой целостности данных. Существенный плюс TCP то, что он использует IP. Это создает иллюзию простой связи между двумя процессами на Вашем хосте и отдаленной машине так, что Вы не заботитесь о том, как и по какому маршруту Ваши данные фактически путешествуют. A TCP создает дуплексную связь, позволяющую одновременно как посылать, так и получать информацию.

В TCP точки связи определяются IP-адресами хостов и номерами так называемых портов (port) на каждом из хостов. Порты служат для определения процесса, с которым устанавливается связь. Если обратится к примеру с номерами телефонов, то IP-адрес соответствует кодам городов, а номер порта местному номеру телефона.

В примере с rlogin приложение-клиент (rlogin) открывает порт на erdos и соединяется с портом 513 на quark , который прослушивает сервер rlogind. Таким образом и устанавливается TCP-связь. Используя эту связь, rlogind выполняет процедуру определения прав доступа и запускает оболочку. Стандартный ввод/вывод этой оболочки перенаправляются на TCP-связь, таким образом, все, набранное Вами в rlogin на Вашей машине, будет передано через TCP-поток на стандартный ввод оболочки.

Удаление группы

Удаление группы выполняется такой командой:

ctlinnd rmgroup group

Удаление группы

Удаление группы выполняется такой командой:

ctlinnd rmgroup group

Аргументы имеют смысл:

group

Имя удаляемой группы.

Эта команда удаляет группу из файла active, но не чистит каталоги новостей. Все статьи для этой группы будут устаревать в обычном порядке, но новые приниматься уже не будут.

Управление битами TOS Биты типа

Доступные классы обслуживания сети:

Minimum delay

Используется, когда время доставки пакета с исходного компьютера на компьютер адресата (время ожидания), наиболее важно. Провайдер выбирает быстрейший канал связи для доставки таких пакетов.

Maximum throughput

Используется, когда объем данных в любом периоде времени важен. Имеются много типов сетевых прикладных программ, для которых время ожидания не особенно важно, но сетевая производительность критична. Для таких пакетов рекомендуются каналы с хорошей пропускной способностью, например, спутниковые.

Maximum reliability

Используется, когда важно иметь некоторую уверенность что данные достигнут адресата без повторной передачи. IP-протокол может быть передан по большому числу основных сред передачи. В то время как SLIP и PPP хорошие для передачи обычных протоколы, они не столь надежны, как X.25 network. Для таких пакетов выбираются самые надежные каналы связи.

Minimum cost

Используется, когда важно минимизировать стоимость передачи данных. Аренда спутникового канала передачи вообще менее дорогостоящая, чем аренда оптоволоконного кабеля, так что провайдер может иметь разные каналы и направлять Ваш трафик по каналу подешевле.

Управление INN команда ctlinnd

Краткий обзор команд ctlinnd выводится по:

# ctlinnd -h

Здесь я рассмотрю наиболее важные опции настройки, за подробностями отсылаю Вас к man-странице на ctlinnd.

Управление почтовой очередью

Почтовая очередь хранится в каталоге /var/spool/mqueue. Программа sendmail обеспечивает средства показа форматируемого списка всех помещенных в очередь сообщений почты и их состояния.
Управление почтовой очередью

Команда /usr/bin/mailq ведет себя идентично:

# sendmail -bp

Вывод отображает message ID, размер, время помещения в очередь, кто послал письмо и сообщение, указывающее текущее состояние. Следующий пример показывает сообщение почты, увязшее в очереди с проблемой:

$ mailq Mail Queue (1 request) --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------ RAA00275 124 Wed Dec 9 17:47 root (host map: lookup (tao.linux.org.au): deferred) terry@tao.linux.org.au

Это сообщение все еще в очереди почты потому, что IP-адрес хоста назначения пока не нашелся.

Мы можем вынуждать sendmail начать обрабатывать очередь немедленно командой /usr/bin/runq.

Команда runq не производит вывода. sendmail начнет обрабатывать очередь почты в фоне.

Управление почтовыми псевдонимами

Псевдонимы почты мощное свойство, которое дает возможность письмам попадать в почтовые ящики, которые являются альтернативными именами для пользователей или процессов на компьютере адресата. Например, обычным явлением считается адрес для комментариев, связанных с сервером WWW, названный "webmaster". Часто нет пользователя, известного как "webmaster" на целевой машине, взамен него подставляется имя другого пользователя системы. Другое общее применение псевдонимов: списки рассылки. Здесь псевдоним направляет входящие сообщения серверу списка рассылки для обработки.
Управление почтовыми псевдонимами

Файл /etc/aliases обычно хранит псевдонимы. Пакет sendmail консультируется с этим файлом при определении, как обработать входящее сообщение почты. Если он находит запись в этом файле, соответствующую пользователю назначения в сообщении почты, он переназначает сообщение на нового получателя.

Есть три ситуации, которые связаны с использованием псевдонимов:

Псевдоним обеспечивает адрес для почты, направляемой одному или нескольким получателям.

Псевдоним может вызывать программу с сообщением почты в качестве ввода для этой программы.

Псевдоним может посылать почту в файл.

Все системы требуют псевдонимов для Postmaster и MAILER-DAEMON, для совместимости с ошибками различных описаний RFC.

Следует быть очень осторожным с программами, которым передается почта, поскольку sendmail выполняется с правами root.

Детали, относительно псевдонимов почты, могут быть найдены на man-странице aliases(5). Образец файла aliases показан в примере 18-4.

Управление Вашей системой В этой

Абсолютный минимум поддержки сводится к проверке файлов протоколов системы и программ в поисках сообщений об ошибках и необычных событиях. Часто это удобно делать с помощью скриптов, периодически запускаемых из cron. Дистрибутивы некоторых пакетов, например, inn или C-News имеют такие скрипты в готовом виде.

Вывод любой из задач cron должен быть отправлен по почте администратору. По умолчанию многие прикладные программы шлют отчеты об ошибках, статистику использования или резюме журнала пользователю root. Это имеет смысл только, если Вы часто работаете как root. Лучше переназначить почту root на Ваш логин, устанавливая псевдоним почты как описано в главе 19 или главе 18.

Как бы тщательно не был настроен сайт, что-то непременно произойдет. Следовательно, поддержание системы также означает поддержку адреса для жалоб пользователей. Обычно люди ожидают, что администратор системы может быть достигнут по e-mail по крайней мере как root, но имеются также другие адреса, которые обычно используются, чтобы достать (во всех смыслах) человека, ответственного за специфический аспект системы. Например, жалобы относительно конфигурации почты будут обычно адресованы postmaster, а проблемы с системой новостей могут быть сообщены newsmaster или usenet. Почта на hostmaster должна быть переназначена человеку, отвечающему за базисные сетевые услуги компьютера и обслуживание имен DNS, если Вы выполняете сервер имен.

User Datagram Protocol

Конечно, TCP не единственный протокол пользователя в сетях TCP/IP. Хоть он и подходит для приложений подобных rlogin, но он излишне надежен и не нужен для приложений типа NFS. Вместо него в них использует UDP (User Datagram Protocol). Подобно TCP, UDP также позволяет приложению-клиенту войти в контакт с сервером, обслуживающим определенный порт на удаленной машине, но он не устанавливает связь для этого. Вместо этого Вы можете использовать его, чтобы посылать отдельные пакеты к месту назначения.
User Datagram Protocol

Предположим, что Вы смонтировали директорию TeX с центрального NFS-сервера galois и хотите просмотреть документ, описывающий, как использовать LaTeX. Вы запускаете редактор, который сначала читает указанный файл. Однако, требуется слишком много времени, чтобы установить TCP-связь с galois, послать файл и повторять это снова. Вместо этого на запрос, посланный к galois, тот посылает файл в паре UDP-пакетов, что происходит гораздо быстрее. Однако, UDP не приспособлен для борьбы с потерей пакетов. Этим приходится заниматься NFS.

Установка CNews доступен в откомпилированном

sys

Файл sys управляет тем, какие группы новостей передаются и принимаются Вашим сайтом. Рассмотрен детально ниже.

active

Хранит указания по обработке статей в группах новостей.

organization

Имя Вашей организации. Например, "Virtual Brewery, Inc". На домашней машине введите "private site" или что-либо, что Вы находите приятным. Большинство людей не будет называть Ваш сайт правильно отконфигурированным, если Вы не настроили этот файл.

newsgroups

Этот файл представляет список всех групп с описанием (одна строка) для каждой из них. Эти описания часто используются программой чтения новостей при показе списка всех групп, на которые Вы подписаны.

mailname

Почтовое имя Вашего сервера, например, vbrew.com.

whoami

Имя Вашего сайта для целей новостей. Часто используется имя UUCP, например, vbrew.

explist

Вы должны редактировать этот файл, чтобы настроить время старения для групп новостей. Дисковое пространство может играть в этом важную роль.

Чтобы создать начальную иерархию новостных групп, получите файлы active и newsgroups с сайта, который передает Вам новости, и установите их в /etc/news. Объявите их принадлежащими пользователю news и задайте права доступа 644 командой chmod. Удалите все группы to.* из файла active и добавьте to.my-site, to.feed-site, junk и control. Группы to.* обычно используются для обмена ihave/sendme сообщениями, но Вы должны создать их независимо от того, планируете ли Вы использовать ihave/sendme или нет. Затем замените все номера статей во втором и третьем полях active, используя следующую команду:

# cp active active.old # sed 's/ [0-9]* [0-9]* / 0000000000 00001 /' active.old > active # rm active.old

Вторая команда вызывает sed, потоковый редактор в Unix. Этот вызов заменяет две строки цифр на строку нулей и строку 000001 соответственно.

В заключение, создайте каталог для хранения новостей и подкаталоги, используемые для входящих и исходящих новостей:

# cd /var/spool # mkdir news news/in.coming news/out.going news/out.master # chown -R news.news news # chmod -R 755 news

Если Вы используете программы чтения новостей из другого дистрибутива, а не из C-News, Вы можете обнаружить, что некоторые из них ожидают найти хранилище новостей в /usr/spool/news, а не в /var/spool/news. Если Ваш newsreader не находит статьи, создайте ссылку из /usr/spool/news в /var/spool/news:

# ln -sf /usr/spool/news /var/spool/news

Теперь Вы готовы получать новости. Обратите внимание, что Вы не должны создавать любые каталоги, отличные от показанных выше, потому что каждый раз, когда C-News получает статью от группы, для которой нет каталога, он создаст его автоматически при обработке статьи.

В частности это случается со всеми группами, в которых новости пересеклись. Через некоторое время Вы найдете в своем каталоге новостей подкаталоги для групп, на которые никогда не подписывались, например, alt.lang.teco. Вы можете предотвратить это удалением всех нежелательных групп из файла active или удаляя все пустые каталоги ниже /var/spool/news из какого-либо скрипта (исключение составляют каталоги out.going и in.coming).

C-News нуждается в пользователе, которому можно послать сообщения об ошибках и отчеты состояния. По умолчанию это usenet. Если Вы используете значение по умолчанию, Вы должны установить специальные права для него. Вы можете также отменять это поведение, устанавливая переменную среды NEWSMASTER в соответствующее имя. Это можно делать из списка заданий пользователя news для отложенного выполнения (crontab) перед запуском утилит администрирования. Можно установить и почтовый псевдоним, что подробно описано в главе 18 и главе 19.

При правке файла /etc/passwd проследите, чтобы каждый пользователь имел свое реальное имя в записи pw_gecos (это четвертое поле). Это вопрос сетевого этикета Usenet, который предписывает, чтобы реальное имя пользователя значилось в поле From: его статей.

Установка и конфигурирование ssh

OpenSSH свободная версия набора программ ssh. Linux-версия есть на http://violet.ibs.com.au/openssh и во многих дистрибутивах Linux. Здесь я не буду рассматривать компиляцию: подробные указания есть в пакете с исходными текстами. Если Вы можете установить программу из откомпилированных модулей, лучше всего это сделать.
Установка и конфигурирование ssh

Для работы ssh нужно два компонента: клиент ssh, которого Вы должны конфигурировать и выполнить на локальном компьютере, и ssh daemon, который должен работать на удаленном компьютер, к которому нужно подключиться.

Установка INN Перед настройкой

Дистрибутивы Linux некоторое время включали INN Version 1.4sec. Увы, эта версия имела две тонких проблемы защиты. Современные версии не имеют этих проблем, и большинство дистрибутивов включают откомпилированный INN Version 2 или старше.

Если Вам нужно откомпилировать INN лично, можете получить исходники с ftp.isc.org (каталог /isc/inn). Это требует, чтобы Вы редактировали файл конфигурации, который сообщает INN подробности относительно операционной системы и некоторых ее свойств.

Компилирование пакета довольно просто; имеется сценарий BUILD, который будет вести Вас через процесс. Архив с исходниками также содержит обширную документацию по тому, как устанавливать и конфигурировать INN.

После установки всех двоичных файлов могут потребоваться некоторые дополнительные настройки, чтобы связать INN с другими прикладными программами, которые могут обращаться к rnews или inews. UUCP, например, ожидает найти rnews в /usr/bin или /bin в то время, как INN устанавливает ее в /usr/lib/bin по умолчанию. Удостоверьтесь, что /usr/lib/bin находится в заданном по умолчанию пути поиска файлов, или что есть символические связи, указывающие на фактическое расположение команд rnews и inews.

Установка клиента NIS с GNU libc

Вашим первым шагом должно быть сообщение клиенту GNU libc NIS того, какой сервер использован для NIS, устанавливая это в файле конфигурации /etc/yp.conf. Очень простой типовой файл для сети может выглядеть следующим образом:

# yp.conf - YP configuration for GNU libc library. # ypserver vbardolino

Инструкция ypserver предписывает использовать хост, заданный как NIS-сервер для локального домена. В этом примере мы определили NIS-сервер как vbardolino. Конечно, соответствие IP-адреса машине vbardolino должно быть задано в файле hosts. Впрочем, можно использовать IP-адрес явно в качестве аргумента параметра server.

В форме, показанной в примере, команда ypserver сообщает ypbind, что нужно использовать заданный сервер, независимо от текущего домена NIS. Если Вы часто перемещаете свою машину между NIS-доменами, хорошо бы хранить информацию для нескольких доменов в файле yp.conf. Вы можете иметь информацию для различных NIS-доменов в одном файле yp.conf, конкретизируя с использованием команды domain. Например, можно переделать предыдущий типовой файл ноутбука:

# yp.conf - YP configuration for GNU libc library. # domain winery server vbardolino domain brewery server vstout

Это позволяет Вам использовать ноутбук в любом из двух доменов, просто задав нужный домен при загрузке командой domainname. NIS-клиент обратится к соответствующему серверу.

Имеется третья весьма полезная опция. Она учитывает случай, когда Вы не знаете имя или IP-адрес сервера, чтобы использовать его в настройках, но можете использовать фиксированный сервер в некоторых доменах. Измените свой файл настройки yp.conf так:

# yp.conf - YP configuration for GNU libc library. # domain winery server vbardolino domain brewery broadcast

Команда broadcast сообщает ypbind, что надо использовать любой сервер, который удалось найти для NIS-домена.

После создания этого базисного файла конфигурации и определения его как доступного на чтение всем, Вы должны выполнить ваш первый тест соединения с Вашим сервером. Выберите обрабатываемую сервером карту, например, hosts.byname и попробуйте ее получить командой ypcat:

# ypcat hosts.byname 172.16.2.2 vbeaujolais.vbrew.com vbeaujolais 172.16.2.3 vbardolino.vbrew.com vbardolino 172.16.1.1 vlager.vbrew.com vlager 172.16.2.1 vlager.vbrew.com vlager 172.16.1.2 vstout.vbrew.com vstout 172.16.1.3 vale.vbrew.com vale 172.16.2.4 vchianti.vbrew.com vchianti

Вывод, который Вы получаете, должен походить на показанный. Если Вы получаете сообщение об ошибке Can't bind to server which serves domain, то домен NIS не соответствует серверу, заданному в yp.conf, или сервер недоступен. В последнем случае удостоверьтесь, что ping для этого хоста выдает положительный результат, и что сервер NIS запущен. Вы можете проверить последний факт использованием rpcinfo, который должен произвести следующий вывод:

# rpcinfo -u serverhost ypserv program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting

Установка sendmail Агент передачи

Исходники sendmail доступны через анонимный FTP с ftp.sendmail.org.

Компиляция пакета очень проста, поскольку sendmail непосредственно поддерживает Linux на уровне исходного кода. Чтобы собрать пакет, надо скомандовать:

# cd /usr/local/src # tar xvfz sendmail.8.9.3.tar.gz # cd src # ./Build

Вам нужны права root, чтобы завершить установку. Для этого скомандуйте:

# cd obj.Linux.2.0.36.i586 # make install

Вы установили двоичные файлы sendmail в каталог /usr/sbin. Несколько символических связей к sendmail будут установлены в каталог /usr/bin. Мы будем говорить относительно этих связей, когда будем обсуждать общие задачи в управлении sendmail.

Установка сервера NNTP NNTP сервер

nntpd может быть сконфигурирован как автономный сервер, который запускается при начальной загрузке системы из rc или как daemon, управляемый inetd. В последнем случае Вы должны иметь следующую запись в /etc/inetd.conf:

nntp stream tcp nowait news /usr/etc/in.nntpd nntpd

Формат inetd.conf описан в главе 12. Если Вы конфигурируете nntpd как автономный сервер, удостоверьтеь, что любая такая строка в inetd.conf закомментирована. В любом случае Вы должны удостовериться, что имеется следующая строка в /etc/services:

nntp 119/tcp readnews untp # Network News Transfer Protocol

Чтобы временно сохранять любые входящие статьи, nntpd также нуждается в каталоге .tmp в spool-каталоге новостей. Вы должны создать его используя команды:

# mkdir /var/spool/news/.tmp # chown news.news /var/spool/news/.tmp

Установка TOSбитов с помощью iptables

Команда iptables позволяет Вам определять правила для сбора данных с заданными TOS-битами, используя параметр -m tos и устанавливать биты с помощью параметра -j TOS. Вы можете устанавливать TOS-биты только на правилах цепочек FORWARD и OUTPUT. Соответствие и установка происходит совершенно независимо. Вы можете конфигурировать много интересных правил. Например, Вы можете конфигурировать правило для отклонения пакетов с задаными TOS-битами или для установки TOS-битов в пакетах с некоего конкретного компьютера.
Установка TOS-битов с помощью iptables

В отличие от ipfwadm и ipchains , iptables использует более простой подход, явно определяя чему TOS-биты должны соответствовать, или какие TOS-биты должны быть установлены. Для битов заданы имена, что куда лучше запоминания их числовых масок

Синтаксис для задания соответствия TOS-битов в правилах:

-m tos --tos mnemonic [other-args] -j target

Синтаксис для установки TOS-битов в правилах:

[other-args] -j TOS --set mnemonic

Помните, что они обычно используются вместе, но могут использоваться совершенно независимо, если это нужно.

Имя Шестнадцатеричное значение

Нормальый сервис	0x00
Minimize-Cost	0x02
Maximize-Reliability	0x04
Maximize-Throughput	0x08
Minimize-Delay	0x10

VERSIONID и OSTYPE VERSIONID(`@(#)sendmail

VERSIONID и OSTYPE

VERSIONID(`@(#)sendmail.mc 8.9 (Linux) 01/10/98')

Макрокоманда VERSIONID факультативная, но полезно записать версию конфигурации sendmail в файл sendmail.cf. Так что Вы будете часто сталкиваться с этим. В любом случае убедитесь в наличии:

OSTYPE(`linux')

Это, вероятно, наиболее важное определение. Макрокоманда OSTYPE заставляет включить файл определений, которые являются хорошими значениями по умолчанию для Вашей операционной системы. Большинство определений в файле OSTYPE устанавливают имена различных файлов конфигурации, имена разных служебных каталогов и имя почтовой программы. Стандартный комплект исходных кодов sendmail включает такой файл для Linux. Многие дистрибутивы Linux, особенно Debian, имеют собственный файл определения, который является полностью совместимым с Linux-FHS. При наличии такого файла следует использовать именно его, а не поставляемую в комплекте с sendmail версию.

Определение OSTYPE должно располагаться поближе к началу файла sendmail.mc, так как много других определений зависят от него.

Внутренние действия uucico

Чтобы понять, почему uucico должен знать некоторые вещи, приведем краткое описание того, как фактически происходит соединение с удаленной системой.
Внутренние действия uucico

Чтобы понять, почему uucico должен знать некоторые вещи, приведем краткое описание того, как фактически происходит соединение с удаленной системой.

Когда Вы выполняете из командной строки команду uucico -s system, сначала происходит физическое соединение. Предпринимаемые действия зависят от типа открываемого соединения. Например, при использовании телефонной линии, команда должна найти модем и набрать номер. Если используется TCP, uucico должна вызвать функцию gethostbyname, чтобы преобразовать имя в сетевой адрес, выяснить, какой порт открывать, и связать адрес с соответствующим сокетом.

После того, как соединение будет установлено, должна выполниться процедура идентификации пользователя. Она состоит из запроса удаленной системой имени, и, возможно, пароля. Все это называется login chat. Процедура идентификации выполняется обычным набором программ getty/login или (на сокетах TCP) непосредственно uucico. Если разрешение на вход получено, удаленная система запускает uucico. Локальная копия uucico, которая инициализировала соединение, назначается главной (master), а удаленная подчиненной (slave).

Затем следует фаза рукопожатия (handshake phase): главная копия посылает cвое hostname и некоторые флаги. Подчиненная система проверяет, имеет ли hostname право входить в нее, посылать и принимать файлы и т.д. Флаги описывают (кроме всего прочего) максимальный приоритет буферизации передаваемых файлов. Если возможно, счет диалога или проверка порядкового номера обращения происходит здесь. Благодаря этой возможности, обе копии поддерживают счет успешных соединений (call sequence number), которые сравниваются. Если они не соответствуют, рукопожатиe прерывается. Это помогает защищаться от самозванцев-хакеров.

В заключение uucico пытается установить общий протокол передачи (transfer protocol). Этот протокол обеспечивает способ перемещения данных, проверку на непротиворечивость и повторную передачу в случае ошибки. Имеется потребность в различных протоколах из-за отличающихся типов обеспечиваемых соединений. Например, телефонные линии требуют "безопасный" протокол, который включает в себя жесткую проверку ошибок в то время, как передача TCP по существу надежна и может использовать более эффективный протокол.

После того, как рукопожатие закончено, начинается фактическая фаза передачи. Обе системы включают выбранный драйвер протокола. Драйверы могут выполнять свою специфическую инициализацию.

Сначала главная система посылает все файлы, поставленные в очередь для передачи на удаленную систему, приоритет буферизации которых является достаточно высоким. Когда передача завершена, она сообщает об этом подчиненной системе, она может теперь отключиться или принимать диалог. Это изменение ролей (назначений): теперь удаленная система становится главной, а локальная становится подчиненной. Она теперь посылает файлы. Когда передача завершена, обе программы обмениваются заключительными сообщениями и закрывают соединение.

Мы не будем вникать во все детали: пожалуйста, обратитесь за ними к исходным текстам или к любой хорошей книге по UUCP. Есть также очень старая статья, касающаяся сети, написанной David A. Novitz, которая дает детализированное описание протокола UUCP. Taylor UUCP FAQ также обсуждает некоторые подробности UUCP. Это всегда есть в группе новостей comp.mail.uucp.

Внутренние сети IPX и маршрутизация

Компьютеры с несколькими IPX-интерфейсами имеют уникальную комбинацию адресов сеть/узел для каждого из интерфейсов. Чтобы соединяться с таким компьютером, Вы можете использовать любую из этих комбинаций. Когда SAP объявляет сервисы, это обеспечивает адрес сети/узла, связанный с сервисом. На компьютерах с несколькими интерфейсами это означает, что один из интерфейсов должен быть выбран как интерфейс для внесения в таблицы маршрутов, это функция флажка primary интерфейса, о котором мы уже говорили ранее. Но это представляет проблему: маршрут к этому интерфейсу не может всегда быть оптимальным, и если происходит сбой, который изолирует эту сеть от остальной части сети, компьютер станет недостижим даже при том, что имеются другие возможные маршруты к другим интерфейсам. Другие маршруты никогда не будут известны другим компьютерам, потому что они не вносятся в таблицы маршрутов, и ядро не может узнать, что оно должно выбрать другой первичный интерфейс. Чтобы избежать этой проблемы, разработано устройство, которое позволяет IPX-компьютеру быть известным, как независимая от маршрута пара адресов сеть/узел. Это решает нашу проблему потому, что эта новая пара доступна через все интерфейсы.
Внутренние сети IPX и маршрутизация

Рассмотрим сервер, подключенный к двум сетям IPX. Он выбирает один из своих интерфейсов как primary, пусть это будет 0000001a:0800000010aa, и объявляет его точкой доступа для некоего сервиса. Это работает нормально для сети 0000001a, но пользователи сети 0000002c пойдут кружным путем через первую сеть, несмотря на то, что сервер имеет порт и в их сети.

Это решается созданием виртуальной сети, которая является полностью программной конструкцией. Ее лучше рассматривать, как находящуюся внутри IPX-машины. SAP-информация нужна только для распространения адреса этой сети. Такие виртуальные сети известны как внутренние (internal network). Но как другие компьютеры узнают, каким путем достичь этой сети? Удаленные компьютеры направляются к внутренней сети через непосредственно связанные сети главного компьютера. Это означает, что надо смотреть на записи маршрутов, которые обращаются к внутренним сетям машин, имеющих несколько сетевых IPX-интерфейсов. Таким образом, в каждый момент будет выбран оптимальный маршрут. Допустим, мы сконфигурировали внутреннюю IPX-сеть с адресом 0x10000010 и используем адрес хоста 00:00:00:00:00:01. Это тот адрес, который будет нашим первичным интерфейсом. Он будет сообщаться через SAP. Наша маршрутизация отразит эту сеть как доступную через любой из реальных сетевых портов, так что компьютеры будут всегда использовать самый лучший сетевой маршрут, чтобы соединиться с этим сервером.

Для созадния внутренней сети используйте команду ipx_internal_net, входящую в пакет IPX tools (автор Greg Page). Простой пример:

# ipx_internal_net add 10000010 000000000001

Эта команда создаст внутреннюю IPX-сеть с адресом 10000010 и адресом узла 000000000001. Сетевой адрес, точно так же как любой другой сетевой адрес IPX, должен быть уникален в Вашей сети. Адрес узла произвольный, так как будет иметься только один узел в этой сети. Каждый компьютер может иметь только одну внутреннюю сеть IPX (IPX Internal Network), и если она сконфигурирована, то всегда будет первичной (primary) сетью.

Для удаления внутренней сети IPX используйте:

# ipx_internal_net del

Введение в сети TCP/IP

TCP/IP происходит от проекта, финансируемого американским DARPA (Defense Advanced Research Projects Agency) в 1969. Это была экспериментальная сеть ARPANET, которая была преобразована в эксплуатационную в 1975 после того, как была доказана ее полезность.
Введение в сети TCP/IP

В 1983 новый протокол TCP/IP был принят как стандарт и от всех хостов в сети требовалось его использование. Когда ARPANET, наконец, вырос в Inetrnet (ARPANET непосредственно окончил свое существования в 1990), использование TCP/IP распространилось и на сети вне Inetrnet. Наиболее известны локальные сети Unix, но из-за появлении быстрого цифрового телефонного оборудования, типа ISDN, он также имеет большой шанс стать протоколом транспортировки для телефонных сетей.

Для более конкретного рассмотрения TCP/IP повсюду в следующих разделах мы будем пользоваться как примером университетом Groucho Marx (GMU), большинство его отделов используют собственную локальную сеть, а другие используют несколько таких сетей. Они все связаны и подключены к 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-приложением. Чтобы сказать этому приложению, что Вы хотите видеть окна на экране Вашего хоста, Вы должны отрегулировать среду. Это делается переменной окружения DISPLAY:

$ DISPLAY=erdos.maths:0.0 $ export DISPLAY

Если Вы теперь запускаете приложение, оно будет входить в контакт с Вашим X-сервером вместо quark и отображать все окна на Вашем экране. Конечно, это требует наличия у вас X11. TCP/IP позволяет quark и erdos посылать X11-пакеты туда и обратно, создавая иллюзию, что Вы находитесь на удаленной системе. Сеть здесь почти прозрачна.

Другое очень важное приложение в сетях TCP/IP: NFS (сетевая файловая система, Network File System). Это другая форма создания прозрачной сети, она позволяет монтировать каталоги с других хостов так, чтобы они рассматривались подобно локальным файловым системам. Например, домашние каталоги всех пользователей могут быть на центральной машине, с которой все другие хосты в локальной сети монтируют требуемые каталоги. В результате пользователи могут войти в сеть с любой машины и находиться в том же самом домашнем каталоге. NFS подрпобно рассмотрена в главе 14.

Конечно, это не единственные примеры того, что Вы можете делать в сетях TCP/IP. Ваши возможности почти безграничны.

Теперь мы поближе познакомимся с работой TCP/IP. Вы будете нуждаться в этом, чтобы понять, как и почему Вы должны конфигурировать свою машину. Мы начнем с исследования аппаратных средств.

Выбор группы для дальнейшей работы

Когда пользователь выбирает группу для просмотра, newsreader может сообщить серверу, что некая группа была выбрана. Это упрощает взаимодействие между ними: исчезает потребность постоянно в каждой команде указывать имя группы новостей. Команда group просто берет имя выбранной группы как параметр. Многие команды используют группу, выбранную по умолчанию сервером:
Выбор группы для дальнейшей работы

group junk 211 3 1 3 junk

Команда group возвращает сообщение с числом активных сообщений, старшим и младшим номерами и именем группы. Обратите внимание, что хотя в нашем примере число активных сообщений и старший номер статьи совпадают, такое бывает нечасто: некоторые статьи, возможно, устарели и были удалены, понижая число активных сообщений, но оставляя старший номер прежним! Здесь надо проявлять внимание.

Выбор нужных карт После проверки

Другие карты, подобно services.byname, не дают таких изменений, но избавляют от редактирования ряда настроек. Карта services.byname ценна, если Вы устанавливаете любые сетевые прикладные программы, которые используют сервисное имя не в стандартном файле services.

Вообще, надо иметь выбор, когда функция поиска использует локальные файлы, когда она делает запрос к серверу NIS станции, и в каких случаях используются другие серверы, типа DNS. GNU libc позволяет Вам конфигурировать порядок, в котором функция обращается к этим услугам. Это управляется через файл /etc/nsswitch.conf (сокращение от Name Service Switch), но он, конечно, не ограничен обслуживанием имен. Для любой из функций поисковой таблицы данных, поддерживаемых GNU libc, файл содержит соответствующую строку.

Порядок опроса зависит от типа данных, которые предлагает каждый сервис. Маловероятно, что карта services.byname будет содержать записи, отличающиеся от своих аналогов в локальном файле services. Она будет содержать только дополнительные записи. Так что проще сначала сделать запрос локальных файлов и проверять NIS только, если сервисное имя не найдено. С другой стороны, информация об именах машин может изменяться очень часто, так что сервер DNS или NIS должен всегда иметь наиболее точные данные в то время, как локальный файл hosts сохраняется только как копия на случай, если DNS и NIS не сработали. Следовательно, для hostname обычно надо проверять локальный файл данных в последнюю очередь.

Следующий пример показывает, как вынудить функции gethostbyname и gethostbyaddr искать в NIS и DNS до просмотра файла hosts и как заставить функцию getservbyname просматривать локальные файлы перед запросом к NIS. Эти функции опробуют каждый из перечисленных сервисов. Если поиск прошел успешно, возвращается результат, иначе выбирается следующий сервис. Установка файла для этих приоритетов:

# small sample /etc/nsswitch.conf # hosts: nis dns files services: files nis

Ниже приведен полный список сервисов и обращений, которые могут использоваться в файле nsswitch.conf.

nis

Использовать текущий сервер NIS домена. Его расположение задается в yp.conf, как показано в предыдущем разделе. Для записи hosts запрашиваются карты hosts.byname и hosts.byaddr.

nisplus или nis+

Использовать для этого домена сервер NIS+. Где его искать берется из файла /etc/nis.conf.

dns

Использовать сервер имен DNS. Этот сервисный тип полезен только с записью hosts. Сервер, который будет запрошен, задается в resolv.conf.

files

Использовать локальный файл (например, /etc/hosts для запроса hosts).

compat

Нужна совместимость со старыми форматами файлов. Эта опция может использоваться, когда NYS или glibc 2.x используются для поиска в NIS или NIS+. В то время, как эти версии обычно не могут интерпретировать старые записи NIS в файлах passwd и group, опция compat позволяет им работать с этими форматами.

Информация берется из файлов DBM, размещенных в каталоге /var/db. Соответствующее имя карты NIS используется для этого файла.

В настоящее время реализация NIS в GNU libc поддерживает следующие базы данных для nsswitch.conf: aliases, ethers.group, hosts, netgroup, network, passwd, protocols, publickey, rpc, services и shadow.

Пример 13-2 показывает более полный пример, который представляет новое свойство nsswitch.conf. Ключевое слово [NOTFOUND=return] в записи hosts предписывает клиенту NIS вернуться, если нужный элемент не может быть найден в базе данных NIS или DNS.

Выбор специфических протоколов

Не каждая реализация uucico понимает все протоколы, так что в течение начальной фазы авторизации оба процесса должны договориться об общем протоколе. Главный uucico предлагает подчиненому список обеспечиваемых протоколов, посылая Pprotlist, из которого подчиненный может выбирать.
Выбор специфических протоколов

Основываясь на типе используемого порта (модем, TCP или прямой), uucico составит заданный по умолчанию список протоколов. Для модема и прямых соединений этот список обычно включает i, a, g, G и j. Для соединений TCP это t, e, i, a, g, G, j и f. Вы можете изменить этот заданный по умолчанию список командой protocols, которая может быть определена в записи системы или порта. Например, Вы могли бы записать в файл port примерно следующее:

port serial1 ... protocols igG

Это требует от любого входящего или исходящего соединения через этот порт использовать i, g или G, если удаленная система не поддерживает никакой из них, диалог потерпит неудачу.

Выключение rкоманд

Самый простой способ запретить r-команды, это закомментировать или удалить записи для них в файле /etc/inetd.conf. Соответствующие им строки этого файла выглядят так:

# Shell, login, exec and talk are BSD protocols. shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd

Вы можете закомментировать их, помещая символ # в начале каждой строки. Не забудьте, что Вы должны перезапустить inetd daemon для вступления изменений в силу.
Выключение r-команд

Вы можете закомментировать их, помещая символ # в начале каждой строки. Не забудьте, что Вы должны перезапустить inetd daemon для вступления изменений в силу.

Выключение сервера новостей

Чтобы выключить сервер новостей скомандуйте:

ctlinnd throttle reason

Выключение сервера новостей

Чтобы выключить сервер новостей скомандуйте:

ctlinnd throttle reason

Аргументы имеют смысл:

reason

Причина выключения сервера.

Эта команда эквивалент одновременно выданных newsreaders no и reject и полезна, когда на базе данных новостей выполняется работа по ликвидации повреждений. Это гарантирует, что ничто не пытается модифицировать базу в то время, как Вы работаете с ней.

Выполнение команд

Задача UUCP состоит в том, чтобы копировать файлы из одной системы в другую и запрашивать выполнение некоторых команд на удаленных машинах. Конечно, Вы как администратор хотите управлять тем, какие права предоставляете другим системам: разрешать им делать, что угодно, определенно, не очень хорошая идея.
Выполнение команд

По умолчанию Taylor UUCP разрешает выполнять на Вашей машине лишь rmail и rnews, которые обычно используются для e-mail и Usent новостей по UUCP. Заданный по умолчанию путь поиска, используемый uuxqt, настраивается во времея компиляции, но обычно содержит /bin, /usr/bin, и /usr/local/bin. Чтобы изменять набор команд для определенной системы, Вы можете использовать ключевое слово commands в файле sys. Аналогично, путь поиска может быть изменен указанием ключевого слова command-path. Например, Вы можете разрешить системе pablo выполнять команду bsmtp в дополнение к rmail и rnews:

system pablo ... commands rmail rnews bsmtp

Выталкивание (Pushing) статьи на сервер

Я упомянул команду IHAVE когда говорил о выталкивании статей на сервер новостей. Давайте посмотрим, как она работает:
Выталкивание (Pushing) статьи на сервер

Я упомянул команду IHAVE когда говорил о выталкивании статей на сервер новостей. Давайте посмотрим, как она работает:

ihave 335 From: terry@gw.vk2ktj.ampr.org Subject: test message sent with ihave Newsgroups: junk Distribution: world Path: gw.vk2ktj.ampr.org Date: 26 April 1999 Message-ID: Body: This is a test message sent using the NNTP IHAVE command. . 235

Все команды NNTP нечувствительны к регистру, так что Вы можете вводить их в любом. Команда IHAVE берет один обязательный параметр, это Message ID статьи, которая помещается на сервер. Каждая статья имеет уникальный message ID. Команда IHAVE будет выдана для каждой статьи, которую сервер желает передать. Если код ответа команды находится в диапазоне "3xx", NNTP-сервер передаст полную статью с заголовком и точкой в отдельной строке в качестве маркера конца статьи. Если код ответа был в диапазоне "4xx", принимающий сервер данную статью принять не может из-за ее наличия или какой-то технической проблемы.

Когда статья передана, принимающий сервер генерирует код сообщающий, успешно ли он принял статью.

Задание TOSбитов с помощью ipfwadm или ipchains

Команды ipfwadm и ipchains имеют дело с TOS-битами. В обоих случаях Вы определяете правило, которое соответствует пакетам с конкретным TOS-битом, и используете параметр -t, чтобы определить изменение, которое Вы желаете сделать.
Задание TOS-битов с помощью ipfwadm или ipchains

Изменения определяются, используя двухразрядные маски. Первая из этих разрядных масок используется в логической операции AND с полем параметров IP-пакета, вторая в операции OR. Если это звучит сложно, я дам Вам рецепты, чтобы обеспечить каждый из типов обслуживания немедленно.

Разрядные маски определяются, используя восьмиразрядные шестнадцатеричные значения. ipfwadm и ipchains используют одинаковый синтаксис:

-t andmask xormask

Наиболее полезные применения для масок приведены вместе с их значениями в таблице 9-3.

Зал славы

Помимо тех, кого мы уже упомянули, большое количество людей внесло вклад в Networking Guide, Мы очень благодарны.
Зал славы

Помимо тех, кого мы уже упомянули, большое количество людей внесло вклад в Networking Guide, Мы очень благодарны.

Имеется список тех, чье содействие оставило след в книге:

Al Longyear, Alan Cox, Andres SepЗlveda, Ben Cooper, Cameron Spitzer, Colin McCormack, D.J. Roberts, Emilio Lopes, Fred N. van Kempen, Gert Doering, Greg Hankins, Heiko Eissfeldt, J.P. Szikora, Johannes Stille, Karl Eichwalder, Les Johnson, Ludger Kunz, Marc van Diest, Michael K. Johnson, Michael Nebel, Michael Wing, Mitch D'Souza, Paul Gortmaker, Peter Brouwer, Peter Eriksson, Phil Hughes, Raul Deluth Miller, Rich Braun, Rick Sladkey, Ronald Aarts, Swen ThЭemmler, Terry Dawson, Thomas Quinot и Yury Shevchuk.

Перевод на русский язык выполнен Паутовым Алексеем в рамках проекта Russian LDP. ¦ёЮ----г А¦=А¬¦- ·.-. ?г-ГЦLЦ ¬= Е-АБ¬-ё гLО ¦Ю-гLБ=!

Заполнение поля From пользователями

Иногда полезно переписывать поле From: исходящих писем. Например, есть web-программа, которая отсылает почту. Обычно письмо от нее придет от имени пользователя, которому принадлежит web-сервер. Но можно определить другой исходный адрес так, чтобы почта исходила с другого адреса. Пакет sendmail обеспечивает средства определения того, для каких пользователей это делать.
Заполнение поля From: пользователями

Опция use_ct_file допускает спецификацию и использование файла, который вносит в список имена доверенных пользователей. По умолчанию таких пользователей мало (root, например). Имя этого файла обычно /etc/mail/trusted-users в системах, использующих каталог настроек /etc/mail или /etc/sendmail.ct во всех остальных. Вы можете определять имя и расположение файла макросом confCT_FILE.

Добавьте FEATURE(use_ct_file) к Вашему файлу sendmail.mc для поддержки возможности.

Запрещение пользователям получать

Запрещение пользователям получать почту

Если Вы имеете пользователей или автоматизированные процессы, которые посылают почте, но никогда не должны ее получать, иногда полезно отказаться принимать предназначенную для них почту. Возможность blacklist_recipients используется в комбинации с access_db и позволяет отключить получение почты для локальных пользователей.

Для включения данного свойства добавьте в sendmail.mc:

FEATURE(access_db) FEATURE(blacklist_recipients)

Чтобы отключить получение почты для локального пользователя, просто добавьте его в базу данных доступа. Обычно Вы будете использовать запись ###, которая возвратит сообщение об ошибке отправителю, так что он будет знать, почему почта не доходит. Это свойство применяется и для виртуальных доменов, но Вы должны включить виртуальный домен в спецификации базы данных доступа. Образец файла /etc/mail/access:

daemon 550 Daemon does not accept or read mail. flacco 550 Mail for this user has been administratively disabled. grump@dairy.org 550 Mail disabled for this recipient.

Запуск INN Пакет исходников inn

Чтобы гарантировать, что inn запустится при начальной загрузке, Вы должны проверить, что /usr/lib/news/innshellvars сконфигурирован правильно, и затем вызвать /usr/lib/news/bin/rc.news во время загрузки.

Имеются административные задачи, которые должны выполняться периодически. Эти задачи обычно конфигурируются так, чтобы быть выполненными командой cron. Самый лучший способ сделать это состоит в том, чтобы добавить соответствующие команды к Вашему файлу /etc/crontab, или даже лучше, создать файл в каталоге /etc/cron.d, если Ваш дистрибутив такой сервис поддерживает. Пример такого файла:

# Example /etc/cron.d/inn file, as used in the Debian distribution. # SHELL=/bin/sh PATH=/usr/lib/news/bin:/sbin:/bin:/usr/sbin:/usr/bin # Expire old news and overview entries nightly, generate reports. 15 0 * * * news news.daily expireover lowmark delayrm # Every hour, run an rnews -U. This is not only for UUCP sites, but # also to process queued up articles put there by in.nnrpd in case # innd wasn't accepting any articles. 10 * * * * news rnews -U

Эти команды гарантируют, что старые новости автоматически удаляются каждый день, и что любые поставленные в очередь статьи будут обработаны в пределах часа. Обратите внимание также, что все выполняется с правами пользователя news.

Запуск NISсервера Обратите внимание

Имеются две возможных конфигурации NIS-сервера: главный (master) и подчиненный (slave). Вторая конфигурация обеспечивает резервную машину, которая должна подхватить нагрузку при сбое основной. Поскольку в документации сервера есть детальное описание различий в настройке первичного и подчиненного режимов, здесь я опишу только настройку первичного сервера.

В настоящее время есть два NIS-сервера, свободно доступные для Linux: один в пакете yps (автор Tobias Reber) и второй в пакете ypserv (разработан Peter Eriksson). Особой разницы между ними нет.

После установки программы-сервера (ypserv) в каталог /usr/sbin, Вы должны создать каталог, хранящий файлы карт, которые Ваш сервер должен распределять. При установке домена NIS как brewery, карты окажутся в каталоге /var/yp/brewery. Сервер определяет, обслуживает ли он некий домен NIS по наличию каталога с картами, так что при отключении некоего домена удалите и соответствующий каталог.

Карты обычно хранятся в DBM-файлах, чтобы ускорить поиск. Они создаются из файлов-заготовок программой makedbm (для сервера Tobias) или dbmload (для версии Peter).

Преобразование главного файла-заготовки в форму для анализа программой dbmload требует довольно сложной работы с процессором awk или sed. Поэтому пакет ypserv Питера Ерикссона (Peter Eriksson) содержит Makefile (с именем ypMakefile), который управляет преобразованием наиболее часто встречающихся файлов. Вы должны установить его как Makefile в каталоге карт и отредактировать так, чтобы отразить карты, которые Вы хотите распространять. Строки для задания карт выглядят так:

all: ethers hosts networks protocols rpc services passwd group netid

Если Вы не хотите распространять, например, карты ethers.byname и ethers.byaddr, просто удалите записи ethers из этого правила. Чтобы проверить настройку, Вы можете запустить сервис с одной или двумя картами, например, services.*.

После редактирования Makefile выполните в каталоге с картами команду make. Она автоматически генерирует и устанавливает карты. Вы должны удостовериться, что они будут модифицироваться всякий раз, когда Вы изменяете файлы, на основе которых построены карты, иначе изменения останутся невидимыми для сети.

В разделе "Установка клиента NIS с GNU libc" будет рассказано, как конфигурировать клиент NIS. Если настройки не работают, Вы должны попробовать выяснить, достигают ли запросы сервера вообще. Если Вы определяете параметр командной строки --debug для ypserv, на консоли будут выведены данные о NIS-запросах и их выполнении. Данная опция не работает в сервере, разработанном Tobias Reber.

Запуск pppd Когда Вы хотите соединитьcя

Как вводный пример того, как устанавливать PPP-связь с помощью pppd, представьте, что Вы работаете на машине vlager. Вы уже соединились с сервером c3po по телефону и зарегистрировались под именем ppp. Машина c3po уже запустила свой PPP-драйвер. После выхода из коммуникационных программ, которые Вы используете для соединения по телефону, Вам необходимо выполнить следующую команду:

# pppd /dev/ttyS3 38400 crtscts defaultroute

Эта команда переведет последовательную линию ttyS3 в PPP-режим и установит IP-связь с c3po. Скорость передачи, используемая на последовательном порте будет 38400bps. Опция crtscts включает аппаратное соединение (hardware handshake) на порт, который должен работать на скорости более, чем 9600 bps.

Первая вещь, которую pppd делает после запуска, договаривается о характеристиках связи, используя LCP. Обычно, по умолчанию задано множество опций, о которых pppd пробует договориться, так что мы не будем подробно вдаваться в это сейчас, а вернемся к LCP позже.

В настоящее время, мы также предполагаем, что c3po не требует какой-либо авторизации, так что период конфигурации завершен успешно.

pppd будет договариваться о IP-параметрах с сервером, используя IPCP (IP control protocol). Так как мы не определяли точно IP-адрес в pppd выше, то он попробует использовать адрес, полученный при просмотре локального hostname. Затем машины объявят этот адрес друг другу.

Обычно, с этими значениями по умолчанию ничего не делается. Даже если Ваша машина находится в Ethernet, Вы можете использовать тот же самый IP-адрес для Ethernet и для PPP-интерфейса. Но тем не менее pppd позволяет Вам использовать различные адреса или даже спрашивать сервер для того, чтобы использовать некоторый специфический адрес. Эти опции будут рассмотрены чуть позже в разделе Опции настройки IP (IPCP).

После прохождения периода установки IPCP, pppd подготовит Ваш сетевой интерфейс для того, чтобы использовать PPP-связь. Сначала будет сконфигурирован сетевой интерфейс PPP как связь point-to-point, используя ppp0 для первой PPP-cвязи, которая является активной, ppp1 для второй и так далее. Затем, он установит маршрутную таблицу, которая указывает на хост в другом конце связи (сервер). В примере, показанном выше, pppd создаст сетевой маршрут по умолчанию к c3po опцией defaultroute. Он заставляет все пакеты к хостам не в локальной сети идти через c3po. Есть ряд различных маршрутов, которые поддерживает pppd, их мы обсудим позже в этой главе.

Запуск sendmail Демон sendmail

При запуске sendmail в автономном режиме, поместите команду в rc-файл, чтобы он запускался при начальной загрузке. Синтаксис обычно такой:

/usr/sbin/sendmail -bd -q10m

Аргумент -bd сообщает, чтобы sendmail выполнился как daemon. Он будет выполняться в фоновом режиме. Параметр -q10m сообщает, что надо проверять очередь каждые десять минут. Вы можете выбирать для разных очередей разное время проверки.

Для запуска sendmail из inetd используйте запись вида:

smtp stream tcp nowait nobody /usr/sbin/sendmail -bs

Аргумент -bs сообщает sendmail, использовать протокол SMTP на stdin/stdout, который требуется для использования с inetd.

Команда runq обычно представляет собой более удобную форму вызова:

# sendmail -q

Когда sendmail вызывается так, он обрабатывает любую почту в очереди. При запуске sendmail из inetd Вы должны также создать задачу cron, которая периодически выполняет runq, чтобы гарантировать, что очередь почты обслуживается сервером периодически.

Подходящая запись для cron:

# Run the mail spool every fifteen minutes 0,15,30,45 * * * * /usr/bin/runq

Большинство инсталляций sendmail обрабатывают очередь почты каждые 15 минут, как показано в данном примере.

Запуск в режиме сервера Установка

Есть два способа работы в серверном режиме SLIP. Оба они требуют создания специального пользователя для клиента SLIP. Допустим, нужно предоставить SLIP-сервис пользователю Arthur Dent с машины dent.beta.com. Создайте логин dent добавлением в файл passwd такой строки:

dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplogin

Затем установите пароль для dent командой passwd.

Команда dip может работать в серверном режиме под именем diplogin. Обычно diplogin является ссылкой на dip. Его главный файл конфигурации /etc/diphosts, который присоединяет имена пользователей к IP адресу. В качестве альтернативы Вы можете также использовать sliplogin, BSD-производное средство, которое описывает более гибкую схему конфигурации, которая позволяет Вам выполнить скрипт всякий раз, когда хост устанавливает и разрывает связь с Вашей машиной.

Когда SLIP-пользователь dent зарегистрируется в системе, dip перейдет в режим сервера. Чтобы определить, действительно, ли ему разрешено использовать SLIP, нужно найти имя пользователя в /etc/diphosts. Этот файл подробно описывает права доступа и параметры соединения для каждого SLIP-пользователя. Типовая запись в /etc/diphosts:

# /etc/diphosts user:password:rem-addr:loc-addr:netmask:comments:protocol,MTU

Поля описаны в таблице 7-2.

Защита системы

Другой очень важный аспект администрирования, это защита от хакеров. Небрежно управляемые системы предлагают злонамеренным людям много адресатов. Атаки могут быть самыми разными: от подбора паролей до Ethernet snooping. Я упомяну некоторые специфические проблемы при обсуждении контекста, в котором они могут происходить, и некоторую общую обороноспособность против них.
Защита системы

Этот раздел содержит несколько примеров и базисные методы для защиты. Конечно, охваченные темы не могут показать все проблемы защиты: они просто служат для иллюстрации проблем, которые могут возникать. Следовательно, чтение хорошей книги по защите насущная необходимость.

Защита системы начинается с хорошего администрирования системы. Это включает проверку монопольного использования и разрешений всех жизненных файлов и каталогов и текущего контроля использования привилегированных логинов. Программа COPS, например, проверит файловую систему и общие файлы конфигурации в поисках необычных разрешений или других аномалий. Также мудро использовать пакет, который предписывает некоторые правила паролей пользователей, которые делают их трудными для подбора. Пакет shadow password suite, например, требует, чтобы пароль имел по крайней мере пять символов и содержал символы верхнего и нижнего регистров и неалфавитные символы.

При создании сервиса, доступного для сети, удостоверьтесь, что Вы дали ему наименьшее количество привилегий. То есть, сервис не должен делать ничего лишнего. Под "лишним" здесь понимается все, что не относится к его работе. Более того, он не должен иметь права делать это. Например, Вы должны объявлять программы как setuid к root или другому привилегированному логину только тогда, когда это необходимо. Также если Вы хотите использовать сервис только для очень ограниченной прикладной программы, пожалуйста, конфигурируйте его так ограничено, как эта прикладная программа позволяет. Например, если Вы хотите позволить компьютерам без диска загружаться с Вашей машины, Вы должны обеспечить Trivial File Transfer Protocol (TFTP) так, чтобы они могли загружать базисные файлы конфигурации из каталога /boot. Однако, когда TFTP используется без ограничителей, протокол позволяет пользователям где-нибудь в мире загружать любой открытый всем на чтение файл из Вашей системы. Если это не то, что Вы хотите, ограничьте TFTP доступом к каталогу /boot.

Вы могли бы также ограничивать некоторые услуги пользователями с определенных компьютеров, скажем, из Вашей локальной сети. В главе 12, мы обсудим tcpd, который делает это для ряда сетевых прикладных программ. Более сложные методы ограничения доступа к компьютерам или сервисам будут исследоваться позже в главе 9.

Другая важная задача: избегать "опасного" программного обеспечения. Конечно, любое программное обеспечение, которое Вы используете, может быть опасно, потому что программное обеспечение может иметь ошибки, которые умные люди могли бы эксплуатировать, чтобы получить доступ к Вашей системе. Такие вещи случаются, и нет никакой полной защиты против этого. Эта проблема одинаково воздействует на свободные и коммерческие программы. Однако, программы, которые требуют специальных привилегий, всегда более опасны, чем другие потому, что в них любая лазейка может иметь куда более разрушительные последствия. Если Вы устанавливаете setui-программу для сетевых целей, надо быть вдвойне осторожными и проверить документацию, чтобы быть уверенными в том, что Вы не создали нарушение защиты случайно.

Еще одним источником головной боли являются программы, которые допускают вход в систему или выполнение команды с ограниченной авторизацией. Команды rlogin, rsh и rexec очень полезные, но их проверка сводится к авторизации стороны вызова. Авторизация основана на доверии к имени вызывающего компьютера, полученного из сервера имен (мы будем говорить о нем позже), который может быть фальшивым. Сегодня должно стать обычной задачей полностью отключить r-команды и заменить их на набор инструментальных средств ssh. Эти инструментальные средства используют намного более надежный опознавательный метод и обеспечивают также другие услуги, типа шифрования и сжатия.

Вы никогда не можете исключать то, что Ваши предосторожности пропали даром, независимо от того, насколько предусмотрительны Вы были. Вы должны удостовериться, что обнаруживаете хакеров своевременно. Проверка журналов системы хорошая отправная точка, но хакер бывает достаточно умен, чтобы ожидать это действие и удалит любые очевидные следы. Однако, имеются инструментальные средства подобные tripwire (авторы Gene Kim и Gene Spafford), которые позволяют Вам проверять жизненно важные системные файлы, чтобы видеть, было ли их содержание или разрешения изменены. Программа tripwire вычисляет различные контрольные суммы этих файлов и сохраняет их в базе данных. В дальнейшем контрольные суммы повторно вычисляются и сравниваются с сохраненными, чтобы обнаружить любые модификации.