В главе 2 рассматривались различные способы настройки компьютера для работы в сетях TCP/IP. Один из этих способов предполагал использование сервера DHCP (Dynamic Host Configuration Protocol — протокол динамической настройки узла). Чтобы определить расположение сервера DHCP, компьютер передает широковещательный запрос. В ответ сервер DHCP возвращает компьютеру его IP-адрес и другие сведения, необходимые для настройки. Такое взаимодействие существенно упрощает настройку компьютеров, выполняющих функции клиентов DHCP, так как исключает необходимость вводить IP-адрес машины, IP-адрес шлюза и другие конфигурационные данные. Однако система DHCP не возникает в сети сама собой. Вам необходимо сконфигурировать сервер DHCP так, чтобы он отвечал на запросы клиентов DHCP. Настройке сервера DHCP посвящена данная глава.

Прежде чем приступить к установке конфигурации сервера DHCP, вам надо убедиться в том, что он действительно нужен. Если это так, вы можете приступать к формированию конфигурационных файлов DHCP. В простейшем случае сервер DHCP распределяет IP- адреса между клиентами таким образом, что после перезагрузки адрес клиента DHCP может измениться. Более сложная конфигурация позволяет присваивать компьютеру один и тот же IP-адрес. Кроме выбора конфигурации, в данной главе рассматриваются также вопросы интеграции сервера DHCP с другими серверами, например Samba или DNS.

Эта глава не содержит исчерпывающей информации о работе сервера DHCP, а призвана лишь дать читателю основные понятия о его настройке. Тем не менее данные, приведенные здесь, часто оказываются достаточными для администрирования простых сетей. Если вам необходимо настроить сервер DHCP для выполнения сложных задач, то, возможно, потребуется дополнительная литература. В качестве дополнительных источников информации можно посоветовать книги Дромса (Droms) и Лемона (Lemon) The DHCP Handbook: Understanding, Deploying, and Managing Automated Configuration Services (New Riders Publishing, 1999) и Керчевала (Kercheval) DHCP: A Guide to Dynamic TCP/IP Network Configuration (Prentice Hall, 1999).

Очевидно, что сервер DHCP имеет смысл устанавливать в том случае, если в сети присутствуют клиенты DHCP. Но при настройке клиентских машин также возникает вопрос: следует ли инсталлировать на них клиент-программы DHCP. Такая программа нужна, только если в сети имеется сервер DHCP. Круг замкнулся. Чтобы "разорвать" его, надо рассмотреть сеть в целом и выяснить, что проще: задавать для каждого компьютера статический IP-адрес или установить и настроить один сервер DHCP.

Чтобы оценить трудоемкость установки статического IP-адреса на компьютере, надо вспомнить материал, изложенный в главе 2. Необходимо также принять во внимание тот факт, что в различных операционных системах сетевые средства настраиваются по-разному. Сервер DHCP, выполняющийся на компьютере под управлением Linux, может предоставлять IP-адреса клиентам, выполняющимся не только в среде Linux, но и на компьютерах, на которых установлены другие системы: различные версии UNIX, Windows, MacOS, OS/2, BeOS и т.д. Клиенты DHCP могут работать в любой системе, поддерживающей стек протоколов TCP/IP. При настройке компьютера для использования статического IP-адреса во всех системах задается приблизительно одинаковая информация; различаются лишь способы ее ввода. Практически во всех системах для инсталляции и настройки клиента DHCP требуется затратить меньше усилий, чем для установки статического IP-адреса.

На заметку

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

Для настройки сервера DHCP обычно требуется намного больше усилий, чем для установки статического IP-адреса на одном компьютере. Поэтому устанавливать сервер DHCP для обслуживания двух клиентов нецелесообразно. Работа по инсталляции и настройке сервера DHCP окупит себя только в том случае, если сеть насчитывает не меньше пяти-десяти узлов. (Если на компьютере установлены две системы, его надо считать как две машины, так как устанавливать IP-адреса придется в каждой системе.)

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

Несмотря на то что DHCP может значительно упростить настройку сети, в ней должен остаться по крайней мере один компьютер, использующий статический IP-адрес. Этим компьютером является сам сервер DHCP. Очевидно, что сервер надо настроить так, чтобы он не пытался выделить свой IP-адрес клиенту.

На заметку

Компьютер с несколькими сетевыми интерфейсами может выполнять роль клиента DHCP в одной сети и выступать в качестве сервера DHCP в другой.

Работа сети во многом зависит от надежности сервера DHCP. В случае неисправности сервера DHCP клиент не сможет вести переговоры о выделении IP-адреса, следовательно, не получит адрес при загрузке. Поэтому, занимаясь администрированием сети, необходимо предусмотреть резервный сервер DHCP. Этот сервер должен быть неактивен, но готов начать работу в любой момент, когда основной сервер DHCP выйдет из строя. По возможности надо обеспечить копирование файла основного сервера, содержащего информацию о выделенных адресах (файла аренды), на резервный сервер. Это нужно для того, чтобы резервный сервер не пытался выделить IP-адрес, который основной сервер уже присвоил другому компьютеру. Организовать периодическое копирование файла с данными о выделенных адресах можно с помощью инструмента

cron

Сервер DHCP обязательно входит в состав дистрибутивного пакета Linux, чего нельзя сказать об остальных системах. Поэтому при формировании сети имеет смысл планировать установку сервера DHCP на компьютере под управлением Linux. В небольшой сети можно использовать широкополосный маршрутизатор — устройство, которое позволяет подключать офисную или домашнюю сеть к Internet посредством кабельного или DSL-соединения. Такое устройство обычно содержит сервер DHCP. Сервер на широкополосном маршрутизаторе легче настраивать, чем сервер DHCP в системе Linux, однако он обеспечивает меньшую степень гибкости. Например, сервер DHCP широкополосного маршрутизатора, как правило, нельзя настроить так, чтобы конкретному клиенту выделялся один и тот же IP-адрес.

Для запуска сервера DHCP обычно используется сценарий SysV. Благодаря этому время отклика становится минимальным, а сервер получает возможность хранить важные конфигурационные данные в памяти. (Вопросы запуска серверов рассматривались в главе 5.)

Для того чтобы иметь возможность использовать сервер DHCP, надо правильно выбрать конфигурацию ядра системы, а также настроить сетевые средства. В частности, вам необходимо установить опции ядра Packet Socket и Socket Filtering. (Версия 1 dhcpd не требует Socket Filtering; эта опция нужна для новых версий программы.) Вопросы установки конфигурации ядра подробно рассматривались в главе

Некоторые клиенты DHCP требуют, чтобы сервер передавал ответы на запросы по адресу 255.255.255.255. Однако по умолчанию система Linux заменяет этот адрес на широковещательный адрес локальной сети (например, 192.168.1.255). Если при работе некоторых клиентов DHCP возникает проблема (обычно это проявляется в системе Windows), ее можно устранить, включив в таблицу маршрутизации компьютера, на котором расположен сервер DHCP, специальный маршрут. Для этого используется следующая команда:

# route add -host 255.255.255.255 dev eth0

Имя

eth0

route -n

Большинство дистрибутивных пакетов Linux содержит сервер DHCP, разработанный Internet Software Consortium (

http://www.isc.org/products/DHCP/

Для настройки сервера DHCP используется конфигурационный файл

dhcpd.conf

/etc

/etc/dhdcp

dhcpd.conf

dhcpd

dhcp.leases

/var/lib/dhcp

dhcp.leases

dhcp.leases

dhcp.leases

dhcp.leases

Строки файла

dhcpd.conf

#

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

• Декларации. Декларации описывают топологию сети (адреса, связанные с конкретными сетевыми интерфейсами), определяют IP-адреса, которые должны выделяться клиентам, а также связывают набор параметров с набором деклараций.

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

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

dhcpd.conf

host teela {

 hardware Ethernet 00:05:02:a7:76:da;

 fixed-address 192.168.1.2;

}

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

host

teela

dhcpd

Наиболее просто устанавливается конфигурация сервера DHCP, предполагающая динамическое распределение IP-адресов. В этом случае сервер сам решает, какой адрес следует выделить компьютеру, который обратился к нему. IP-адреса для конкретных машин не резервируются, поэтому IP-адрес, который клиент получил в данный момент, в общем случае может отличаться от IP-адреса, выделенного ему при прошлом обращении к серверу. Клиент может запросить конкретный адрес; более того, большинство клиентов запрашивают именно тот адрес, который они использовали ранее, но сервер игнорирует подобную информацию в составе запроса. На практике компьютеры могут достаточно долгое время работать с одним и тем же IP-адресом. Это происходит, если компьютер редко выключается либо если он был отключен в течение короткого промежутка времени. Тем не менее наличие постоянного IP-адреса не гарантируется. Конфигурация, осуществляющая динамическое распределение адресов, удобна в сетях, содержащих большое число клиентов, однако она имеет существенный недостаток: при динамическом распределении IP-адресов затрудняется использование доменных имен, так как серверы DNS связывают имена со статическими IP-адресами. Существуют способы устранения этого недостатка; их мы рассмотрим ниже. Один из способов предполагает организацию совместной работы серверов DHCP и DNS, а другой способ состоит в выделении компьютерам фиксированных IP-адресов.

В листинге 5.1 приведен пример содержимого файла

dhcpd.conf

Листинг 5.1. Простой файл

dhcpd.conf

default-lease-time 7200;

max-lease-time 10800;

option subnet-mask 255.255.255.0;

option routers 192.168.1.1;

option domain-name-servers 192.168.1.1, 172.17.102.200;

option domain-name "threeroomco.com";

subnet 192.168.1.0 netmask 255.255.255.0 {

 range 192.168.1.50 192.168.1.150;

}

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

default-lease-tim

max-lease-time

default-lease-time

max-lease-time

default-lease-tim

max-lease-time

Следующие четыре строки листинга задают глобальные параметры, которые передаются клиенту DHCP, а именно: маска подсети, адрес маршрутизатора (шлюза), адреса серверов DNS и доменное имя. Как вы, вероятно, помните из главы 2, те же сведения используются при установке статического IP-адреса компьютера. Несмотря на то что в листинге указаны IP-адреса, вы можете также использовать доменные имена узлов, но при этом необходимо быть уверенным, что сервер DNS работает корректно и связь с ним надежна. Если вы зададите доменные имена, то перед передачей их клиенту сервер DHCP будет преобразовывать их в IP-адреса. Для параметров, не указанных в листинге 5.1, используются значения по умолчанию. При необходимости их можно переназначить явно. Как видно на рис. 5.1, определение параметра заканчивается символом

;

dhcpd.conf

• 

filename "имя_файла"

dhcpd

filename

• 

next-server "имя_узла"

filename

• 

server-name "имя_узла"

• 

boot-unknown-clients флаг

dhcpd

false

host

• 

option broadcast-address IP-адрес

• 

get-lease-hostnames флаг

true

dhcpd

false

• 

use-host-decl-names флаг

get-lease-hostnames

true

dhcpd

host

true

На заметку

Параметры

get-lease-hostnames

и

use-host-decl-names

определяют, должен ли сервер DHCP предоставлять клиентам доменные имена. Несмотря на то что при использовании

get-lease-hostnames dhcpd

обращается к серверу DNS для получения доменного имени, ни один из этих двух параметров не влияет на работу сервера DNS. Если вы хотите, чтобы при обращении к клиенту DHCP посредством доменного имени обеспечивалась достаточная надежность, вам надо сконфигурировать сервер DHCP так, чтобы он выделял компьютеру фиксированный IP-адрес, или принять меры для организации совместной работы серверов DHCP и DNS.

В файле

dhcpd.conf

option

dhpcd.conf

В большинстве случаев параметры указываются в начале файла

dhcpd.conf

В листинге 5.1 представлена чрезвычайно простая конфигурация DHCP, в которой определяется один диапазон IP-адресов. Для указания диапазона адресов используется декларация subnet, которая имеет следующий вид:

subnet 192.168.1.0 netmask 255.255.255.0 {

 range 192.168.1.50 192.168.1.150;

}

Данная декларация указывает на то, что сервер действует в сети 192.168.1.0/24. Очевидно, что компьютер должен иметь сетевой интерфейс, с которым связан адрес из этой сети. В пределах данной сети распространяются широковещательные запросы, передаваемые клиентами и обслуживаемые сервером DHCP. Декларация range определяет диапазон IP-адресов, из которого сервер выбирает адреса, предоставляемые клиенту. В данном примере это адреса 192.168.1.50-192.168.1.150. При необходимости можно использовать любой диапазон, из указанной сети (192.168.1.0/24), важно, чтобы в него не попадали статические IP-адреса компьютеров, в том числе адрес самого сервера DHCP.

В файле

dhcpd.conf

subnet

dhcpd

subnet

dhcpd.conf

subnet

subnet 172.20.30.0 netmask 255.255.255.0 {

}

Внимание

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

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

dhcpd

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

Тем не менее бывают ситуации, при которых необходимо настраивать систему DHCP так, чтобы клиентам выделялись фиксированные адреса. Подобным образом приходится поступать в том случае, если на компьютере, выполняющем функции клиента DHCP, работает какой-либо сервер. Использование фиксированных адресов упрощает диагностику сети; в этом случае, вызывая команду

ping

dhcpd

dhcpd

dhcpd

MAC-адрес используется для организации сетевого взаимодействия на самом низком уровне. При использовании сетевых карт Ethernet MAC-адрес состоит из шести байтов, значения которых обычно представляются шестнадцатеричными числами и разделяются двоеточиями, например 00:80:C8:FA:3B:0A. Каждый пакет, передаваемый устройством Ethernet по сети, содержит MAC-адрес этого устройства, поэтому программа

dhcpd

На заметку

Первые три байта MAC-адреса Ethernet содержат код производителя сетевой карты; остальные три байта устанавливает предприятие, выпускающее Ethernet-карты. Информацию о кодах производителей можно найти по адресу

http://www.coffer.com/mac_find/

или

http://www.cavebear.com/CaveBear/Ethernet/vendor.html

. Для настройки DHCP эти сведения не требуются, но вы можете воспользоваться ими, выясняя расположение компьютеров по широковещательным запросам клиентов DHCP. Заметьте, что производитель Ethernet-карты и производитель компьютера — это, как правило, разные компании.

Для того чтобы программа

dhcpd

При работе с Linux и другими подобными UNIX системами MAC-адрес можно определить с помощью команды

ifconfig

ifconfig eth0

ifconfig

ifconfig

eth0 Link encap:Ethernet HWaddr 00:80:C6:F9:3B:BA

MAC-адрес следует за ключевым словом

HWaddr

Используя Windows 2000, вы можете выяснить MAC-адрес посредством программы

IPCONFIG

ifconfig

IPCONFIG /ALL

Physical Address : 00-50-BF-19-7E-99

В Windows Me используется программа

WINIPCFG

IPCONFIG

Рис. 5.1.

WINIPCFG

Если клиент DHCP расположен на компьютере Macintosh и выполняется в системе MacOS Classic, вы найдете MAC-адрес в окне TCP/IP Control Panel. После щелчка на кнопке Info отобразится диалоговое окно TCP/IP Info, в котором выводится MAC-адрес. В MacOS X данная информация доступна в диалоговом окне Network, показанном на рис. 5.2.

Рис. 5.2. В системе MacOS X MAC-адрес отображается в диалоговом окне Network

Аналогичные средства, позволяющие определить MAC-адрес, имеются и в других операционных системах; для того чтобы использовать соответствующие команды, надо ознакомиться с описанием конкретной системы.

MAC-адрес клиента также можно определить с помощью сервера DHCP. Для этого необходимо, чтобы средства поддержки стека протоколов на клиентском компьютере работали исправно. Сконфигурируйте клиент для работы с сервером DHCP так, чтобы после загрузки клиент получил от сервера динамический IP-адрес. Затем ознакомьтесь с содержимым файла аренды (обычно это файл

/var/lib/dhcp/dhcpd.leases

lease 192.168.1.50 {

 starts 4 2002/07/19 21:37:20;

 ends 4 2002/07/19 23:17:20;

 binding state active;

 next binding state free;

 hardware ethernet 00:50:56:82:01:03;

}

В приведенной записи указаны IP-адрес, выделенный клиенту, время начала и завершения аренды, а также прочая информация, в том числе MAC-адрес (

hardware ethernet 00:50:56:82:01:03

MAC-адреса могут также содержаться в файле протокола Linux (обычно это файл

/var/log/messages

dhcpd

# grep dhcpd /var/log/messages | tail -n 1

Jul 19 18:27:38 speaker dhcpd: DHCPACK on 192.168.1.50 to

00:50:56:82:01:03 via eth0

Эту команду можно выполнить сразу после того, как сервер DHCP выделит IP-адрес клиенту. Если вы не знаете IP-адреса, присвоенного клиенту, вы рискуете ошибочно определить MAC-адрес. Так может случиться, если после запроса интересующего вас компьютера какой-то клиентов обратится к серверу DHCP для того, чтобы продлить аренду. Зная IP-адрес, проверьте запись в файле протокола. Если адрес не совпадает, просмотрите другие записи, задавая значения опции

-n

tail

И, наконец, независимо от того, использует ли клиент статический IP-адрес или получил адрес от сервера DHCP, вы можете определить MAC-адрес с помощью команды

arp

arp

# arp 192.168.1.50

Address HWtype HWaddress Flags Mask Iface

192.168.1.50 ether 00:50:56:82:01:03 C eth0

Не исключено, что перед вызовом

arp

ping

ping -с 192.168.1.50

Для того чтобы программа

dhcpd

host

subnet

host

host teela {

 hardware ethernet 00:05:02:a7:76:da;

 fixed-address 192.168.1.2;

}

Декларация начинается с ключевого слова

host

use-host-decl-names

hardware

token-ring

fixed-address

range

В файле

dhcpd.conf

dhcpd.conf

range

host

host

subnet

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

hardware

fixed-address

host

option host-name "имя"

get-lease-hostnames

use-host-decl-names

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

host

group

group {

 get-lease-hostnames true;

 host teela {

  hardware ethernet

  fixed-address 192.168.1.2;

 }

 host nessus {

  hardware ethernet 00:50:BF:19:7E:99;

  fixed-address

 }

}

group {

 use-host-decl-names true;

 host hindmost {

  hardware ethernet 00:50:56:81:01:03;

  fixed-address 192.168.1.4;

 }

 host louiswu {

  hardware ethernet

  fixed-address 192.168.1.5;

 }

}

Имена, предоставляемые первым двум клиентам (

teela

nessus

hindmost

louiswu

host

filename

next-server

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

get-lease-hostnames

Система NetBIOS, являющаяся основой для протоколов SMB/CIFS, использует для решения стоящих перед ней задач набор структур и инструментов, действующих на базе протоколов TCP/IP. (Подробно протоколы SMB/CIFS, будут рассматриваться в главе 7.) Сервер DHCP можно настроить так, что он будет предоставлять информацию некоторым из этих структур, выполняющихся на клиентских компьютерах под управлением Windows. В результате повысится эффективность работы системы. Для этого в состав файла

dhcpd.conf

• 

option netbios-name-servers адреса_серверов

option netbios-name-servers

dhcpd.conf

• 

option netbios-node-type код_типа

• 

option netbios-dd-server адрес_сервера

• 

option netbios-scope строка

group

Если сервер DHCP предоставляет IP-адреса Windows-клиентам, целесообразно использовать первые два из рассмотренных выше параметров как глобальные. (Пакет Samba в системе Linux не использует значения, предоставляемые DHCP; они предназначены в основном для клиентов Windows). Например, вы можете включить в начало файла

dhcpd.conf

option netbios-name-servers 192.168.1.1;

option netbios-node-type 8;

Чтобы убедиться, что компьютеры под управлением Windows используют эту информацию, надо проверить, установлена ли опция Use DHCP for WINS Resolution в диалоговом окне TCP/IP Properties (рис. 5.3). Если вы выберете опцию Disable WINS Resolution, система вовсе не будет использовать WINS. Установив опцию Enable WINS Resolution, вы сможете вручную задать IP-адрес сервера WINS.

Рис. 5.3. Клиенты Windows можно непосредственно настраивать для использования NetBIOS-данных, предоставляемых сервером DHCP

Если вы хотите, чтобы к клиенту DHCP мог непосредственно обратиться любой узел сети, добиться этого можно двумя способами. Вы можете сконфигурировать сервер DHCP так, чтобы он предоставлял клиенту фиксированный IP-адрес (необходимые действия обсуждались ранее в этой главе), либо настроить серверы DHCP и DNS для взаимодействия друг с другом; в этом случае записи сервера DNS будут обновляться, отражая текущее назначение адресов клиентам DHCP. Если адреса клиентов DHCP изменяются редко, а обращение к ним выполняется только из локальной сети, второй способ предпочтительнее первого. Если к компьютеру предполагается доступ из Internet, этот способ мало пригоден. Если запись в конфигурационном файле DNS изменится, то для распространения изменений по Internet потребуется определенное время. В течение этого времени могут быть предприняты попытки обращения к компьютеру по его старому адресу.

В версиях

dhcpd

dhcpd

На заметку

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

Для организации взаимодействия с сервером DNS используется параметр

ddns-update-style

ad-hoc

interim

none

ddns-update-style

dhcpd.conf

ad-hoc

interim

Внимание

Оба метода обновления DNS работают только в том случае, если сервер DNS воспринимает информацию об обновлении. Соответствующая конфигурация сервера DNS будет обсуждаться в главе 18.

При использовании метода ad-hoc имя узла задается одним из четырех способов. Эти способы с учетом их приоритета перечислены ниже.

1. Если в декларации

host

ddns-hostname

2. Если клиент передает полностью определенное доменное имя (имя, состоящее из имени узла и имени домена), сервер DHCP принимает содержащееся в нем имя узла.

3. Если клиент передает имя узла без указании имени домена, это имя воспринимается сервером DHCP.

4. Используется имя клиента, указанное в декларации

host

В любом случае применяется только локальное имя компьютера. Если его невозможно определить ни одним из этих способов, сервер DHCP не предпринимает попыток обновить данные сервера DNS. Если сервер DHCP имеет в своем распоряжении имя узла, он объединяет его с именем домена, заданным с помощью параметра

ddns-domainname

domain-name

Сформированное полное доменное имя сервер DHCP использует для изменения данных сервера DNS. Сначала обновляется запись

А

А

Метод interim во многом похож на метод ad-hoc, но он предоставляет возможность клиенту обновить запись

А

dhcpd.conf

allow client-updates

ignore client-updates

Если сервер DHCP сконфигурирован так, что клиентам разрешено обновлять данные сервера DNS, то для создания записи PTR сервер DHCP использует полное доменное имя, переданное клиентом. Если действия клиента по обновлению данных сервера DNS запрещены, сервер DHCP создает полное доменное имя из имени узла, полученного от клиента, и имени домена, заданного в файле

dhcpd.conf

А

PTR

Если клиенту запрещено изменять записи сервера DNS, то метод interim дает те же результаты, что и метод ad-hoc. Если вмешательство клиента в работу сервера DNS разрешено, ситуация несколько изменяется. Клиент может задать имя домена, отличное от того, которое указано при настройке сервера DHCP. Предположим, например, что в конфигурационном файле сервера DHCP указано имя домена

threeroomco.com

threeroomco.com

dino.pangaea.edu

PTR

dino.pangaea.edu

Динамические средства DNS

Многие пользователи получают доступ к Internet через кабельные модемы и DSL-соединения. Для присвоения их компьютерам IP-адресов используются DHCP или другие протоколы. Если в подобной ситуации вам потребуется поставить в соответствие своему компьютеру фиксированное доменное имя, вы не сможете организовать совместную работу DHCP и DNS в системе Linux. В этом случае целесообразно использовать один из бесплатных пакетов динамической поддержки DNS. (Если подобный пакет распространяется на коммерческой основе, цена его обычно небольшая.

Серверы динамической поддержки DNS обеспечивают преобразование имен узлов Internet. На своем компьютере вы можете установить клиентский пакет, который при изменении IP-адреса будет обращаться к серверу DNS провайдера. В результате вы получите возможность использовать фиксированное доменное имя, принадлежащее либо домену, поддерживаемому динамическими средствами DNS провайдера, либо вашему собственному домену. Этому имени будет соответствовать IP-адрес вашего компьютера. Многие провайдеры, предоставляющие услуги динамической DNS, распространяют программы, написанные на Perl или другом языке сценариев, большинство из которых могут выполняться в среде Linux.

Списки провайдеров, предоставляющие услуги динамической DNS, можно найти по адресам

http://www.technopagan.org/dynamic/

,

http://www.geocities.com/kiore_nz/

и

http://dns.highsynth.com

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

Протокол DHCP может успешно использоваться как в больших, так и в малых сетях. Сосредоточив информацию о конфигурации на одном сервере, вы существенно упростите настройку сетевых средств на клиентских машинах, работающих под управлением различных операционных систем. Следует однако помнить, что сервер DHCP также необходимо настраивать и поддерживать; если такой сервер будет сконфигурирован неверно или если он выйдет из строя, клиентские машины не смогут нормально работать в сети. Сервер DHCP можно настроить так, что он будет выделять клиентам произвольные IP-адреса из пула, либо указать при настройке, что определенным узлам сети должны предоставляться фиксированные адреса. Если вы хотите, чтобы клиенты DHCP были доступны по именам, вам необходимо использовать фиксированные адреса. Доменные имена можно связывать и с динамически выделяемым IP-адресами; для этого надо организовать совместную работу серверов DHCP и DNS. Соответствующие средства реализованы в версии 3 сервера DHCP для Linux.

В системе Linux обычно используется локальная аутентификация. Пользователь вводит имя и пароль, а компьютер ищет соответствующие данные в своей базе и принимает решение о том, следует ли зарегистрировать пользователя в системе. Подобный принцип идентификации применяется и в серверах (например, в POP- и FTP-серверах), для работы с которыми необходимо указать пароль. Если пользователи должны регистрироваться на различных компьютерах, такой подход мало приемлем, так как поддержка учетных записей на различных узлах сети отнимает у администратора слишком много времени. Более того, если пароли передаются по сети (а они часто пересылаются в незашифрованном виде), появляется реальная опасность перехвата пароля и использования его для незаконного доступа к системе. Эти проблемы призвана решить система Kerberos. В этой системе поддерживается централизованная база данных о пользователях. При выполнении аутентификации компьютеры обращаются к этой базе, а кодирование информации исключает возможность перехвата секретных данных.

На заметку

Название Kerberos пришло из греческой мифологии: так звали трехглавого пса, который охранял вход в царство мертвых. Несмотря на то что в английском языке имя этого мифологического персонажа пишется как Cerberus, разработчики использовали для своей системы греческий вариант имени. Изображение трехглавого пса можно найти на многих Web-страницах, посвященных системе Kerberos.

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

Работа системы Kerberos основана на использовании протокола Kerberos. Это чрезвычайно сложный протокол; чтобы обеспечить его работу, надо сконфигурировать не только сервер Kerberos, но и другие клиенты и серверы, присутствующие в сети. Если вы не хотите ограничиваться установкой простейших вариантов системы Kerberos, а собираетесь решать более сложные задачи, вам придется изучить дополнительные документы, специально посвященные работе системы Kerberos. Необходимую информацию можно получить, обратившись на главный Web-узел Kerberos по адресу

http://web.mit.edu/kerberos/www/

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

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

Kerberos представляет собой межплатформенную систему. Клиенты и серверы Kerberos созданы для Linux и других UNIX-подобных систем, Windows, MacOS и т.д. (Система Kerberos, реализованная Microsoft, не всегда совместима со стандартной версией системы. На Web-странице Kerberos, поддерживаемой MIT, расположены ссылки на другие реализации Kerberos, которые могут работать в Windows и свободны от данного недостатка.) Межплатформенная совместимость является чрезвычайно важной характеристикой во многих средах.

Для эффективного использования Kerberos в приложениях должны быть специально предусмотрены средства взаимодействия с этой системой. Например, почтовый клиент и сервер, обменивающиеся данными по протоколу POP, должны поддерживать аутентификацию Kerberos (в противном случае им придется применять внутренние средства аутентификации). В данной главе рассматривается конфигурация системы Kerberos, предназначенной для работы в среде Linux. Несмотря на то что в реальной сети необходимо обеспечивать взаимодействие с другими операционными системами, здесь не будет рассматриваться настройка клиентов Kerberos для Windows, MacOS и других платформ.

Централизованные и распределенные вычисления

15 конце 1960-х появились системы, позволяющие нескольким пользователям работать на одном компьютере. В особенности такая тенденция стала заметной в 1980-е годы. В частности, UNIX была создана как многопользовательская система. Многопользовательские компьютеры размещались в машинном зале, а пользователи работали на алфавитно-цифровых терминалах, а впоследствии на X-терминалах, обеспечивающих работу с графикой. По мере удешевления оборудования рабочие станции стали размещать на рабочих местах пользователей. Этот процесс существенно ускорился при появлении персональных компьютеров x86.

В настоящее время во многих сетях используется децентрализованная распределенная модель вычислений; рабочие станции функционируют под управлением Windows, MacOS, Linux и других разновидностей UNIX, Основная нагрузка по обработке данных лежит именно на них, но в процессе работы эти компьютеры могут обращаться по сети к различным серверам. Подобные сети работают гораздо надежнее, чем системы с одним мэйнфреймом, так как при выходе из строя какого-либо из серверов остальная часть сети продолжает функционировать. Благодаря использованию распределенных вычислений каждый компьютер увеличивает определенную часть обрабатывающих ресурсов, как минимум на ресурсы процессора своей рабочей станции, При работе в локальной сети каждый пользователь "привязан" к своему компьютеру, поскольку именно на нем хранится информация о пользовательском имени и пароле, используемая при аутентификации. Это — одна из проблем, решаемая с помощью Kerberos.

B настоящее время компьютеры x86 обеспечивают гораздо более высокую производительность, чем мэйнфреймы, применявшиеся двадцать лет назад. В результате появилась возможность использовать их для централизованных вычислений. Часто в системе Linux выполняется большое количество пользовательских программ. Пользователи могут работать за менее мощными компьютерами, на которых выполняются программы эмуляции терминалов (эти программы будут обсуждаться в главах 13 и 14). При таком подходе снова появляются проблемы, характерные для централизованных вычислений, например, если центральный компьютер выходит из строя, остальные устройства становятся практически бесполезными. Однако, централизованный подход существенно упрощает администрирование системы, и это может рассматриваться как дополнительный аргумент в пользу применения Kerberos.

Для того чтобы эффективно применять средства Kerberos в сети, надо инсталлировать сервер паролей Kerberos, который также называют центром распространения ключей (key distribution center — KDC). Кроме того, необходимо обеспечить поддержку средств Kerberos клиентскими и серверными программами. Программы, настроенные для взаимодействия с Kerberos, часто называют керберизованными приложениями (Kerberized application). Чтобы использовать Kerberos, необходимо понимать, как работает протокол Kerberos и как организуется взаимодействие основных компонентов системы. В данном разделе описаны основные принципы действия протокола Kerberos, а также представлена информация об основных продуктах Kerberos и изложены требования к KDC.

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

Основным компонентом системы Kerberos является KDC. Он отвечает за аутентификацию компьютеров в области (realm) Kerberos. Обычно область Kerberos совпадает с некоторым доменом или поддоменом Internet. Например, домен

threeroomco.com

THREEROOMCO.COM

REALM1.THREEROOMCO.COM

REALM1.THREEROOMCO.СОМ

В процессе работы система Kerberos выдает билеты на использование различных служб. Подобно авиационным или театральным билетам, билеты Kerberos предоставляют право пользования некоторыми услугами. Существуют два основных типа билетов, о которых будет сказано ниже.

Сервером Kerberos будем называть либо компьютер, на котором выполняется серверная программа Kerberos, либо саму программу, т.е. KDC. Клиент Kerberos — это компьютер либо программа, которые получают билет от сервера Kerberos. Обычно считается, что действия системы Kerberos инициирует пользователь, который отправляет запрос на получение услуг от некоторого сервера приложения (например, сервера печати).

Kerberos предоставляет билеты принципалам, в роли которых выступают пользователи либо серверные программы. Для описания принципала применяется идентификатор, состоящий из трех компонентов: основы (primary), экземпляра (instance) и области (realm). Этот идентификатор записывается в формате

основа/экземпляр@область

ftp

fluffy

admin

fluffy@THREEROOMCO.COM

fluffy/admin@THREEROOMCO.СОМ

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

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

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

На заметку

Многие приложения, использующие пароль для доступа к удаленным системам, предоставляют пользователю возможность сохранения пароля. Такое поведение типично, например, для почтовых серверов (POP и IMAP). Пользоваться этой возможностью крайне нежелательно, так как в случае взлома рабочей станции пароль окажется в руках злоумышленника. При работе в сети возникает также проблема смены пароля. Новый пароль приходится задавать сразу в нескольких программах. Обе проблемы позволяет решить Kerberos.

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

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

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

2. Рабочая станция (клиент Kerberos) передает имя пользователя KDC и запрашивает TGT (ticket-granting ticket — билет на получение билета). Этот запрос обрабатывается специальным компонентом Kerberos, который называется TGS (ticket-granting service — служба получения билета).

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

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

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

6. Клиент принимает билет на получение услуг, но не предпринимает попытки расшифровать его (действия с этим билетом также прозрачны для пользователя).

7. Клиент передает билет на получение услуг целевому серверу. Этот билет рассматривается как запрос на инициализацию сеанса передачи данных.

8. Сервер расшифровывает билет, пользуясь для этого паролем. Попытка расшифровки будет успешной только в том случае, если билет был корректно закодирован KDC. Если запрос корректен (билет получен от действительного пользователя, успешно расшифрован и т.д.), сервер использует код сеанса для кодирования ответа клиенту.

9. Клиент получает ответ сервера. Если данные корректны, клиент предполагает, что сервер аутентифицирован, завершает процедуру установления соединения и начинает передачу информации. Информация передается только в том случае, если от сервера получен допустимый ответ.

С этого момента процесс обмена данными происходит так, как будто система Kerberos не используется, за исключением того, что в составе керберизованных приложений действуют средства кодирования и декодирования данных (в обычных приложениях такие средства отсутствуют). Со временем срок действия TGT и билета на получение услуг истекает, но это вряд ли повлияет на обмен информацией, так как срок действия билетов обычно устанавливается равным нескольким часам. Если же такая ситуация возникла в течение сеанса, билеты должны быть обновлены.

ВНИМАНИЕ

Как видно из описанной выше процедуры, в составе билетов содержатся временные отметки. Если таймеры компьютеров, участвующих во взаимодействии, установлены по-разному, обмен данными может не состояться. В некоторых случаях несоответствие системного времени может привести к снижению уровня безопасности системы. Поэтому необходимо синхронизировать таймеры на всех компьютерах, входящих в состав сети Kerberos. Сделать это можно с помощью сервера NTP (Network Time Protocol — сетевой протокол времени), описанного в главе 10.

Зная принципы работы системы Kerberos, можно сформулировать требования к ее компонентам. Очевидно, что с точки зрения безопасности сети KDC является чрезвычайно важным компонентом системы. Доступ к серверу (равно как и физический доступ к компьютеру, на котором он выполняется) должен иметь только администратор системы. Необходимо уделять внимание своевременному обновлению версий программного обеспечения. Поскольку KDC используется в работе многих серверов, необходимо продумать план его восстановления в случае неисправности. Создавайте резервные копии данных KDC и держите наготове компьютер, где можно было бы запустить KDC в случае выхода из строя машины, на которой выполняется основной сервер. Имеет смысл создать ведомый, или резервный KDC, который получал бы конфигурационные данные от ведущего, или основного KDC, и в случае выхода из строя последнего мог бы взять на себя обязанности по обслуживанию клиентов и серверов в сети.

Характеристики аппаратных средств, необходимых для работы KDC, определяются размерами сети, а именно числом компьютеров и пользователей. Для небольших сетей, насчитывающих порядка двух десятков узлов, для KDC подойдет низкоуровневый компьютер. Система, содержащая процессор Pentium с низким быстродействием, 32 Мбайт оперативной памяти и жесткий диск объемом в несколько сотен мегабайт, будет более чем достаточна для работы KDC в такой сети. Если же к сети подключены сотни, а тем более тысячи машин, потребуется более мощный компьютер, обладающий быстродействующим процессором и обеспечивающий высокую скорость обмена по сети. Размещая KDC в сети, надо выбрать его расположение так, чтобы обеспечивалась максимальная надежность, а время доставки данных клиентам и серверам было минимальным. Например, если сеть состоит из нескольких отдельных сегментов, желательно поместить в каждом из сегментов свой KDC. Если один KDC будет обслуживать несколько сетевых сегментов, то при сбое в работе маршрутизаторов взаимодействие клиентов с серверами станет невозможным.

Наибольшей популярностью пользуется пакет Kerberos, доступный по адресу

http://web.mit.edu/kerberоs/www/

Подобно X Window, Kerberos распространяется в исходных кодах. Кроме того, существуют варианты системы, созданные на основе кода MIT, которые предоставляются на коммерческой основе. Одна из разновидностей Kerberos создана в Швеции Королевским технологическим институтом (Royal Institute of Technology) и доступна по адресу

http://www.pdc.kth.se/kth-krb/

krb4

binaries

Центр параллельных вычислений (Center for Parallel Computers) реализовал систему Kerberos, известную под названием Heimdal; ее коды расположены по адресу

http://www.pdc.kth.se/heimdal/

В настоящее время средства поддержки Kerberos включаются в состав большинства дистрибутивных пакетов Linux. В частности, Debian 2.2 комплектуется eBones и Heimdal, в состав Mandrake 8.1 и Red Hat 7.2 входит Kerberos V5, a SuSE 7.3 комплектуется Heimdal. В поставку систем Caldera 3.1, Slackware 8.0 и TurboLinux 7.0 средства Kerberos не входят, но вы можете включить их, скомпилировав исходные коды либо установив пакет, предназначенный для другой версии Linux.

На заметку

В последующих разделах данной главы описывается система Kerberos V5, разработанная MIT. Версия Kerberos V4 отличается от нее некоторыми особенностями конфигурации. Некоторые особенности работы систем, созданных на базе Kerberos V5, могут не совпадать с описанными здесь. Работая над данной главой, я использовал пакет Kerberos V5 в системе Red Hat, в тексте главы приводятся ссылки на исходные коды MIT.

Основой сети Kerberos является сервер Kerberos, или KDC. Как и для большинства серверов Linux, для настройки KDC используется текстовый файл, находящийся в каталоге

/etc

На заметку

Некоторые действия, рассматриваемые в данном разделе, приходится выполнять при настройке клиентов Kerberos и серверов приложений. Например, для всех систем задаются области Kerberos.

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

configure

make

make install

configure

--enable-shared

krb5-libs

krb5-server

krb5-workstation

Основным конфигурационным файлом сервера Kerberos является файл

/etc/krb5.conf

krb5.conf

Листинг 6.1. Пример файла

krb5.conf

[logging]

default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults]

ticket_lifetime = 24000

default_realm = THREEROOMCO.COM

dns_lookup_realm = false

dns_lookup_kdc = false

[realms]

THREEROOMCO.COM = {

 kdc = kerberos.threeroomco.com:88

 kdc = kerberos-1.threeroomco.com:88

 kdc = kerberos-2.threeroomco.com:88

 admin_server = kerberos.threeroomco.com:749

 default_domain = threeroomco.com

}

[domain_realm]

.threeroomco.com = THREEROOMCO.COM

threeroomco.com = THREEROOMCO.COM

outsider.threeroomco.com = PANGAEA.EDU

[kdc]

profile = /var/kerberos/krb5kdc/kdc.conf

Каждая строка внутри раздела состоит из имени переменной, за которой следуют знак равенства (символ "

=

[realms]

THREEROOMCO.COM

На заметку

Большинство разделов, содержащихся в рассмотренном конфигурационном файле, используется для настройки серверов приложений и клиентов Kerberos. Не нужны лишь разделы

[login]

и

[kdc]

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

[appdefaults]

.

KDC также использует собственный конфигурационный файл

kdc.conf

krb5.conf

kdc.conf

krb5.conf

Как правило, для определения областей в файлы

krb5.conf

kdc.conf

В файле

krb5.conf

[realms]

[domain_realm]

В рассмотренном примере раздел

[realms]

THREEROOMCO.СОМ

kerberos

kerberos-n

admin-server

default_domain

В одном файле

krb5.conf

[realms]

Записи, содержащиеся в разделе

[domain_realm]

threeroomco.com

threeroomco.com

THREEROOMCO.СОМ

outsider.threeroomco.com

PANGAEA.EDU

Совет

При настройке DNS-сервера целесообразно создать записи CNAME, определив с их помощью имена узлов, указанные в

krb5.conf

и в других конфигурационных файлах. Это поможет вам быстро ввести в строй резервный KDC, расположенный на другом компьютере, не редактируя конфигурационные файлы. Кроме того, для обращения к KDC можно использовать виртуальный IP-адрес. В этом случае компьютер, поддерживающий протокол NAT (Network Address Translation — преобразование сетевых адресов), определяется на DNS-сервере как KDC, но при обращении к нему он перенаправляет запрос тому компьютеру, на котором размещается реальный KDC. Это также позволяет перемещать KDC с одного компьютера на другой, не изменяя записи DNS.

В файле

kdc.conf

krb5.conf

kdc.conf

[realms]

kdc.conf

EXAMPLE.COM

[realms]

[kdcdefaults]

Листинг 6.2. Пример файла

kdc.conf

[kdcdefaults]

acl_file = /var/kerberos/krb5kdc/kadm5.acl

dict_file = /usr/share/dict/words

admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab

[realms]

THREEROOMCO.COM = {

 master_key_type = des-cbc-crc

 supported_enctypes = des-cbc-crc:normal des3-cbc-raw:normal \

  des3-cbc-shal:normal des-cbc-crc:v4 des-cbc-crc:afs3

}

Для контроля доступа к Kerberos используется основной ключ (master key), который по сути представляет собой пароль и хранится в stash-файле. Stash-файл — это специальный файл, который читает сервер при запуске и определяет, разрешено ли его выполнение. Если stash-файл отсутствует, основной ключ необходимо вручную вводить при запуске сервера.

Поскольку stash-файл содержит чрезвычайно важную информацию, он должен храниться на том же диске, что и KDC, и быть доступным для чтения только пользователю

root

yiwttd

yi9Wt%Td

Для создания основного ключа и записи его в stash-файл используется команда

kdb5_util

# kdb5_util create -r THREEROOMCO.COM -s

Initializing database '/var/kerberos/krb5kdc/principal' for

realm 'THREEROOMCO.COM',

master key name 'K/M@THREEROOMCO.COM'

You will be prompted for the database Master Password.

It is important that you NOT FORGET this password.

Enter KDC database master key:

Re-enter KDC database master key to verify:

На заметку

Из соображений безопасности символы, вводимые в ответ на приглашение, не отображаются на экране.

В процессе выполнения утилита

kdb5_util

/var/kerberos/krb5kdc

/usr/local/var/krb5kdc

kdb5_util

• Stash-файл с именем

.k5.имя_области

.k5stash

• Файлы

principal

principal.ok

principal

principal.db

• Файлы

principal.kadm5

principal.kadm5.lock

Если вы по каким-то причинам не хотите создавать stash-файл, то, вызывая

kdb5_util

s

Отредактировав конфигурационные файлы Kerberos и вызвав

kdb5_util

Информация о принципалах Kerberos хранится в формате ACL (Access Control Lists — списки контроля доступа) в файле, имя которого определяет запись

acl_file

kdc.conf

Принципал_Kerberos Полномочия Целевой_принципал

На заметку

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

Первое поле (Принципал Kerberos) содержит идентификатор принципала (правила формирования идентификатора принципала были рассмотрены ранее). Любой компонент идентификатора можно заменить символом "

*

*/admin@THREEROOMCO.СОМ

admin

THREEROOMCO.СОМ

Второе поле (Полномочия) — это код ACL, соответствующего принципалу. Типы полномочий задаются с помощью односимвольных кодов. Назначение символов описано в табл. 6.1. Объединяя разные коды, можно задать различные типы доступа. Например, код

ali

Таблица 6.1. Коды полномочий в файле ACL

Последнее поле (Целевой принципал) может отсутствовать. Оно определяет имена принципалов, к которыми применяются заданные полномочия. Например, вы можете ограничить возможности пользователя по доступу и модификации прав конкретных принципалов. Как и при определении принципала Kerberos, в идентификаторе целевого принципала можно использовать символ "

*

Рассмотрим в качестве примера следующую запись:

*/admin@THREEROOMCO.COM *

Эта запись предоставляет всем принципалам экземпляра

admin

Для администрирования базы пользователей Kerberos применяются программы

kadmin

kadmin.local

kadmin

kadmin.local

kadmin.local

kadmin

При запуске программ

kadmin

kadmin.local

admin/admin@THREEROOMCO.COM

addprinc

# kadmin.local

Authenticating as principal root/admin@THREEROOMCO.COM with

password.

kadmin.local: addprinc admin/admin@THREEROOMCO.COM

WARNING: no policy specified for admin/admin@THREEROOMCO.COM;

defaulting to no policy

Enter password for principal "admin/admin@THREEROOMCO.COM":

Re-enter password for principal "admin/admin@THREEROOMCO.COM":

Principal "admin/admin@THREEROOMCO.COM" created.

На заметку

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

После создания принципала, предназначенного для администрирования, вам надо сформировать для него ярлык (keytab). Ярлык — это ключ, который Kerberos использует для расшифровки административных билетов. Вам нет необходимости задавать этот ключ; Kerberos сгенерирует его самостоятельно. Достаточно лишь указать системе на необходимость выполнения этого действия, для чего следует в среде

kadmin.local

ktadd

kadmin.local: ktadd -k /var/kerberos/krb5kdc/kadm5.keytab \

kadmin/admin kadmin/changepw

Для указания файла, в котором должен храниться ярлык, используется опция

-k

kdc.conf

-k

kadmin/admin

kadmin/changepw

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

addprinc

fluffy@THREEROOMCO.COM

kadmin.local: addprinc fluffy@THREEROOMCO.COM

Для серверов желательно использовать опцию

-randkey

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

имя_сервера/имя_узла@имя_области

pop

ftp

host

host

ktadd

-k

kadmin

ktadd

Вероятнее всего, вы решите создать принципала для каждого KDC. Идентификаторы таких принципалов создаются в формате

host/имя_узла@имя_области

host/kerberos-1.threeroomco.com/THREEROOMCO.COM

Окончив работу с программой

kadmin

quit

К этому моменту компоненты Kerberos настроены и могут быть запущены. Для запуска сервером можно использовать способы, описанные в главе 4. Если пакет Kerberos поставлялся вместе с вашей системой, для вероятно, существует сценарий запуска SysV. Сценарий для KDC обычно называется

krb5kdc

kadmin

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

krb5kdc

kadmin

/etc/rc.d/rc.local

Ведомый KDC настраивается практически так же, как и ведущий. Вам надо отредактировать файлы

krb5.conf

kdc.conf

kdb5_util

ktadd

kadmin.local

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

kpropd.acl

/var/kerberos/krb5kdc

/usr/local/var/krb5kdc

host/kerberos.threeroomco.com@THREEROOMCO.COM

host/kerberos-1.threeroomco.com@THREEROOMCO.COM

Сформировав данный файл для каждого из KDC, надо сконфигурировать ведомый KDC для выполнения двух серверов:

kpropd

klogind

/etc/inetd.conf

krb5_prop stream tcp nowait root /usr/kerberos/sbin/kpropd

kpropd eklogin stream tcp nowait root \

 /usr/kerberos/sbin/klogind klogind -k -c -e

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

xinetd

/etc/services

krb5_prop

eklogin

krb5_prop 754/tcp # Передача данных ведомому

                  # серверу Kerberos

eklogin 2105/tcp  # Удаленная регистрация

                  # с использованием шифрования

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

kprop

cron

Листинг 6.3. Пример сценария, предназначенного для передачи базы данных Kerberos ведомым KDC

# !/bin/sh

/usr/kerberos/sbin/kdb5_util dump

/usr/kerberos/var/krb5kdc/slave_datatrans

/usr/kerberos/sbin/kprop -f

/usr/kerberos/var/krb5kdc/slave_datatrans \

 kerberos-1.mil.threeroomco.com

Настройка KDC — важный этап подготовки системы Kerberos к работе, но сам по себе KDC не осуществляет полезных действий. Для того чтобы система стала работоспособной, необходимо выполнить вторую часть работы — настроить серверы приложений и клиенты Kerberos для взаимодействия с KDC. Данный раздел посвящен настройке серверов приложений, а настройка клиентов будет рассматриваться в следующем разделе.

На заметку

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

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

[realms]

[domain_realm]

krb5.conf

host/имя_узла@имя_области

telnet/имя_узла@имя_области

kadmin.local

addprinc

kadmin.local

kadmin.local: addprinc \

 host/gingko.threeroomco.com@THREEROOMCO.COM

kadmin.local: addprinc \

 telnet/gingko.threeroom.com@THREEROOMCO.COM

kadmin.local: ktadd -k gingko.keytab \

 host/gingko.threeroomco.com telnet/gingko.threeroomco.com

Файл

gingko.keytab

/etc

krb5.keytab

scp

root

ktadd

-k gingko.keytab

Как правило, в состав стандартного пакета Kerberos входят керберизованные серверы и локальные средства аутентификации, например, программы, поддерживающие протоколы Telnet и FTP, а также разновидности

shell

exec

login

inetd

/etc/inetd.conf

klogin stream tcp nowait root /usr/kerberos/sbin/klogind \

 klogind -k -c

eklogin stream tcp nowait root /usr/kerberos/sbin/klogind \

 klogind -k -c -e

kshell stream tcp nowait root /usr/kerberos/sbin/kshd \

 kshd -k -c -A

stream tcp nowait root /usr/kerberos/sbin/ftpd \

 ftpd -a

telnet stream tcp nowait root /usr/kerberos/sbin/telnetd \

 telnetd -a valid

Приведенные выше строки заменяют соответствующие записи в составе файла.

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

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

имя_пользователя@имя_области

kadmin

kadmin.local

На первый взгляд может показаться, что для обращения к серверам приложений Kerberos достаточно иметь соответствующие клиентские программы. На самом деле ситуация выглядит несколько сложнее. Прежде всего, в процессе обмена участвуют специальные утилиты: пользователь должен иметь возможность получить TGT и при необходимости изменить пароль Kerberos. Кроме того, к самим клиент-программам Kerberos предъявляются специальные требования; без поддержки специфических возможностей клиенты Kerberos превращаются в обычные клиентские программы, не обеспечивающие повышенный уровень защиты.

В состав пакета Kerberos входят утилиты, предназначенные для управления паролями и билетами Kerberos. Наиболее важные из них перечислены ниже.

• 

kinit

kinit

kinit

kinit minerva@PANGAEA.EDU

kinit

kinit

• 

klist

kinit

klist

• 

kpasswd

kpasswd

passwd

kpasswd

• 

kdestroy

kdestroy

Совет

Желательно включать вызов

kdestroy

в состав

.logout

,

.xinitrc

и других стандартных файлов, которые выполняются по окончании сеанса работы пользователя в системе. При использовании модулей РАМ (они будут рассматриваться далее в этой главе)

kdestroy

вызывается автоматически.

Как используются перечисленные выше утилиты на практике? В большинстве случаев программы

kinit

kdestroy

klist

$ kinit

Password for fluffy@THREEROOMCO.COM:

$ klist

Ticket cache: FILE:/tmp/krb5cc_500

Default principal: fluffy@THREEROOMCO.COM

Valid starting    Expires           Service principal

10/09/02 14:38:57 10/10/02 00:38:57 krbtgt/THREEROOMCO.COM@\

                                    THREEROOMCO.COM

Kerberos 4 ticket cache: /tmp/tkt500

klist: You have no tickets cached

$ kpasswd

Password for fluffy@THREEROOMCO.COM:

Enter new password:

Enter it again:

Password changed.

$ kdestroy

$ klist

klist: No credentials cache file found (ticket cache

FILE:/tmp/krb5cc_500)

Kerberos 4 ticket cache: /tmp/tkt500

klist: You have no tickets cached

Программа

kinit

klist

krbtgt

klist

klist

kinit

kdestroy

Клиент-программы, ориентированные на работу с Kerberos, выполняются так же, как и их аналоги, не обеспечивающие дополнительную защиту. В большинстве случаев для вызова клиент-программы надо ввести ее имя и имя сервера, с которым необходимо установить соединение. Иногда для использования средств Kerberos приходится задавать некоторые параметры. Например, чтобы избавить пользователя от необходимости указывать имя и пароль при работе с клиентом

telnet

• 

telnet

telnet

telnet

telnet удаленный_узел

-а

-f

• 

rlogin

rlogin

-f

telnet

-а

-f

• 

ftp

На заметку

Программа

ftp

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

• 

rsh

telnet

rlogin

-f

• 

rcp

rcp

• Прочие программы. Здесь рассмотрены лишь описания сетевых инструментов, поставляемых в составе стандартного пакета Kerberos V5. В настоящее время доступны другие керберизованные системы. Очевидно, что для работы с ними необходимо, чтобы средства Kerberos поддерживались как клиентами, так и серверами.

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

-х

su

root

ksu

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

/usr/local/bin

/usr/local/sbin

/usr/kerberos/bin

PATH

PATH

/etc/profile

.bashrc

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

kinit

login.krb5

ksu

Внимание

Рекомендуется перед использованием

login.krb5

сначала проверить программу

kinit

для основных учетных записей, в том числе для записи root. Если

kinit

не работает, не будет работать и

login.krb5

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

login.krb5

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

Процедура регистрации в системе Linux в текстовом режиме включает использование программы

getty

getty

mingetty

mgetty

vgetty

/etc/inittab

/bin/login

/bin/login

login.krb5

/bin/login

# mv /bin/login /bin/login-original

# cp /usr/kerberos/sbin/login.krb5 /bin/login

Если возникнут проблемы с использованием

login.krb5

/bin/login

login

kinit

/etc/passwd

/bin/login

При использовании

su

ksu

• Компьютер, на котором работает

ksu

/etc/krb5.keytab

• Для исполняемого файла

ksu

root

chmod a+s /usr/kerberos/bin/ksu

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

.k5login

.k5users

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

ksu

.k5login

.k5users

*

minerva@THREEROOMCO.COM

/bin/ls

/usr/bin/zip

minerva@THREEROOMCO.COM /bin/ls /usr/bin/zip

После настройки программа

ksu

su

.k5login

.k5users

Если вы хотите непосредственно выполнить некоторую программу, вы можете сделать это с помощью опции

-е имя_программы

/bin/ls

fluffy

fluffy -e /bin/ls

Замена программ

login

su

vlock

xscreensaver

РАМ выполняет роль посредника между программами, которым требуется аутентификация (например, сервером FTP, программой

login

/etc/passwd

/etc/shadow

На заметку

Поддержка Kerberos с помощью РАМ имеет свои ограничения. В частности, если код программы построен так, что программа запрашивает имя пользователя и пароль, ее поведение не изменится при замене РАМ на модуль, поддерживающий Kerberos. Полученные данные программа передаст РАМ, и он предпримет попытку аутентификации с использованием базы данных Kerberos. Так, например, РАМ не устраняет необходимость ввода имени пользователя и пароля при работе с FTP-сервером, но позволяет следить за текущим паролем и приводить его в соответствие с данными для области Kerberos. Если речь идет о керберизованных программах, выполняющих регистрацию пользователя, то такая особенность не является недостатком, так как программы регистрации в любом случае запрашивают пользовательское имя и пароль.

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

• Модуль Деррика Брешера (Derrik Brashier). Этот модуль предназначен для использования совместно с Kerberos V4. Он расположен по адресу

ftp://ftp.dementia.org/pub/pam/

pam_krb4

• Модуль Фрэнка Кусека (Frank Cusack). Модуль РАМ, поддерживающий MIT Kerberos V5 и Heimdal, находится по адресу

http://www.nectar.com/zope/krb/

• Модуль Кертиса Кинга (Curtis King). Этот модуль доступен по адресу

ftp://ftp.dementia.org/pub/pam/

pam_krb5-1.1.3.tar.gz

• Модуль для системы Red Hat. Модуль РАМ Kerberos V5 входит в состав дистрибутивного комплекта Red Hat под именем

pam_krb5

• Модули для системы Debian. В Debian и других подобных системах работа с Kerberos V5 и Heimdal поддерживается соответственно модулями

libpam-krb5

libpam-heimdal

http://ftp.nl.debian.org/debian/pool/non-US/main/libp/libpam-krb5/

http://ftp.nl.debian.org/debian/pool/non-US/main/libp/libpam-heimdal/

При инсталляции РАМ для поддержки Kerberos вы по сути устанавливаете средства, с помощью которых РАМ настраивается для выполнения конкретной задачи. В состав модуля РАМ входит одна или несколько библиотек, которые располагаются в каталогах

/lib/security

/usr/lib/security

pam_krb5.so

pam_krb5afs.so

/etc/pam.d

/etc/pam.d/login

login

/usr/share/doc/pam_krb5-версия/pam.d

/etc/pam.d

• 

login

login

login.krb5

login

• 

gdm

• 

xdm

• 

su

sudo

su

su

sudo

sudo

• 

passwd

passwd

• 

vlock

vlock

vlock

• 

xlock

xscreensaver

vlock

Возможно, вы захотите настроить и другие программы для взаимодействия с Kerberos; при этом вам придется отредактировать соответствующие конфигурационные файлы РАМ. Если какой-то из серверов уже сконфигурирован для работы с Kerberos, вам не надо модифицировать файлы РАМ. Например, если у вас уже установлен керберизованный FTP-сервер, вам не следует изменять файл

/etc/pam.d/ftp

Если некоторая программа использует РАМ, то для обеспечения ее совместной работы с Kerberos вам необходимо добавить или заменить некоторые строки в конфигурационном файле РАМ. В составе такого файла содержатся записи, определяющие основные действия, связанные с аутентификацией:

auth

account

password

session

gdm

Листинг 6.4. Пример конфигурационного файла РАМ для поддержки Kerberos

#%РАМ-1.0

auth     required   /lib/security/pam_nologin.so

auth     sufficient /lib/security/pam_unix.so shadow md5 \

 nullok likeauth

auth     required   /lib/security/kam_krb5.so use_first_pass

account  required /lib/security/pam_unix.so

password required /lib/security/pam_crack.lib.so

password required /lib/security/pam_unix.so shadow md5 \

 nullok use_authtok

session  required /lib/security/pam_unix.so

session  optional /lib/security/pam_krb5.so

session  optional /lib/security/pam_console.so

На заметку

В разных системах модули РАМ настраиваются по-разному, поэтому содержимое конфигурационного файла может отличаться от приведенного в листинге 6.4. Часто настройка сводится к включению строки, указывающей на

pam_krb.so

, и удалению ссылки на другой модуль.

В данном примере наиболее важны последняя запись

auth

session

auth

use_first_pass

kinit

password

password required /lib/security/pam_krb5.so use_authtok

Это необходимо в случае, если модуль

password

раsswd

session

xscreensaver

linuxconf

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

/etc/pam.d

pam_pwdb.so

pam_pwdb.so

password

passwd

Новая конфигурация РАМ становится доступна сразу после внесения соответствующих изменений; перезапускать программы РАМ не требуется. Если установленная конфигурация оказывает воздействие на сервер, который уже выполняется в системе, то чтобы он работал с учетом новой конфигурации его, возможно, придется перезапустить. Если установки влияют на регистрацию в системе, они окажут требуемое воздействие лишь после завершения сеанса работы пользователя. При использовании средств регистрации с графическим интерфейсом, например GDM, может понадобиться перезапустить сервер.

Kerberos — мощный инструмент, позволяющий централизованно выполнять аутентификацию в сети. Протокол обмена предполагает передачу шифрованных сообщений и наличие централизованной базы данных, которая используется серверами приложений, рабочими станциями и основным сервером Kerberos для аутентификации. Применяя средства Kerberos, можно добиться того, что после регистрации на некоторой рабочей станции пользователь сможет работать со всеми сетевыми службами, при этом повторный ввод пароля не потребуется. Исходный пароль никогда не передается по сети, поэтому вероятность того, что пароль попадет в руки злоумышленника, становится минимальной. Наличие централизованной базы данных существенно упрощает поддержку учетных записей.

Существует несколько реализаций Kerberos, предназначенных для применения в системе Linux; некоторые из них проще в использовании, чем другие. Для того чтобы сконфигурировать сеть Kerberos, надо установить на всех компьютерах как минимум подмножество системы Kerberos. Один из компьютеров должен выполнять функции центра распространения ключей (key distribution center — KDC); именно на этой машине располагается база данных с информацией о пользователях. На рабочих станциях и серверах необходимо установить керберизованные версии клиентских и серверных программ. Несмотря на то что настройка этих программ требует времени и усилий, достигнутый в результате использования Kerberos более высокий уровень защиты и преимущества централизованного администрирования оправдывают затраты. В особенности это заметно в сетях среднего и большого размера.

В конце 1990-х в локальных сетях все чаще стали устанавливать компьютеры под управлением Linux. Увлеченные перспективой затрачивать для решения сложных задач относительно небольшие ресурсы, администраторы использовали Linux даже тогда, когда это было совершенно не оправдано. Часто такими компьютерами заменяли дорогие и ненадежные серверы Windows, в результате пришлось решать задачу взаимодействия клиентов, работающих под управлением Windows, и Linux-серверов, т.е. возникла потребность в специальном инструменте, позволяющем поддерживать новую конфигурацию сети. Таким инструментом стал продукт Samba — сервер, обеспечивающий поддержку протокола SMB (Server Message Block — блок сообщений сервера), который в настоящее время известен также под названием CIFS (Common Internet Filesystem — общая межсетевая файловая система). SMB/CIFS — это протокол, позволяющий организовывать совместное использование файлов и принтеров и работающий на базе NetBIOS (набор протоколов, широко используемый в сетях, содержащих компьютеры под управлением Windows). Другими словами, Samba позволяет компьютеру под управлением Linux выполнять функции файлового сервера и сервера печати в сетях, содержащих компьютеры Windows. В настоящее время Samba очень хорошо справляется с этой задачей, кроме того, данный продукт постоянно дорабатывается и дополняется новыми средствами.

В начале данной главы речь пойдет о роли, которую Samba играет в современных сетях, а затем мы обсудим общие вопросы настройки Samba. В частности, здесь будут рассмотрены конфигурация Samba как контроллера домена, основного броузера и сервера имен NetBIOS; такие функции не имеют непосредственного отношения к разделению файлов, но их приходится выполнять в сетях NetBIOS. Средства Samba, предназначенные для разделения файлов и принтеров, понять не сложно; при их обсуждении будет уделено внимание ряду параметров, позволяющих изменить поведение системы. Завершается данная глава рассмотрением средств автоматизации Samba, с помощью которых решаются задачи, обычно не имеющие непосредственного отношения к организации файловых серверов и серверов печати.

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

man smb.conf

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

Поскольку NetBIOS и SMB/CIFS наследуют некоторые характеристики систем DOS и Windows, очевидно, что Samba целесообразнее всего применять в сетях, использующих компьютеры под управлением именно этих операционных систем. Ряд свойств Samba упрощает обмен данными с DOS и Windows. Например, всем известно, что в именах файлов DOS и Windows не учитывается регистр символов; имена

FILE.TXT

file.txt

File.txt

Samba применяется даже в сетях, не использующих компьютеры под управлением DOS, Windows, OS/2 и других систем, в которых основным протоколом разделения файлов является SMB/CIFS. UNIX, Macintosh, BeOS и другие системы также поддерживают SMB/CIFS. Если такая поддержка не реализована в самой системе, она обеспечивается продуктами независимых производителей. Linux позволяет работать и с другими протоколами разделения файлов (в частности, Linux поддерживает средства NFS, которые будут подробно рассмотрены в главе 8), однако в некоторых случаях использование Samba предпочтительнее. Модель защиты SMB/CIFS (к которой для аутентификации применяются пользовательские имена и пароли) отличается от модели NFS (где компьютеры идентифицируются по IP-адресам, а за безопасность системы отвечают средства защиты клиента).

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

Для настройки Samba используется файл

smb.conf

/etc

/etc/samba

/etc/samba.d

smb.conf

#

[имя_разделяемого_объекта]

Последующие строки раздела определяют характеристики объекта — имя каталога, соответствующего разделяемому объекту, особенности обработки файлов и т.д. Раздел, содержащий опции общего назначения, выглядит как определение разделяемого объекта, но таковым не является. В начале этого раздела указано имя

[global]

[global]

Для настройки Samba используются параметры, которые представляются в следующем формате:

параметр = значение

Samba позволяет использовать при указании параметров символы как нижнего, так и верхнего регистра, но в большинстве случаев имена параметров содержат только символы нижнего регистра, а значения параметров начинаются с прописной буквы. Некоторые значения, например имена файлов Linux, зависят от регистра символов. Ряд параметров предполагает двоичные значения; в этом случае

Yes

True

1

No

False

0

В сетях NetBIOS используется система имен, не связанная с доменными именами, применяемыми в сетях TCP/IP. Например, компьютеру

harding.threeroomco.com

BILLY

USPRES

На заметку

Различие между рабочей группой и доменом NetBIOS не очень существенны. Рабочая группа — это набор компьютеров с общим именем группы. Домен отличается от рабочей группы тем, что в нем присутствует специальный компьютер, называемый контроллером домена, который обеспечивает централизованную аутентификацию и выполняет некоторые другие функции. Домен может занимать несколько сегментов сети; для рабочей группы реализовать такую конфигурацию затруднительно. При необходимости компьютер, на котором выполняется сервер Samba, может выступать в роли контроллера домена (этот вопрос будет обсуждаться далее в данной главе).

Имя рабочей группы или имя домена задается с помощью параметра

workgroup

workgroup = USPRES

Данный параметр указывает на то, что компьютер принадлежит рабочей группе

USPRES

По умолчанию Samba использует в качестве имени узла NetBIOS первый компонент доменного имени TCP/IP этого компьютера. Например, для компьютера

harding.threeroomco.com

HARDING

netbios name

netbios aliases

BILLY

WILLIAM

netbios name = BILLY

netbios aliases = WILLIAM

Совет

В большинстве случаев рекомендуется, чтобы имя компьютера, входящее в состав домена TCP/IP, и имя NetBIOS, совпадали. Это исключит недоразумения при обращении к узлу сети.

В ранних реализациях SMB/CIFS пароли передавались по сети в незашифрованном виде. Это давало возможность для перехвата их другими узлами локальной сети, а если в обмене данными участвовали маршрутизаторы, то пароль мог быть перехвачен и внешними компьютерами. В последующих реализациях SMB/CIFS были использованы средства шифрования паролей. Однако способы кодирования SMB/CIFS не совместимы со способами, которые используются для поддержки локальных паролей Linux. Закодированный пароль SMB/CIFS невозможно сравнить с записями, хранящимися в локальной базе Linux, поэтому в Samba была реализована собственная база паролей. Эта база называется

smbpasswd

В системе Windows, начиная с версий Windows 95 OSR2 и Windows NT 4.0 SP3, по умолчанию используются зашифрованные пароли. Если сервер Samba настроен для передачи незакодированных паролей, взаимодействие с Windows будет невозможным. Для того чтобы устранить эту проблему, надо переконфигурировать либо сервер Samba, либо систему Windows. Чтобы изменить конфигурацию Samba, придется затратить меньше усилий, кроме того, такой подход гораздо предпочтительнее с точки зрения безопасности системы.

Обработкой зашифрованных паролей управляет параметр

encrypt passwords

smbpasswd

smbpasswd

# smbpasswd -а имя_пользователя

В процессе выполнения утилита

smbpasswd

smbpasswd

smbpasswd

smbpasswd

Дополнительные меры по защите обеспечивают параметры

hosts allow

hosts deny

/etc/hosts.allow

/etc/hosts.deny

algernon.pangaea.edu

hosts allow = 192.168.7. algernon.pangaea.edu

На заметку

Последующие разделы посвящены работе Samba в качестве сервера имен NetBIOS, основного броузера и контроллера домена. Читатели, не интересующиеся данными вопросами, могут перейти к разделу "Организация файлового сервера с помощью Samba". Конфигурация, установленная по умолчанию, обеспечит работу Samba во многих сетях.

В сетях NetBIOS необходимы средства преобразования имен. Преобразование имен NetBIOS и TCP/IP выполняется различными способами; основные из них описаны ниже.

• Имена TCP/IP. Для преобразования можно использовать имена TCP/IP; в Windows 2000, Windows XP и Samba этот способ применяется по умолчанию. Следует заметить, что такое решение не имеет непосредственного отношения к NetBIOS.

• Применение файла

lmhosts

lmhosts

/etc/hosts

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

• WINS-сервер. Сервер NBNS (NetBIOS Name Service — служба имен NetBIOS), который также известен под названием WINS (Windows Internet Name Service — сервер Internet-имен для системы Windows), выполняет преобразование имен в IP-адреса.

Чтобы сервер Samba мог работать в качестве WINS-сервера, надо включить в раздел

[global]

smb.conf

wins support = Yes

WINS-сервер не требует дополнительной настройки (по крайней мере на стороне сервера). Если клиенты и серверы NetBIOS могут обмениваться данными по сети, они регистрируются на WINS-сервере. WINS-сервер должен быть задан для каждого компьютера, подключенного к сети. В системе Windows для этого используется диалоговое окно TCP/IP Properties, показанное на рис. 7.1. Если вы установите флажок опции Use DHCP for WINS Resolution, Windows будет получать необходимую информацию от DHCP-сервера. (Вопросы настройки DHCP-сервера рассматривались в главе 5.)

Рис. 7.1. Диалоговое окно TCP/IP Properties в системе Windows позволяет задавать адрес WINS-сервера

Чтобы сервер Samba использовал для преобразования имен NetBIOS WINS-сервер, вам надо задать в файле

smb.conf

wins server

name resolve order

name resolve order

host

beast

wins server = 192.168.1.1

name resolve order = wins lmhosts host beast

Роль WINS-сервера может выполнять только одна система. Если таких серверов будет несколько, ненадежность выполнения процедуры преобразования снизится, так как некоторые компьютеры будут регистрироваться на одном сервере, а остальные — на других серверах. (В NetBIOS-сетях предусмотрен механизм использования вторичного сервера имен. Наличие вторичного сервера увеличивает надежность сети и обеспечивает работу клиентов при выходе основного сервера из строя. Однако система Samba не может работать в качестве вторичного сервера имен.)

Выше я упоминал о броузерах Network Neighborhood и My Network Places. Эти программы не являются Web-броузерами. Они предназначены для просмотра данных, предоставляемых серверами SMB/CIFS, работающими в сети NetBIOS (рис. 7.2). Дважды щелкнув мышью на имени компьютера, вы увидите информацию о разделяемых объектах SMB/CIFS. Разделяемые объекты файлов отображаются в виде папок, а разделяемые объекты печати — в виде пиктограмм с изображением принтеров. Дважды щелкнув на изображении папки, вы получите доступ к разделяемым файлам и сможете работать с ними так же, как и с файлами на локальном жестком диске.

Рис. 7.2. Windows предоставляет информацию о компьютерах вашего домена или рабочей группы, а также о компьютерах, принадлежащих другим доменам или рабочим группам, которые находятся в текущем сегменте локальной сети

Такое взаимодействие удобно с точки зрения пользователя, но для того, чтобы оно стало возможным, необходимо иметь соответствующим образом настроенное программное обеспечение. Рассмотрим описанную ситуацию с точки зрения сетевого броузера Windows. Как он может получить информацию о том, какие компьютеры присутствуют в сети и какие объекты доступны для совместного использования? Для этого один из компьютеров в сегменте сети NetBIOS должен выполнять функции основного локального броузера (local master browser). Этот компьютер хранит список серверов SMB/CIFS, принадлежащих сегменту сети, и предоставляет данные клиентам SMB/CIFS в ответ на их запросы. В результате, для того, чтобы иметь сведения о разделяемых ресурсах, клиент должен знать только адрес основного броузера, а такую информацию он может получить с помощью широковещательного сообщения. Сразу после загрузки клиент передает в широковещательном режиме запрос на получение адреса основного броузера. То же делает и сервер, но при этом он регистрирует свои ресурсы. В результате на основном броузере всегда содержится самая новая информация о конфигурации сети.

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

В роли основного броузера домена обычно выступает контроллер домена. Компьютер специально настраивается для выполнения соответствующих функций. Основные локальные броузеры определяются с помощью процедуры выборов (election), в ходе которых компьютеры, принадлежащие сегменту сети, выступают в роли претендентов и объявляют в сети свои возможности. Один из претендентов оказывается победителем и принимает на себя обязанности основного локального броузера. Важно, чтобы основные броузеры работали надежно; если компьютер, выполняющий функции основного броузера часто выходит из строя или перезагружается, то в это время пользователи не смогут просматривать ресурсы сети. Важно также, чтобы сервер Samba не проявлял излишней "настойчивости", пытаясь стать победителем. Установка одного из параметров (он будет рассмотрен ниже) приведет к тому, что Samba будет периодически выставлять свою кандидатуру на роль основного локального броузера, в результате чего процедура просмотра ресурсов сети станет работать с перебоями.

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

[global]

browse list = Yes

local master = Yes

preferred master = Yes

os level = 65

Параметр

browse list

Yes

Yes

Yes

preferred master

No

Yes

preferred master

os level

os level = 65

os level

os level

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

domain master = Yes

domain master

Как вы уже знаете, компьютеры в сетях NetBIOS объединяются в рабочие группы, либо в домены. Эти структуры похожи друг на друга, но в домене степень централизации несколько выше. В домене присутствует компьютер, называемый контроллером домена, который выполняет аутентификацию пользователей. Вместо того чтобы предоставлять каждому серверу самостоятельно решать, разрешить ли пользователю обращаться к разделяемым объектам, эту задачу выполняет контроллер домена. Использование такого контроллера существенно упрощает администрирование сети, содержащей несколько серверов, в особенности, если администратору часто приходится создавать учетные записи для новых пользователей и удалять старые записи. Однако для настройки контроллера домена необходимо приложить определенные усилия. Контроллер домена может решать также другие задачи. Например, с помощью можно поддерживать сценарии регистрации или создавать профили Windows. Профили — это специальные наборы установок, которые могут вместе с пользователями перемещаться от одного клиента к другому. Конфигурирование контроллера домена — достаточно сложная задача, поэтому в данном разделе приводятся лишь общие сведения о его настройке.

Существуют два типа контроллеров домена NetBIOS: основной контроллер домена (primary domain controller — PDC) и резервный контроллер домена (backup domain controller — BDC). В случае если PDC выходит из строя или становится недоступным, его функции выполняет BDC. Samba поддерживает возможности PBC, но не может выступать в роли ВВС.

Чтобы настроить Samba для работы в качестве PBC, необходимо добавить в раздел

[global]

smb.conf

security = User

encrypt passwords = Yes

domain logons = Yes

Параметр

security

encrypt passwords

domain logons

domain logons

Yes

smbpasswd

На заметку

Для установки доменного имени надо использовать параметр

workgroup

, включив его в файл

smb.conf

.

Если в состав сети входят компьютеры под управлением Windows NT, 2000 или XP, вам надо предпринять дополнительные действия по настройке системы. Во-первых, необходимо помнить, что версии Samba, предшествующие 2.2.0, не поддерживают взаимодействие с клиентами Windows NT, версии, выпущенные ранее 2.2.1a, не поддерживают клиентов Windows XP и Windows 2000 Service Pack 2 (SP2). Samba 2.2.0 и более поздние версии поддерживают многие новые возможности, реализованные в клиентах NT/2000 и даже в Windows NT 4.0. Это надо учитывать, выбирая версию Samba. Во-вторых, для использования Samba в качестве контроллера домена для каждого из клиентов NT/2000/XP необходимо создать в системе Linux структуру, которая называется доверительной учетной записью (trust account). Сделать это можно, выполнив следующие команды:

# groupadd -r trust

# useradd -r -g trust -d /dev/null -s /dev/null client$

# smbpasswd -a -m client

Команду

groupadd

useradd

CLIENT

$

smbpasswd

client

smbpasswd

$

Конфигурация домена требует также изменить способ настройки клиента. Это можно сделать с помощью управляющей панели. В Windows 9x/Me для этого надо выбрать в окне Network пункт Microsoft Networks и щелкнуть на кнопке Properties. Система отобразит диалоговое окно Client for Microsoft Networks Properties, показанное на рис. 7.3. Установите флажок опции Log On to Windows NT Domain и введите имя домена. Чтобы сделать то же самое в системе Windows 2000, надо щелкнуть правой кнопкой мыши на пиктограмме My Computer и выбрать пункт Properties, чтобы открыть диалоговое окно System Properties. Затем необходимо выбрать Network Identification и щелкнуть на кнопке Properties. После установки конфигурации домена система запросит пользовательское имя и пароль администратора. В ответ надо, как обычно, ввести имя пользователя и пароль.

Рис. 7.3. Выбор конфигурации домена на клиентской машине под управлением Windows сводится к установке флажка опции и вводу имени домена

Настройка файлового сервера для выполнения функций контроллера домена и WINS-сервера часто бывает необходима, но в подавляющем большинстве случаев сервер Samba используется как обыкновенный файловый сервер. Для того чтобы настроить Samba таким образом, надо определить разделяемые файлы, включив эти определения в файл

smb.conf

[global]

Описание разделяемого объекта Samba, обеспечивающего совместный доступ к файлам, выглядит следующим образом:

[sample]

path = /home/samba/shared-dir

browseable = Yes

read only = No

В данном примере определяется разделяемый объект с именем

[sample]

SAMPLE

/home/samba/shared-dir

SAMPLE

browseable = Yes

browseable

Yes

browseable

browseable = No

read only = No

writeable = Yes

write ok = Yes

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

[homes]

[homes]

• Задавать параметр

path

• В списке просмотра разделяемый объект отображается под именем, совпадающим с именем пользователя (например, объект

rodsmith

browseable = No

[homes]

Во многих дистрибутивных пакетах разделяемый объект

[homes]

smb.conf

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

Настраивая сервер Samba, вы можете описывать как угодно много разделяемых объектов, но очевидно, что определять несколько объектов

[homes]

[global]

В системах Linux и Windows действуют разные соглашения по именованию файлов. Если в вашей сети, кроме Windows, присутствуют также клиенты DOS, то при настройке Samba следует учесть, что правила именования DOS-файлов отличаются от правил, принятых не только в Windows. Таким образом, при работе в сети с компьютерами Windows и DOS сервер Samba должен решить сложную задачу: представить файловую систему Linux в формате, совместимом с файловыми системами DOS и Windows.

Одно из самых важных отличий файловой системы Linux от системы Windows состоит в том, что имена файлов Linux чувствительны к регистру символов, т.е. имена

FILE.TXT

file.txt

File.txt

Параметр

case sensitive

sensitive = Yes

sensitive = Yes

Параметры

preserve case

short preserve case

Yes

No

default case

Lower

Upper

short preserve case

short preserve case = No

Средства SMB/CIFS обеспечивают доставку имен 8.3 даже в том случае, если исходные имена содержат большее количество символов. Это позволяет организовывать доступ к файлам с длинными именами для клиентов, работающих в DOS или 16-битовой системе Windows. Поскольку в Linux длина имени файла не ограничена, сервер Samba должен динамически генерировать имена 8.3. Параметр

mangled names = Yes

mangled names = No

Средства защиты Linux базируются на понятиях принадлежности файла определенному владельцу и правах доступа к нему, принятых в системе UNIX. Однако SMB/CIFS использует те же признаки несколько по-другому. Средства SMB/CIFS регистрируют пользователей, обратившихся к серверу, анализируя имена и пароли, таким образом, по умолчанию Samba использует для этой цели учетные записи Linux. Если пароли передаются в незашифрованном виде, Samba применяет стандартный механизм аутентификации Linux, а при работе с зашифрованными паролями сервер Samba самостоятельно идентифицирует пользователя. Samba позволяет проводить сеанс работы от имени различных пользователей. В частности, параметры

force user

force group

[jekyl]

path = /home/samba/jekyl

read only = No

force user = hyde

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

hyde

muriel

hyde

henry

/home/samba/jekyl

hyde

force group

На заметку

Обращаясь к разделяемому объекту, для которого указан параметр

force user

, пользователь указывает собственный пароль.

Параметры

force user

force group

Несмотря на то что и Linux, и SMB/CIFS поддерживают пользовательские имена, механизмы обеспечения доступа, используемые ими, не совпадают. Если Samba применяется для взаимодействия с клиентами DOS и Windows 9x/Me, клиент вовсе не использует сведения о правах доступа. Поэтому вы можете устанавливать для файлов, созданных этими клиентами, любые права. Сделать это можно с помощью параметров

create mask

directory mask

create mask

directory mask

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

• 

map archive

Yes

create mask

• 

map system

Yes

No

• 

map hidden

Yes

No

На заметку

По умолчанию Samba устанавливает признак скрытого файла для файлов Linux, имена которых начинаются с точки. Linux интерпретирует подобные файлы приблизительно так же, как DOS — скрытые файлы. Если такое поведение системы вас не устраивает, вы можете изменить настройку, задав параметр

hide dot files = No

.

Значение параметра

create mask

map archive

map system

map hidden

map system

map hidden

create mask

В системах Windows NT/2000/XP используется более сложная модель защиты, чем в Windows 9x/Me. В Windows NT/2000/XP поддерживаются ACL (Access Control Lists — списки контроля доступа), которые позволяют непосредственно определить уровень доступа конкретного пользователя к файлу. Samba поддерживает отображение прав доступа для владельца, группы и всех пользователей Linux в Windows ACL. Это позволяет хранить на сервере Samba информацию о правах, установленных в системе Windows NT/2000/XP. Поддержка ACL задается с помощью параметра

nt acl support

Yes

No

На заметку

В файловых системах DOS и Windows 9x/Me существует признак, который разрешает или запрещает запись в файл. Этот признак воздействует на права владельца, группы и пользователя, поэтому для его поддержки необходимо соответствующим образом изменить значения параметра

create mask

или

directory mask

. ACL обеспечивают полный контроль доступа к файлам, в частности, позволяют разрешить или запретить запись в файл.

Samba использует различные средства контроля доступа к серверу. В качестве примера можно привести уже упоминавшиеся параметры

hosts allow

hosts deny

valid users

invalid users

valid users

invalid users

Помимо

valid users

invalid users

write list

read list

write list

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

[control]

path = /home/samba/control

read only = Yes

invalid users = thomas susan

write list = gertrude henry

Для большинства пользователей данный объект допускает только чтение. Двум пользователям (

thomas

susan

gertrude

henry

Разделяемые объекты, представляющие принтеры, используются по такому же принципу, как и объекты, предназначенные для организации совместного доступа к файлам. Для того чтобы вывести данные на печать, клиент передает файл разделяемому объекту принтера. Сервер обрабатывает этот файл и выводит его содержимое на устройство печати. Многие из параметров, которые используются при описании разделяемых объектов файлов, применимы и для объектов принтеров. Так, например, в описания разделяемых объектов принтеров можно включать параметры, управляющие доступом пользователей. С другой стороны, в определении таких объектов неуместны параметры, которые управляют использованием в именах файлов символов верхнего и нижнего регистра.

Трудности, возникающие при поддержке разделяемых принтеров, в основном связаны с обработкой заданий на печать, передаваемых Windows-клиентами. В зависимости от типа очереди Linux, такие задания должны либо модифицироваться, либо оставаться неизменными. В некоторых случаях приходится создавать различные конфигурации для PostScript-принтеров и принтеров, в которых отсутствует поддержка данного языка.

На заметку

При рассмотрении вопросов взаимодействия с устройством печати предполагается, что принтер уже подключен к компьютеру и может выводить данные, которые передаются ему в системе Linux. (Для некоторых принтеров отсутствуют драйверы Ghostscript, но эти принтеры могут успешно использоваться посредством Samba.)

Основное различие между разделяемыми объектами файлов и принтеров состоит в том, что в описании последнего присутствует параметр

printable = Yes

print ok = Yes

/var/spool/lpd

/tmp

/var/pool/samba

chmod 1777 /каталог

chmod o+t /каталог

[laser]

comment = Laser printer in Room 7

path = /var/spool/samba

printable = Yes

Параметр comment задает комментарии для разделяемого объекта

LASER

laser

name = lр

lр

В различных дистрибутивных пакетах Linux используются разные системы печати. В настоящее время чаще всего применяется система BSD, но системы LPRng и CUPS (Common Unix Printing System — общая система печати UNIX) также приобретают популярность. Разные системы печати отличаются друг от друга синтаксическими правилами, что необходимо учитывать при настройке Samba. Для этой цели предусмотрен параметр

printing

print command

%s

print command

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

[printers]

/etc/printcap

[homes]

[printers]

browseable = No

PRINTERS

Yes

В ходе предыдущего обсуждения не затрагивался вопрос об использовании драйверов. Этот вопрос чрезвычайно важен для разделения принтеров в системе Samba; драйверы принтеров часто становятся источником проблем. В системе Windows драйверы принтеров взаимодействуют с прикладными программами и генерируют данные, совместимые с конкретной моделью принтера. Таким образом, формат файла, который приходит разделяемому объекту печати, расположенному на сервере Samba, зависит от того, какой драйвер принтера был установлен на клиентской машине. В отличие от Windows, в системе Linux обычно используются очереди печати, которые настраиваются для приема данных в формате PostScript. В зависимости от типа принтера, подключенного к компьютеру, данные могут передаваться ему в неизменном виде либо обрабатываться фильтром печати. Фильтр печати преобразует PostScript-код в формат, подходящий для данного принтера. Различия в моделях печати иногда приводят к возникновению конфликтов. Если клиент Windows предоставляет серверу Samba файл в формате, отличном от PostScript, информация, предназначенная для вывода на печать, может быть искажена. Возможна также ситуация, когда данные, сгенерированные PostScript-драйвером Windows, воспринимаются на сервере Samba как информация, представленная в другом формате. В этом случае при выводе на печать также будут получены некорректные результаты. Существует ряд правил и параметров Samba, которые позволяют разрешить данную проблему, но необходимо испробовать различные средства, чтобы найти наиболее подходящие из них.

Наиболее просто конфигурация Samba устанавливается в том случае, если разделяемый принтер поддерживает язык PostScript. В этом случае PostScript-код может быть непосредственно передан на устройство печати. Однако поддержка PostScript обычно реализуется в высокоуровневых лазерных принтерах и некоторых устройствах печати среднего уровня. Низкоуровневые лазерные принтеры и струйные принтеры, поддерживающие PostScript, встречаются крайне редко. Для того чтобы выяснить, может ли ваш принтер обрабатывать PostScript-код, необходимо ознакомиться с документацией на это устройство.

Внимание

Некоторые принтеры объявляются в системе как устройства, поддерживающие PostScript, однако данное свойство принтера эмулируется с помощью интерпретатора, выполняющегося в системе Windows. При организации совместного доступа к подобным принтерам они должны рассматриваться как устройства печати, не поддерживающие PostScript. Это могут быть высококачественные принтеры, но без эмулятора они не способны обрабатывать PostScript-код.

На заметку

Язык PostScript и соответствующий интерпретатор были первоначально разработаны компанией Adobe (

http://www.adobe.com

). Многие компании, занимающиеся выпуском принтеров, также разработали свои версии интерпретаторов PostScript для включения в состав устройств печати. Так, поддержка PostScript реализована во многих принтерах Hewlett Packard и Lexmark. Первые интерпретаторы PostScript были далеки от совершенства, но присущие им ошибки были исправлены в более поздних версиях. В настоящее время при установке конфигурации Samba совершенно не важно, поддерживает ли ваш принтер версию PostScript, разработанную Adobe, или в нем используется один из интерпретаторов, выпущенных другими компаниями.

Если ваш принтер непосредственно поддерживает PostScript, вы можете установить PostScript-драйвер в системе Windows. Такие драйверы входят в поставку операционной системы, а также распространяются производителями принтеров. (Компания Adobe также предоставляет драйверы PostScript, но они предназначены для принтеров, в которых используется PostScript-интерпретатор, разработанный Adobe.) Этот драйвер генерирует данные в формате PostScript, которые Samba передает в очередь на устройство печати; затем данные приходят на конкретный принтер. В большинстве случаев информация корректно выводится на печать.

Иногда при использовании описанной конфигурации возникают проблемы, которые чаще всего связаны с тем, что PostScript-драйвер, установленный в системе Windows, предваряет вывод данных символом <Ctrl+D>. Большинство PostScript-принтеров игнорирует этот символ, но он может влиять на поведение очереди в системе Linux. Фильтр печати ожидает встретить в начале файла, содержащего задание на печать, идентификатор формата PostScript. Обнаружив символ <Ctrl+D>, фильтр печати интерпретирует его как признак того, что в файле содержится ASCII-текст. Поскольку ASCII-текст не может быть непосредственно передан на PostScript-принтер, этот файл повторно преобразуется в PostScript-формат. В результате вместо текста документа на принтер выводится его PostScript-код. Разрешить эту проблему можно двумя способами.

Рис. 7.4. Если наличие <Ctrl+D> приводит к возникновению проблем при выводе документа на принтер в системе Linux, вы можете запретить генерацию этого символа

Вы можете отключить опцию драйвера печати Windows, которая управляет выводом символа <Ctrl+D>. Эту опцию можно найти в диалоговом окне Properties принтера либо в окне, которое отображается после щелчка на кнопке Advanced в этом же окне необходимо сбросить флажок опции Send CTRL+D Before Job. (Опция Send CTRL+D After Job обычно не приводит к возникновению проблем.) Такое решение хорошо подходит в том случае, если вы используете одну очередь для обслуживания PostScript-принтеров и устройств печати, поддерживающих другие языки описания документов. Недостаток подобного подхода состоит в том, что для настройки многочисленных Windows-клиентов придется затратить много времени.

Чтобы разрешить проблему, возникающую из-за наличия в начале задания на печать символа <Ctrl+D>, необходимо установить параметр

postscript = Yes

Существуют два способа настройки Samba для работы с принтерами, не поддерживающими PostScript. Первый способ заключается в использовании PostScript-драйвера на клиентской машине и настройке очереди печати Linux для преобразования PostScript-данных в формат, поддерживаемый конкретным принтером. Согласно второму способу, следует установить на клиентском компьютере драйвер, генерирующий данные на языке принтера, а в системе Linux создать очередь без обработки (raw queue). Данные, помещенные в такую очередь, передаются на принтер в неизменном виде. Оба способа имеют свои преимущества и недостатки, и для реализации каждого из них необходимо определенным образом сконфигурировать Samba.

Предположим, что вам необходимо вывести на принтер, не поддерживающий PostScript, сгенерированные Linux-приложением PostScript-данные. В этом случае система должна быть сконфигурирована так, чтобы данные, предназначенные для печати, обрабатывались программой Ghostscript. Ghostscript

(http://www.cs.wisc.edu/~ghost/

http://www.linuxprinting.org/printer_list.cgi

В очереди печати Linux, настроенной для совместной работы с Ghostscript, присутствует фильтр печати, который распознает тип файла. В отличие от фильтра, который используется в очереди, обслуживающей PostScript-принтер, данный фильтр передает данные на вход программы Ghostscript. В этом случае необходимо использовать инструментальные средства настройки принтеров, поставляемые в составе дистрибутивного пакета, а также следовать инструкциям по установке конфигурации фильтра. Настроенная подобным образом очередь работает почти идентично очереди PostScript-принтера (вопросы выбора конфигурации Samba и клиентов для такой очереди рассматривались в предыдущем разделе). Для Windows-клиентов надо выбрать универсальный PostScript-драйвер (для лазерных принтеров хорошо подходят драйверы Apple LaserWriter, а для струйных — драйвер QMS magicolor). Проблема, связанная с появлением в составе задания на печать символа <Ctrl+D>, решается так же, как и при использовании PostScript-принтеров.

Некоторые PostScript-драйверы в системе Windows включают в состав PostScript-файлов дополнительные команды, предназначенные для вывода информации на встроенные дисплеи принтеров. Такие команды часто приводят к появлению дополнительных страниц выходных данных с сообщениями типа

%% [ LastPage ] %%

gs

>/dev/null

/dev/null

/var/spool/lpd/имя_очереди/printfilter

/usr/lib/rhs/rhs-printfilters/ps-to-printer.fpi

Если вы хотите использовать на клиентской машине драйвер, генерирующий информацию в формате, отличном от PostScript, вам надо создать в системе Linux очередь принтера, в которой не предпринимались бы попытки модифицировать данные, переданные на печать. Некоторые фильтры Linux распознают ряд языков и передают соответствующие данные принтеру в неизменном виде, поэтому не исключено, что вам удастся использовать обычную очередь печати. Если же задания, помещенные в такую очередь, исчезают или выводятся в искаженном виде, вам придется создать очередь без обработки (raw queue).

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

/etc/printcap

if=

if

lр|hp4000|raw:\

 :lp=/dev/lp0:\

 :sd=/var/spool/lpd/lp:\

 :mx#0:\

 :sh:\

 :if=:

В данном примере указаны три имени принтера:

lp

hp4000

raw

/dev/lp0

/var/spool/lpd/lp

/var/spool/lpd/lp

mx#0

sh

if=

Определяя разделяемый объект принтера для очереди без обработки, необходимо убедиться, что параметр

postscript

No

Если компьютеру, на котором выполняется сервер Samba, подключен принтер, не поддерживающий PostScript, вам необходимо принять решение о том, нужно ли установить на клиентской машине PostScript-драйвер или драйвер, ориентированный на работу с имеющимся у вас устройством печати. Следует заметить, что рассмотренные выше варианты решения не являются взаимоисключающими, как это кажется на первый взгляд. Вы можете создать две очереди, а если фильтр печати распознает задания, предназначенные для принтера, не поддерживающего PostScript, можно даже обойтись одной очередью печати. (Если вы создадите две очереди Linux, то разделяемый объект

[printers]

Одно из важных различий между рассмотренными подходами состоит в том, что текст или изображение преобразуется в битовую карту на разных этапах обработки. Рассмотрим вывод на печать документа, содержащего в основном текстовые данные. Если вы используете Ghostscript в системе Linux и PostScript-драйвер на стороне клиента, клиент генерирует текстовый файл. Размеры этого файла относительно невелики, поэтому создание такого файла не создает существенной нагрузки на процессор клиентской машины. Трафик, связанный с передачей этого файла по сети, также невелик. Для обработки такого файла в системе Linux требуется большой объем ресурсов, так как содержащиеся в файле данные должны быть преобразованы в битовую карту. Если на клиентском компьютере установлен драйвер целевого принтера, основную нагрузку по обработке файла будет нести процессор этой машины, поскольку именно на стороне клиента будет осуществляться преобразование в формат битовой карты. Соответственно возрастет трафик сети, потому что размер передаваемого файла увеличится. Нагрузка на процессор компьютера, на котором выполняется сервер Samba, будет небольшой, поскольку основная обработка данных выполняется на стороне клиента. Таким образом, при использовании интерпретатора Ghostscript в работу вовлекается меньше ресурсов клиентской машины и уменьшается трафик сети. Применение драйвера целевого принтера оправдано в тех случаях, когда необходимо уменьшить нагрузку на процессор сервера. При выводе на печать графических файлов разница между различными подходами практически не ощущается, так как размеры файла почти не зависят от того, передается ли он в формате PostScript или в формате целевого принтера.

Еще одно различие между вариантами поддержки принтеров, не обрабатывающих PostScript-данные, связано с качеством выходных данных. Используя Ghostscript, вы полагаетесь на реализованные в этом продукте средства генерации изображений. Чаще всего Ghostscript хорошо справляется с этой задачей, но в некоторых случаях драйверы целевых принтеров генерируют изображения гораздо лучшего качества. В особенности это бывает заметно при работе с последними моделями струйных принтеров. Некоторые принтеры вовсе не поддерживаются Ghostscript; для такого устройства возможна лишь одна конфигурация, предполагающая использование драйвера этого принтера на стороне клиента и очереди без обработки в системе Linux. Бывают ситуации, в которых интерпретатор Ghostscript предпочтительнее драйвера целевого принтера. Это случается при работе с приложениями, непосредственно ориентированными на работу с PostScript-принтерами (например, пакетами, предназначенными для организации настольных издательских систем), или при выводе на печать файлов EPS (Encapsulated PostScript). Необходимо заметить, что интерпретатор Ghostscript позволяет обеспечить PostScript-совместимость, затратив для этого минимальные усилия. Преимуществом использования Ghostscript также является тот факт, что данный интерпретатор обеспечивает реальную возможность стандартизировать вывод на печать, т.е. исключает необходимость переключаться между различными принтерами.

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

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

Одна из самых привлекательных особенностей Samba — возможность выполнения сценариев. Вы можете задавать команды, которые будут выполнены при наступлении определенных событий. Благодаря поддержке сценариев Samba можно использовать для решения задач, непосредственно не относящихся к совместному использованию файлов и принтеров. В начале данного раздела мы обсудим сценарии

preexec

postexec

Samba поддерживает параметры

preexec

postexec

preexec

postexec

billy@harding.threeroomco.com

preexec = mail -s "Share being used" \

 billy@harding.threeroomco.com

Если пользователь зарегистрируется для работы с объектом, Samba пошлет от его имени сообщение по адресу

billy@harding.threeroomco.com

Subject

Share being used

Аналогично действует параметр

postexec

Разновидностями параметров

preexec

postexec

root preexec

root postexec

root preexec

root postexec

root

При выполнении сценариев сервер Samba может обрабатывать переменные, перечисленные в табл. 7.1. Эти переменные позволяют настроить сценарии

preexec

postexec

Таблица 7.1. Переменные, доступные в системе Samba

Параметры

preexec

postexec

preexec

preexec

postexec

• С помощью сценариев

preexec

postexec

follow symlinks = No

• С помощью параметра

preexec

postexec

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

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

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

/etc

postexec

/etc

• Чтобы уменьшить риск потери информации, необходимо периодически создавать резервные копии данных. Разделяемый объект можно использовать для создания процедуры копирования, запускаемой по инициативе пользователя. Для этого надо создать Windows-сценарий, который открывал бы разделяемый объект Samba, копировал все файлы с компьютера в этот объект и закрывал его. Для решения данной задачи следует также построить сценарий разделяемого объекта, осуществляющий копирование данных на резервный носитель. При наличии такого объекта и сценариев пользователю остается установить носитель на устройство, запустить сценарий Windows и ожидать завершения копирования данных.

Некоторые из описанных примеров реализуются чаще других. Ряд задач (например, задачи администрирования) создают потенциальную угрозу безопасности системы, поэтому соответствующие сценарии находят лишь ограниченное применение. Поэтому приведенные выше примеры — это не описания задач, которые должны быть решены с помощью сценариев

preexec

postexec

На заметку

Несмотря на то что вы можете задавать необходимые команды непосредственно в составе параметров

preexec

и

postexec

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

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

max connections

max connections = 1

Еще одну возможность использования сценариев предоставляет параметр

print command

print command

print command

• Передача факсов с помощью программного обеспечения Linux и PostScript-драйвера Windows. При этом даже можно воспользоваться Windows-программами, например, продуктом Respond (

http://www.boerde.de/~horstf/

• Конвертирование PostScript-файлов в другие типы данных, например, представление их в виде PDF-файлов или преобразование в графический формат. Пример подобного использования параметра

print command

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

print command

• Объединяя данные в файл архива и передавая этот файл на компьютер под управлением Linux, вы можете решать задачи, подобные тем, которые решаются с помощью сценариев

preexec

postexec

Подобно сценариям

preexec

postexec

print command

force user

В составе параметра

print command

%s

preexec

postexec

%H

Параметр

print command

preexec

postexec

postexec

print command

С помощью сценариев можно сконфигурировать сервер Samba как платформу для создания компакт-дисков. Предположим, что вы администрируете сеть небольшого офиса, к которой подключены десятки клиентских компьютеров. Предположим также, что в офисе имеется лишь одно устройство, позволяющее записывать компакт-диски. Время от времени у разных пользователей возникает необходимость записать информацию на компакт-диск. Вы можете подключить устройство записи к компьютеру, на котором выполняется сервер Samba, и предоставить всем желающим возможность использовать программное обеспечение Linux для создания компакт-дисков. Однако при этом возникнут проблемы. Во-первых, вам придется обучить пользователей работать с программами записи. Во-вторых, некоторые пользователи не будут удалять после окончания записи свои файлы, что приведет к нерациональному использованию дискового пространства. Сценарии Samba позволяют автоматизировать процесс записи и разрешить возникающие проблемы.

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

preexec

postexec

1. Удаление из разделяемого объекта всех файлов.

2. Получение файлов, предназначенных для записи на компакт-диск.

3. Создание образа диска с помощью

mkisofs

4. Запись образа на компакт-диск с помощью

cdrecord

5. Удаление образа диска и файлов, из которых он был создан.

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

[cd-create]

path = /home/samba/cd-create

create mask = 0666

directory mask = 0777

read only = No

max connections = 1

preexec = /bin/rm -r %P/*

postexec = /usr/local/bin/create-cd %H %P %U

Параметр preexec решает первую задачу. Вторая задача решается с помощью обычных операций Samba. Для решения задач 3-5 предназначен сценарий

/usr/local/bin/create-cd

Листинг 7.1. Сценарий, предназначенный для записи компакт-диска

#/bin/sh

# $1 - Рабочий каталог пользователя, выполняющего запись на диск

# $2 - Каталог с исходными файлами

# $3 - Имя пользователя, выполняющего запись на диск

mkisofs -J -r -о $1/image.iso $2

cdrecord speed=2 dev=4,0 $1/image.iso

mail -s "CD-R creation finished" $3

rm $1/image.iso

rm -r $2/*

Для создания описанного выше разделяемого объекта выполните следующие действия.

• Создайте сценарий

create-cd

/usr/local/bin

chmod а+x /usr/local/bin/create-cd

mkisofs

cdrecord

• Создайте разделяемый объект Samba с именем

[cd-create]

• Установите признак SUID для исполняемой программы

cdrecord

chmod a+s /usr/bin/cdrecord

forсе group

[cd-create]

postexec

root postexec

create-cd

cdrecord

После выполнения описанных выше действий вы можете использовать созданный разделяемый объект. Работая в системе Windows, можно смонтировать этот объект с помощью Network Neighborhood или My Network Places. Для этого надо щелкнуть правой кнопкой мыши на имени объекта и выбрать в контекстном меню пункт Map Network Drive. Затем следует связать разделяемый объект с именем устройства. Монтирования каталога пользователь должен скопировать файлы, предназначенные для записи на компакт-диск, на сервер Samba. Он может перемещать файлы в пределах каталога, копировать, удалять их и выполнять другие подобные действия. Когда пользователь будет готов начать запись, ему следует вставить чистый диск в устройство и размонтировать разделяемый объект, щелкнув правой кнопкой мыши на соответствующем ему пункте в окне My Computer и выбрав в контекстном меню пункт Disconnect.

К сожалению, при активизации этого пункта меню Windows может не разорвать соединение с объектом. В этом случае придется завершить сеанс работы или (при использовании Windows 9x/Me) перезагрузить компьютер. Через некоторое время (от нескольких секунд до нескольких минут) начнется запись на компакт-диск, по завершении которой пользователю, инициировавшему данную задачу, будет передано почтовое сообщение. Получив сообщение, пользователь может извлечь диск из устройства и проверить качество записи на своей машине.

Определение разделяемого объекта и код сценария, приведенные в данном примере, далеки от совершенства. В сценарии не приняты меры, запрещающие одновременное обращение к разделяемому объекту двух пользователей. Поэтому, если пользователь предпримет попытку начать запись до того, как другой пользователь извлечет свой диск из устройства, неминуемо возникнет проблема. Кроме того, сценарий не оповещает пользователя об ошибках. Например, если образ диска слишком велик и не может быть записан на имеющийся носитель, пользователь узнает об этом лишь тогда, когда попытается прочесть записанные данные. Более совершенный сценарий должен сообщать о возникающих проблемах или устранять их самостоятельно. Наконец, следует заметить, что различные версии Samba по-разному интерпретируют переменную

%P

Механизм псевдопринтеров позволяет записывать компакт-диски способом, более удобным для пользователей Windows 9x/Me, однако применение данного средства не так очевидно, как действия, основанные на использовании разделяемого объекта файлов. Данный подход заключается в следующем. Windows-клиент передает серверу Samba zip-архив, который содержит файлы, предназначенные для записи на компакт-диск. Разделяемый объект вызывает сценарий, который распаковывает архив, и записывает извлеченные из архива файлы на компакт-диск. Данный сценарий представляет собой разновидность сценария

create-cd

[cd-print]

path = /var/spool/samba

printable = Yes

print command = /usr/local/bin/print-cd %H %s %U %P; rm %s

Как и в предыдущем примере, вам необходимо уточнить особенности обработки переменной

%P

/var/spool/samba

Листинг 7.2. Сценарий для записи компакт-диска с помощью параметра print command

#!/bin/sh

# $1 - Рабочий каталог пользователя, выполняющего запись на диск

# $2 - Имя zip-файла

# $3 - Имя пользователя, выполняющего запись на диск

# $4 - Путь к zip-файлу

mkdir -p $1/cdr/samba

cd $1/cdr/samba

unzip $4/$2

mkisofs -J -r -o $1/image.iso ./

cdrecord speed=2 dev=4,0 $1/image.iso

mail -s "CD-R creation finished" $3

rm $1/image.iso

rm -r $1/cdr/samba

Сценарий и разделяемый объект, используемые в данном примере, надо сконфигурировать так же, как это было сделано для объекта

[cd-create]

create-cd

mkisofs

cdrecord

cdrecord

root

COPY

С:\> COPY FILE.ZIP\\SERVER\CD-PRINT

В результате выполнения данной команды содержимое файла

FILE.ZIP

SERVER

.ВАТ

COPY %1 \\SERVER\CD-PRINT

При вызове файла

.ВАТ

MAKECD.ВАТ

MAKECD FILE.ZIP

.ВАТ

.ВАТ

.ВАТ

.ВАТ

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

В качестве примера использования очереди печати можно привести задачу преобразования входных PostScript-данных в PDF-файлы. Для ее решения надо создать очередь подобную той, которая используется для обработки данных, сгенерированных с помощью PostScript-драйвера. Описание разделяемого объекта имеет следующий вид:

[pdf-create]

comment = Create a PDF file

path = /var/spool/samba

printable = Yes

print command = gs -dNOPAUSE -q -dBATCH -sDEVICE=pdfwrite \

 -sOutputFile=%H/%s.pdf %s; rm %s

На заметку

Символ

\

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

С помощью параметра

print command

gs

-dNOPAUSE

-q

-dBATCH

-sDEVICE=pdfwrite

-sOutputFile=%H/%s.pdf

.pdf

Samba — сложный инструмент, позволяющий организовать совместное использование файлов и принтеров. Этот продукт позволяет добиться большой степени гибкости при решении конкретных задач. Если Samba поставляется в составе дистрибутивного пакета Linux, то сформированный по умолчанию конфигурационный файл обеспечивает работу данного продукта в сети. Изменять конфигурацию Samba приходится в тех случаях, когда необходимо реализовать более сложные функции (например, когда сервер Samba должен действовать как контроллер домена). В составе конфигурационного файла также приходится определять разделяемые объекты. Как правило, изменения, вносимые в состав конфигурационного файла, не сложные и легко могут быть выполнены администратором средней квалификации. Одной из привлекательных особенностей Samba является способность выполнять заданные команды при наступлении определенных событий. Благодаря такой возможности Samba можно использовать для решения задач, непосредственно не связанных с разделением файлов и принтеров.

Протоколы Server Message Block (SMB)/Common Internet Filesystem (CIFS), рассмотренные в предыдущей главе, очень удобны для организации совместного доступа к файлам и принтерам клиентов, работающих под управлением DOS, Windows, OS/2 и многих других систем. Однако эти протоколы не поддерживают некоторые характеристики файловых систем UNIX и Linux, например, не позволяют задавать владельца файла и права доступа. Поэтому для разделения файлов в системах UNIX и Linux целесообразно использовать другой протокол, а именно NFS (Network Filesystem — сетевая файловая система). В отличие от SMB/CIFS, NFS не поддерживает принтеры. Вопросы совместного использования принтеров будут рассмотрены в главе 9.

Как правило, серверы NFS применяются для разделения файлов в системах UNIX и Linux. Необходимость в совместном доступе к файлам может возникнуть по разным причинам. Возможно, вы захотите хранить на сервере программы большого объема для того, чтобы их можно было запускать на клиентских машинах с дисками малого размера. Часто сервер NFS используют как централизованное хранилище файлов; изменения, внесенные в файл, сразу становятся доступными всем пользователям. Если в сети применяется централизованная система регистрации, например Kerberos, целесообразно размещать на сервере NFS рабочие каталоги пользователей. Такой подход обеспечивает высокую степень гибкости. В этом случае пользователь перестает быть "привязанным" к своей рабочей станции и может регистрироваться с любого компьютера и работать со своими данными. Существует множество других ситуаций, в которых оправдано применение серверов NFS. Например, вы можете разместить рабочие каталоги пользователей на локальных компьютерах, а сервер NFS использовать для обмена файлами или организовать чтение данных из статической базы, расположенной на сервере.

Несмотря на то что система NFS ориентирована на использование в сетях, состоящих в основном из компьютеров под управлением UNIX, клиенты и серверы NFS разработаны и для других систем, например для Windows, OS/2 и MacOS. Выбор инструмента разделения файлов зависит от конкретной ситуации. В большинстве случаев наилучшие результаты достигаются при использовании в системе Linux протокола, специально разработанного для других систем. Примером подобного решения является организация сервера SMB/CIFS на компьютере под управлением Linux. Кроме того, для настройки сервера Samba в системе Linux потребуется намного меньше времени и усилий, чем для инсталляции и конфигурирования средств поддержки NFS на клиентских компьютерах. Если же в сети в основном используются машины под управлением UNIX и Linux и лишь несколько компьютеров Windows или MacOS, предпочтительнее использовать для разделения файлов систему NFS. (Система MacOS X базируется на UNIX, поэтому средства поддержки NFS хорошо работают в этой среде, однако для их настройки с помощью графического интерфейса MacOS придется затратить много усилий.)

Внимание

Как вы узнаете из последующих разделов, в процессе работы NFS не проверяет пароли и не реализует другие подобные способы контроля доступа. Вместо этого NFS использует принцип доверия, согласно которому сервер полагается на средства аутентификации пользователей, применяемые на клиентских машинах. На сервере NFS вы определяете узлы, пользующиеся доверием, и задаете их IP-адреса. Данный механизм защиты не сложно обойти, используя фальшивый IP-адрес или изменяя конфигурацию локальных компьютеров, поэтому, планируя систему NFS, надо уделять особое внимание безопасности данных. В частности, нельзя допускать передачу секретной информации средствами NFS. Если возникает необходимость обмена важными данными по локальной сети, для этого лучше использовать Samba или другие механизмы передачи, например, программу scp, которая входит в состав пакета SSH (Secure Shell — защищенная оболочка).

В 1998-2002 г. средства поддержки NFS в системе Linux претерпели ряд важных изменений; некоторые из таких изменений рассматриваются в данном разделе. Если вы используете старые дистрибутивные пакеты или устаревшую документацию, представленные здесь сведения позволят вам составить впечатление о реальном положении дел. Чаще всего сервер NFS, поставляемый в составе Linux, можно использовать для обмена данными, но в некоторых случаях, чтобы реализовать NFS-взаимодействие с другими компьютерами, вам придется установить более новое (а возможно, и более старое) программное обеспечение. Информацию о последних разработках в области NFS-обмена в системе Linux можно получить, обратившись по адресу

http://nfs.sourceforge.net

Сервер NFS в основном предназначен для обмена данными между файлами на диске и сетевым интерфейсом. В обычных условиях сервер NFS выполняется в системе Linux в пользовательском режиме. Это означает, что сервер не имеет специальных привилегий и не использует средства ядра. Другими словами, информация читается с диска с помощью функций ядра, затем прочитанные данные передаются программе, работающей в пользовательском режиме, а после этого они поступают на сетевой интерфейс. (Данные, принятые посредством сетевого интерфейса и записываемые на диск, проходят этот путь в обратном направлении.) Необходимость обмена информацией между ядром и программой, выполняющейся в пользовательском режиме, снижает производительность системы. Чтобы устранить этот недостаток, надо изменить коды сервера NFS и конфигурацию ядра так, чтобы передачей данных занимались только функции ядра. Для этого необходимо установить опцию NFS Server Support в подменю Network File Systems меню File Systems (рис. 8.1). Сделав это, вы передадите ядру часть обязанностей сервера NFS. Кроме того, надо использовать код сервера NFS, непосредственно ориентированный на взаимодействие с ядром. Обычно программа, реализующая такой сервер, называется

knfsd

nfsd

Рис. 8.1. В ядре Linux реализованы средства поддержки как клиента, так и сервера NFS

На заметку

В инструментах настройки ядра Linux также присутствует опция NFS File System Support. Эта опция включает в ядро средства поддержки клиента NFS, которые совместно с утилитой mount позволяют монтировать каталоги, экспортируемые удаленным сервером NFS, в локальной файловой системе. Средства поддержки клиента и сервера NFS в составе ядра не связаны друг с другом, и вы можете независимо включать или отключать любую из этих опций.

Подобно другим протоколам и программам, средства NFS периодически пересматриваются и реализуются их новые версии. В 2002 г. широко использовалась последняя на тот момент версия 3 системы NFS, или NFSv3. (На самом деле в это время уже существовала версия NFSv4, но она находилась в стадии разработки. Дополнительную информацию о состоянии дел с NFSv4 можно найти, обратившись по адресу

http://www.ntsv4.org

Если вы хотите обеспечить работу с сервером NFSv3, в котором операции NFS ускоряются за счет ядра, вы должны при установке конфигурации ядра выбрать опцию Provide NFSv3 Server Support (которая является подопцией обсуждавшейся ранее опции NFS Server Support). Аналогично, для использования средств NFSv3 клиентом надо выбрать опцию Provide NFSv3 Client Support. Протокол NFS обеспечивает совместимость с ранними версиями, поэтому если в вашей системе поддерживаются средства NFSv3, а на других компьютерах установлены лишь средства NFSv2, то узлы сети могут обмениваться данными по протоколу NFSv2.

Если вы хотите обмениваться данными по протоколу NFSv3, то, помимо установки опций ядра, вам надо использовать утилиты, поддерживающие эту версию. Для обеспечения работы клиента вам понадобятся

nfs-utils

mount

rpm

dpkg

mount

$ rpm -q mount mount-2.11b-5mdk

В данном случае при выполнении команды было обнаружено, что в системе инсталлирована версия 2.11b утилиты mount, которая подходит для обеспечения работы клиента NFSv3.

Большинство серверов TCP/IP принимают обращения от клиентов через порт с определенным номером. Так, например, сервер, реализующий протокол SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты), использует при работе порт 25, а Web-сервер, поддерживающий протокол HTTP (Hypertext Transfer Protocol — протокол передачи гипертекстовой информации), — порт 80. Обмен с сервером также может быть организован через нестандартный порт, но обычно конфигурацию сервера выбирают так, чтобы для обращения к ним не требовалась специальная настройка клиентов. NFS представляет собой класс протоколов, которые действуют несколько по-иному. При работе NFS применяется процедура отображения портов. Специальная программа связывается с фиксированным портом (номер порта 111) и перенаправляет обращения клиентов на требуемые порты. (NFS чаще всего использует порт UDP 2049, но NFSv3 предполагает также работу через порт TCP 2049.) Весь процесс обмена данными базируется на применении протокола RPC (Remote Procedure Call — удаленный вызов процедур).

Процедуру отображения портов реализует программа

portmap

portmap

inetd

/etc/hosts.deny

portmap : ALL

Затем можно разрешить обращение к

portmap

/etc/hosts.allow

portmap : 192.168.1.

На заметку

В главе 4 обсуждались вопросы настройки TCP Wrappers, в частности, способы описания клиентов. При работе с программой отображения портов не следует указывать доменные имена клиентов, так как процедура преобразования имен может привести к повторному обращению к

portmap

. Это, в свою очередь, приведет к необходимости нового преобразования адресов. Такая бесконечная последовательность вызовов не даст никакого результата, а лишь создаст дополнительную нагрузку на процессор. Поэтому для указания клиентов надо использовать их IP-адреса.

Для обеспечения NFS-обмена недостаточно вызвать программу отображения портов. Вам также надо определить разделяемые каталоги (этот вопрос будет рассматриваться в следующем разделе) и запустить сам сервер NFS. Для запуска сервера NFS используется сценарий SysV (обычно он называется

nfs

restart

/etc/rc.d/init.d/nfs restart

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

mount

Для управления сервером NFS используется файл

/etc/exports

экспортируемый_каталог клиент1(опции) [клиент2(опции) [...]]

Имя экспортируемого каталога может иметь вид

/home

/usr/X11R6

/etc

/proc

/dev

/dev

/dev

nodev

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

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

• Имя одного компьютера. Если вы укажете имя конкретного компьютера, например

larch

larch.threeroomco.com

• Группа клиентов, определенная с помощью символов групповой операции. При описании клиента могут быть использованы знак вопроса (

?

*

*.threeroomco.com

threeroomco.com

?

*

.

*.threeroomco.com

mulberry.bush.threeroomco.com

• Группа NIS. Если в вашей сети присутствует сервер NIS (Network Information Service — сетевая информационная служба), вы можете задавать группы NIS, указывая в начале имени группы символ

@

• Группа клиентов, заданная с помощью IP-адреса сети. Ограниченную группу клиентов можно описывать, указывая адрес и маску подсети, например 255.255.0.0. Допускается также определение маски подсети как число битов, соответствующих адресу посети, например 172.19.0.0/16. (Задавая IP-адрес одного компьютера, маску подсети можно не указывать.)

С точки зрения безопасности системы предпочтительнее использовать для идентификации компьютеров их IP-адреса, так как если злоумышленник получит доступ к серверу DNS или NIS, доменные имена и имена групп могут быть переопределены. IP-адрес также можно подделать, особенно если попытка незаконного доступа осуществляется из локальной сети, но использование IP-адреса исключает по крайней мере один способ атаки. С другой стороны, указание компьютеров с помощью IP-адресов может быть неудобным, в особенности если адреса часто меняются. Так, например, происходит, если адреса компьютерам выделяет сервер DHCP, работа которого рассматривалась в главе 5 данной книги.

Совет

Как вы уже знаете, доступ к программе

portmap

можно ограничить с помощью TCP Wrappers. При этом указание идентификаторов клиентов в описании экспортируемых каталогов может показаться излишней мерой. Это не совсем верно. Ограничивая доступ к серверу, надо использовать для этого все доступные способы. Дело в том, что средства, блокирующие обращения, могут быть сконфигурированы неверно, а при наличии недостатков в системе защиты их можно обойти. В этом случае избыточные механизмы ограничения доступа будут очень полезны. Рекомендуется также запретить обращение ряда узлов к серверу, применяя для этого фильтрацию пакетов. Данный способ будет рассматриваться в главе 25.

На заметку

В состав многих дистрибутивных пакетов Linux входят средства брандмауэра; они легко конфигурируются в процессе инсталляции. Некоторые из них, например брандмауэр для Red Hat, уже настроены с учетом блокирования доступа к серверу NFS, поэтому в некоторых случаях разрешить доступ бывает достаточно трудно. Если у вас возникнут проблемы, связанные с взаимодействием клиентов с сервером NFS, ознакомьтесь с материалом, изложенным в главе 25, он поможет вам изменить настройку брандмауэра.

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

• 

sync

async

async

• 

wdelay

no_wdelay

wdelay

no_wdelay

wdelay

Многие из опций, которые указываются для каждого клиента в файле

/etc/exports

/etc/exports

• 

secure

insecure

root

insecure

insecure

• 

ro

rw

ro

rw

knfsd

ro

rw

• 

hide

nohide

/usr

/usr/local

/usr

/usr/local

hide

nohide

hide

nohide

hide

• 

noaccess

/home

/home/abrown

/etc/exports

/home

/home/abrown

noaccess

/home/abrown

• 

subtree_check

no_subtree_check

no_subtree_check

subtree_check

• 

root_squash

no_root_squash

root

root

root

no_root_squash

• 

all_squash

no_all_squash

all_squash

no_all_squash

all_squash

• 

anonuid

anongid

nobody

anonuid

anongid

root

Пример файла

/etc/exports

/usr/X11R6

/home

noaccess

/home/abrown

/usr/X11R6

/home

gingko

/usr/X11R6

/hom

gingko

/usr/X11R6

/home

Листинг 8.1. Пример файла

/etc/exports

/usr/X11R6 gingko(ro,anonuid=504) 192.168.4.0/24(ro)

/home gingko(rw,no_subtree_check) 192.168.4.0/255.255.255.0(rw)

/home/abrown (noaccess)

На стороне клиента экспортируемые каталоги выглядят как разделы диска. Для их монтирования используется команда

mount

сервер:путь_к_монтируемому_каталогу

/home

/mnt/userfiles

# mount larch:/home /mnt/userfiles

Если вы хотите, чтобы экспортируемый каталог был постоянно доступен, вам надо создать запись в файле

/etc/fstab

mount

nfs

mount

/etc/fstab

mount

larch:/home /mnt/userfiles nfs defaults 0 0

В результате пользователь, обращаясь к каталогу

/mnt/userfiles

/home

larch

Экспортируя каталоги и содержащиеся в них файлы, сервер NFS экспортирует также права доступа к ним. Информацию о пользователях и правах можно применять для контроля обращений к файлам и каталогам. Эти средства можно использовать даже для управления доступом со многих компьютеров, например, в случае, если один сервер NFS обслуживает несколько клиентов. Однако при этом может возникнуть проблема, которая состоит в следующем. Для идентификации пользователей в системе NFS применяются UID и GID. Если такие идентификаторы не совпадают на клиентах и на сервере, это может угрожать безопасности системы. Способы разрешения данной проблемы будут рассмотрены ниже в этой главе.

В последующих разделах будут описаны некоторые опции программы mount, которые влияют на поведение клиентов и серверов NFS и могут быть использованы для увеличения производительность и решения других задач. Ряд опций утилиты mount перечислен ниже.

• 

hard

• 

soft

timeo=время

• 

nodev

• 

nosuid

• 

noexec

Перечисленные опции можно задавать при вызове команды

mount

-о

# mount -о noexec,nodev larch:/home /mnt/userfiles

Если вы создаете запись в файле

/etc/fstab

defaults

Выше были описаны два способа повышения производительности системы: поддержка NFS ядром (совместно с программой

knfsd

• Оптимизация размера передаваемых блоков. Опции

rsize

wsize

mount

larch: /home /mnt/userfiles -о rsize=8192

/etc/fstab

defaults

• Оптимизация за счет исключения информации об обращении к файлу. Опция

noatime

mount

• Выбор количества экземпляров сервера NFS. Как правило, в сценарии запуска сервера NFS предусматривается одновременное выполнение восьми экземпляров этой программы. Если нагрузка на систему не велика, с ней может справиться и меньшее количество серверов. Если же система постоянно обрабатывает запросы, восьми серверов может оказаться недостаточно. Недостаток серверов при большой нагрузке на систему приводит к что для установления соединения с клиентом потребуется неоправданно большое время. Увеличить производительность можно, выбрав наиболее подходящее число экземпляров сервера. Обычно это значение задается в начале сценария и имеет вид

RPCNFSDCOUNT=8

• Устранение причин снижения производительности, не связанных с работой средств поддержки NFS. Производительность NFS может снижаться по ряду причин, многие из которых непосредственно не связаны с работой сети. Например, если ваша сетевая карта работает медленно, эффективность NFS-обмена будет низкой. Качество работы сервера NFS существенно зависит от используемого жесткого диска. Важно, чтобы данное устройство было достаточно быстродействующим и не создавало излишней нагрузки на центральный процессор. (Для сервера хорошо подойдет EIDE-контроллер с поддержкой адаптера DMA или SCSI; производительность устройств SCSI выше, чем производительность дисков EIDE.)

Если производительность сервера NFS недостаточна, необходимо прежде всего выяснить, что является источником проблем: программное обеспечение сервера NFS, клиент-программы или конфигурация сети. Возможно также, что производительность снижается по другим причинам, например, из-за недостаточной эффективности работы жестких дисков. Выяснить это можно, выполняя тестирование с использованием различных протоколов и с участием разных клиентов. (Для проверки производительности жестких дисков можно вызвать команду

hdparm

-t

На компьютере под управлением Linux, работающем независимо от других машин, за отображение пользовательских имен в числовые идентификаторы (UID) отвечает файл

/etc/passwd

/etc/group

/etc/passwd

На заметку

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

Самым простым решением описанной выше проблемы отображения пользовательских имен является синхронизация UID и GID на клиентской машине и на сервере. Например, если некоторому пользователю на сервере соответствует идентификатор 504, необходимо принять меры к тому, чтобы и на клиентском компьютере его UID был также равен 504. Аналогичным образом должны быть синхронизированы GID. Если сеть насчитывает большое число компьютеров, синхронизация UID и GID займет очень много времени. Однако в небольшой сети, при условии, что число пользователей в ней невелико, действия по синхронизации могут быть выполнены относительно просто. Привести в соответствие существующие пользовательские идентификаторы можно с помощью утилиты

usermod

abrown

# usermod -u 504 abrown

При выполнении этой команды будет изменена запись в файле

/etc/passwd

Команда

groupmod

usermod

-g

project3

# groupmod -g 127 project3

Внимание

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

/tmp

.

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

abrown

alyson

alyson

abrown

Обеспечить синхронизацию UID и GID можно, используя отдельный сервер для аутентификации пользователей как на клиентских компьютерах, так и на сервере NFS. В этом случае пользователь получит один и тот же UID, независимо от компьютера, на котором он зарегистрируется, а конкретной группе будет соответствовать единственный GID. В качестве такого средства аутентификации можно использовать систему Kerberos, которая была рассмотрена в главе 6. Кроме того, реализация NFS для Linux включает поддержку аутентификации NIS; для этой цели используется опция

map_nis

/etc/exports

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

gingko

larch

james

james

larch

alyson

gingko

larch

Jennie

samuel

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

map_static

/etc/exports

/home larch(rw,map_static=/etc/nfs/larch-map)

Таблица 8.1. Идентификаторы пользователей на двух компьютерах

Эта запись сообщает системе о том, что, предоставляя каталог

/home

larch

/etc/nfs/larch-map

map_static

larch-map

#

uid

gid

-

Листинг 8.2. Пример содержимого файла соответствия идентификаторов

# Отображение идентификаторов для клиента larch

#   удаленный локальный

uid 0-99      -        # доступ запрещен

uid 504       500

uid 501       501

uid 503       502

uid 502       503

gid 0-99      -        # доступ запрещен

gid 100-102   100

В файле соответствия необходимо задать идентификаторы всех пользователей. Например, в листинге 8.2 указан UID 501, который отображается в тот же идентификатор на сервере. Отсутствующий UID приведет к некорректному отображению, что, в свою очередь, станет источником проблем. В листинге 8.2 явным образом указано, что попытки обращения с системных UID (с номерами меньше 100) должны отвергаться. Аналогичное правило задано для идентификаторов групп 0-99. GID 100-102 отображаются в GUID 100. Несмотря на то что вы можете отобразить диапазон клиентских идентификаторов в единственный идентификатор на сервере, обратное действие не имеет смысла. При попытке пользователя с определенным UID на стороне клиента создать файл сервер не сможет выбрать локальный идентификатор.

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

Решить проблему синхронизации пользовательских идентификаторов можно, задавая на стороне сервера опцию

map_daemon

ugidd

rpc.ugidd

ugidd

ugidd

/etc/hosts.allow

nobody

NFS — чрезвычайно полезный инструмент, позволяющий обеспечить разделение файлов в системах UNIX и Linux. В отличие от Samba, NFS обеспечивает поддержку данных о владельцах файлов и правах доступа. Настройка NFS осуществляется несколько проще, чем конфигурирование средств Samba. С другой стороны, NFS использует принцип доверия, поэтому при работе с данной системой приходится предпринимать меры для синхронизации идентификаторов пользователей на клиентских машинах и серверах или хранить сведения о соответствии идентификаторов в специальном конфигурационном файле.

Система печати, используемая в Linux, первоначально была разработана для BSD UNIX. Эта система, которую также называют по имени ее основного компонента LPD (Line Printer Daemon — демон принтера), намного проще, чем системы печати Windows и MacOS, и в то же время обеспечивает гораздо более высокую гибкость. Система LPD позволяет передавать задания на печать по сети; она включает и сервер печати, и клиент-программу. В системе LPD, в отличие от других систем, не предусмотрена поддержка драйверов принтеров. Для согласования с конкретными типами устройств применяются дополнительные пакеты (например, Ghostscript, информацию о котором можно получить по адресу

http://www.cs.wise.edu/~ghost/

В данной главе рассматриваются система LPD, а также новые протоколы печати, которые в последнее время становятся все более популярными. Здесь не затрагиваются вопросы настройки компьютера для работы с конкретной моделью принтера; подобную информацию вы сможете найти в документации на вашу систему или в книгах, представляющих собой введение в систему Linux. В начале главы приводятся общие сведения о системе LPD, в частности, обсуждается функционирование сервера LPD и выбор программного обеспечения печати для работы в Linux. Затем рассматриваются вопросы настройки каждой из трех широко распространенных систем печати: BSD LPD, и CUPS.

Сетевая система печати работает подобно средствам разделения файлов. Клиент-программа передает на сервер печати файл, предназначенный для вывода на принтер (это можно сравнить с передачей файла на файловый сервер). Основное отличие между данными процессами заключается в том, что на файловом сервере файл сохраняется на диске для дальнейшего использования, а на сервере печати файл передается на принтер и после обработки удаляется. Сходство между этими двумя задачами приводит к тому, что в некоторых случаях они решаются посредством одного протокола. В качестве примера можно привести протоколы SMB/CIFS, реализованные в рамках одного продукта (Samba). В системе UNIX для организации совместного использования файлов и принтеров традиционно применяются две различные системы: NFS и LPD.

В составе стандартных инструментов LPD интегрированы средства локальной и сетевой печати; таким образом, обеспечить прием данных, предназначенных для вывода на принтер, или передачу заданий на печать можно, затратив сравнительно небольшие усилия. В небольших сетях система сетевой печати позволяет сократить объем ресурсов, требуемых для организации работы. Так, например, вместо десяти низкоуровневых лазерных принтеров (стоимостью $300 каждый) можно приобрести за $1500 мощный принтер и использовать его как сетевое устройство печати. Сэкономленные $1500 можно потратить на цветной струйный принтер или другие подобные устройства. Одним из компонентов, позволяющих реализовать подобную конфигурацию, является LPD.

LPD — не единственный сетевой протокол печати. Как было сказано выше, выполнение подобных функций обеспечивают протоколы SMB/CIFS. Работу средств печати можно реализовать с помощью AppleTalk (в системе Linux для этого используется Netatalk). Таким образом, возникает вопрос: в каких случаях оправдано применение LPD, а когда следует отдать предпочтение другим инструментам? Для того чтобы ответить на него, следует рассмотреть следующие дополнительные вопросы.

• Какой протокол наиболее подходит для клиента? Linux поддерживает самые разнообразные протоколы печати, поэтому компьютер под управлением Linux может выполнять функции сервера печати для различных клиентов. Поскольку обычно число клиентов в сети значительно превышает число серверов, целесообразно выбрать тот протокол печати, который лучше всего поддерживается большинством клиентов. Если клиентские компьютеры работают под управлением UNIX или Linux, таким протоколом является LPD. При использовании клиентов DOS, Windows или OS/2 лучше выбрать SMB/CIFS. Для клиентов Macintosh наилучшим выбором будет AppleTalk, хотя MacOS X также хорошо поддерживает LPD.

• Какие из протоколов поддерживают необходимые вам возможности? Процедура сетевой печати реализуется проще, чем разделение файлов. Например, при печати не приходится поддерживать признаки прав доступа. Тем не менее для каждого протокола характерны свои особенности, например, по-разному выполняется процедура аутентификации. Если протокол, который наиболее подходит для большинства клиентов, не обеспечивает поддержку необходимых вам средств, надо рассмотреть вопрос об использовании другого протокола.

Вопрос поддержки специальных средств заслуживает более подробного рассмотрения. Подобно NFS, LPD использует принцип доверия, т. е. сервер полагается на результаты, полученные при аутентификации пользователя на стороне клиента. Поэтому решение о предоставлении доступа принимается на основании IP-адреса клиентского компьютера. Этот метод удобен в тех случаях, когда на клиентских компьютерах могут работать различные пользователи, но он обеспечивает гораздо более слабую защиту, чем способ, предполагающий проверку пользовательского имени и пароля. Если вам необходимо, чтобы вопрос о предоставлении доступа к серверу печати решался на основании проверки пароля, используйте протоколы, которые обеспечивают такую возможность, например протоколы SMB/CIFS. Однако при этом необходимо принять во внимание, что если клиенты будут работать под управлением UNIX или Linux, вам, возможно, придется хранить пароли в отдельном конфигурационном файле, доступном как клиентам, так и серверам, а это вряд ли обеспечит более высокую степень защиты, чем принцип доверия. Новый протокол IPP (Internet Printing Protocol — межсетевой протокол печати), используемый CUPS, предусматривает проверку пользовательского имени и пароля, но при желании вы можете не использовать эту возможность.

Несмотря на то что на клиентских компьютерах, выполняющихся под управлением Windows, поддерживаются средства LPD, если такие клиенты присутствуют в сети, для разделения принтеров чаще всего используют протоколы SMB/CIFS. Если же на основной части клиентских машин установлены UNIX, Linux MacOS и другие системы, не поддерживающие SMB/CIFS, следует рассмотреть вопрос о применении других протоколов.

При организации сети вам придется также решать вопрос о том, в какой операционной среде целесообразно реализовать сервер печати. Большинство серверов печати, доступных для Linux, могут также выполняться и в различных версиях UNIX. Необходимо выбрать платформу, наиболее пригодную для вашей сети. Если вам необходимо организовать совместное использование принтеров клиентскими программами, работающими в Linux, UNIX, Windows, MacOS и других операционных системах, на роль универсальной платформы печати лучше всего подойдет Linux.

Перед администратором часто возникает вопрос: следует ли использовать в качестве сервера печати специальное сетевое устройство? Такие устройства обычно комплектуются Ethernet-интерфейсом и предоставляют параллельные, последовательные и USB- подключения принтеров. Протокол поддержки сервера печати обычно реализован в них на аппаратном уровне. Такое устройство удобно применять в том случае, если вы не хотите использовать в качестве сервера печати обычный компьютер. Подобное решение может быть принято из соображений безопасности или тогда, когда компьютер, рассматриваемый в качестве претендента на роль сервера печати, должен время от времени выключаться. В качестве выделенных серверов печати могут выступать некоторые сетевые принтеры.

Совет

Выделенный сервер печати можно построить на базе старого компьютера; для этой цели подойдет даже компьютер с процессором 386. На нем надо установить систему Linux и отключить все программы-серверы и другие инструменты, непосредственно не участвующие в поддержке функций печати. Если быстродействие процессора достаточно велико, на данном компьютере можно установить Ghostscript, что позволит обрабатывать файлы PostScript. Таким способом можно эмулировать сетевой принтер PostScript. Если на компьютере есть несколько параллельных или USB-портов, к нему можно подключить несколько принтеров. Мощный компьютер может не только выступать в роли сервера печати, но и выполнять при этом задачи, непосредственно не связанные с выводом на принтер.

Различные варианты UNIX и Linux позволяют использовать большое количество различных пакетов, предназначенных для организации печати, большинство из которых поддерживает протокол LPD. В 2001 г. наиболее популярными пакетами для Linux были следующие.

• Сервер BSD LPD. Этот пакет в течение длительного времени был стандартным для Linux. При выполнении многих Linux-программ предполагается, что в системе установлены средства BSD LPD. По этой причине LPRng и CUPS эмулируют BSD LPD, хотя делают это несколько по-разному. В BSD LPD используются предельно простые средства контроля доступа; это стало одной из причин перехода к другим системам печати.

• Пакет LPRng. Данная система печати, информацию о которой можно найти в документе

http://www.astart.com/lprng/LPRng.html

• Common UNIX Printing System (CUPS). Информация о CUPS находится на сервере

http://www.cups.org

На заметку

В UNIX-подобных операционных системах используются также другие системы печати. Одна из них применяется в некоторых версиях UNIX, построенных на базе SysV. Эта система печати может взаимодействовать с BSD LPD, но команды, используемые в ней, несколько отличаются от BSD LPD. Так, например, для передачи задания на печать вместо

lpr

следует задавать команду

lр

.

В табл. 9.1 перечислены системы печати, поставляемые в составе некоторых популярных дистрибутивных пакетов Linux. В случае, если система печати отсутствует в дистрибутивном пакете, вы можете установить ее отдельно, но для настройки программного обеспечения придется затратить дополнительные усилия. Одна из задач, которые вам придется решить, — обеспечить автоматический запуск сервера (этот вопрос рассматривался в главе 4).

Таблица 9.1. Стандартные программы печати в составе дистрибутивных пакетов Linux

На заметку

Различия между "стандартными" и "альтернативными" системами печати, приведенными в табл. 9.1, весьма условны. Например, при инсталляции Mandrake вы можете выбирать, какая из систем печати должна быть установлена: LPRng или CUPS, а в Debian по умолчанию средства печати не устанавливаются вовсе.

При составлении стандартной документации на Linux, как правило, предполагается, что в системе установлены средства печати BSD LPD. Большая часть приведенных в документации сведений справедлива также для системы LPRng, различаются лишь детали, связанные с ограничением доступа к сетевому серверу печати. Что касается CUPS, то конфигурационные файлы этой системы существенно отличаются от BSD LPD и LPRng, поэтому документы, которые касаются конфигурации системы печати, не применимы к CUPS.

Среди средств настройки сервера BSD LPD наиболее важны два файла:

/etc/hosts.lpd

/etc/printcap

/etc/printcap

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

/etc/hosts.lpd

@

+

+

-

/etc/hosts.lpd

gingko

+@group1

group1

oak.threeroomco.com

group1

Листинг 9.1. Пример файла

/etc/hosts.lpd

gingko

birch.threeroomco.com

192.168.1.7

+@group1

-oak.threeroomco.com

В файле

/etc/hosts.lpd

#

Внимание

Аналогично

/etc/hosts.lpd

можно использовать файл

/etc/hosts.equiv

. Файл

/etc/hosts.equiv

применяется не только для решения задач, связанных с печатью; он также предоставляет доступ для клиентов, которые используют

rlogin

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

В файле

/etc/printcap

printcap

:

\

Большинство деталей настройки принтеров с помощью файла

/etc/printcap

• 

lр

lp=/dev/lp0

/dev/lp0

lр=

• 

rm

oak

rm=oak

• 

rp

rp

rm

rp

inkjet

/etc/printcap

rp=inkjet

inkjet

lр1

canon

Таким образом, имея локальную очередь печати, вы можете преобразовать ее в сетевую очередь, заменив опцию

lp

rm

rp

rm

rp

lp

rm

rp

Если сервер печати не поддерживает LPD-соединения, необходимо использовать более сложную конфигурацию. Например, сервер может быть настроен для обработки заданий на печать, передаваемых средствами SMB/CIFS или AppleTalk. В таком случае вам надо создать сценарий, который обрабатывал бы задания на печать, и вызывать его с помощью опции

if

С точки зрения пользователя система печати LPRng работает так же, как и BSD LPD. Это вполне закономерно, так как средства LPRng были разработаны для замены BSD LPD. LPRng использует файл

/etc/printcap

/etc/lpd.perms

Файл

/etc/lpd.perms

lpd.perms

/var/spool/lpd/имя_очереди

/etc/lpd.perms

Независимо от расположения файла

lpd.perms

#

/etc/hosts.lpd

DEFAULT ACCEPT

DEFAULT REJECT

ACCEPT [ключ=значение[, значение]* ]*

REJECT [ключ = значение [, значение]* ]*

Первые два типа записей задают политику системы по умолчанию, т. е. общие правила по предоставлению или запрету доступа. В большинстве пакетов LPRng, поставляемых в составе дистрибутивных версий Linux, в файле

/etc/lpd.perms

DEFAULT ACCEPT

localhost

ACCEPT

REJECT

Опции

ACCEPT

REJECT

lpq

lprm

lрс

NOT

/

Таблица 9.2. Ключи и их значения, используемые при формировании файла

lpd.perms

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

/etc/lpd.perms

ACCEPT SERVICE=M SAMEHOST SAMEUSER

ACCEPT SERVICE=M SERVER REMOTEUSER=root

REJECT SERVICE=M

В этих трех строках указано, кто может использовать утилиту

lprm

SERVICE=M

lprm

SERVICE

SAMEHOST

SAMEUSER

SERVER

REMOTEUSER=root

root

lprm

lpd.perms

ACCEPT SERVICE=M

REJECT SERVICE=M

ACCEPT

REJECT

Как было сказано ранее, во многих случаях система LPRng по умолчанию настраивается так, чтобы она принимала обращения с любого узла. Подобная конфигурация недопустима с точки зрения безопасности, так как любой внешний пользователь может запустить задание на печать, в результате чего будут расходоваться бумага и ресурсы принтера. Кроме того, при обнаружении недостатков в защите LPRng неограниченный доступ к этой системе предоставит дополнительную возможность для взлома принтера. Исходя из этих соображений возможности пользователей по обращению к серверу печати необходимо ограничить. Сделать это можно с помощью брандмауэра (вопросы настройки брандмауэра будут рассмотрены в главе 25). Кроме того, я настоятельно рекомендую вам принять дополнительные меры по защите самой системы LPRng. Предположим, что вы настраиваете сервер печати, который должен обрабатывать задания, переданные из сети 172.22.0.0/16, и с компьютера, на котором установлен сервер; обращения с других узлов должны отвергаться. Сделать это можно с помощью следующих записей:

ACCEPT SERVICE=X SERVER

REJECT SERVICE=X NOT REMOTEIP=172.22.0.0/16

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

REMOTEIP=127.0.0.1

SERVER

REJECT

ACCEPT

Файл

/etc/printcap

lp

rm

rp

Системы BSD LPD и LPRng используют протокол LPD, поэтому вы можете сконфигурировать клиент LPRng для печати на сервере BSD LPD и наоборот. Подобное взаимодействие можно также организовать с системой CUPS. Кроме того, CUPS поддерживает расширенный протокол, который может использоваться только в рамках этой системы.

Система печати CUPS, предназначенная для использования в Unix и Linux, обеспечивает чрезвычайно высокую степень гибкости. Вместо того чтобы вносить изменения в пакет BSD LPD (что по сути надо было сделать при создании LPRng), разработчики CUPS создали полностью новый набор базовых средств, поддерживающих вывод на принтер в различных системах, в том числе в Linux. Часть этих базовых средств предназначена для обеспечения совместимости, поэтому пользователи могут задавать привычные им команды для вывода данных на печать. Клиенты CUPS могут работать с серверами LPD, а клиенты LPD, в свою очередь, могут передавать задания на сервер CUPS. Кроме того, в системе CUPS реализована поддержка нового протокола IPP, который базируется на протоколе HTTP, используемом Web-серверами и броузерами. В системе CUPS можно передавать на сервер информацию о типе файла, что упрощает выбор принтера; для описания возможностей принтеров могут использоваться файлы PPD (PostScript Printer Description); средства просмотра принтеров дают возможность клиенту искать нужные принтеры в сети; при этом не требуется настройка клиентской системы для работы с конкретным устройством. При условии повсеместного применения CUPS перечисленные свойства системы существенно упростят конфигурацию как локальных, так и сетевых средств печати.

Работу с CUPS усложняет одна особенность этой системы: конфигурационные файлы существенно отличаются от файлов, используемых в системах BSD LPD и LPRng. Даже если вы хорошо знакомы с данными системами, это не поможет вам при работе с CUPS; средства ее настройки придется изучать специально. Если вы предпочитаете работать с инструментами, предоставляющими графический интерфейс, можете воспользоваться KUPS (

http://cups.sourceforge.net/kups/

http://www.easysw.com/printpro/

http://localhost:631

На заметку

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

http://www.cups.org/sam.html

.

Работой сервера CUPS управляет файл

/etc/cups/cupsd.conf

/etc/cups/printers.conf

/etc/cups/classes.conf

lpadmin

cupsd.conf

Файл

cupsd.conf

• 

Allow

from

All

None

Allow

Location

• 

AuthClass

AuthClass

Anonymous

User

System

Group

Anonymous

System

sys

SystemGroup

Group

AuthGroupName

• 

BrowseAddress

BrowseAddress

• 

BrowseAllow

BrowseAllow

from

• 

BrowseDeny

BrowseAllow

• 

BrowseOrder

BrowseAllow

BrowseDeny

BrowseOrder

BrowseOrder Allow, Deny

BrowseOrder Deny, Allow

• 

BrowseInterval

BrowseTimeout

• 

BrowsePoll

• 

BrowsePort

• 

BrowseTimeout

BrowseInterval

• 

Browsing

On

Off

On

• 

Deny

Allow

Deny

Location

• 

HostNameLookups

Off

On

Double

Off

On

Double

Double

• 

Listen

Listen 192.168.23.8:631

Listen

• 

Location

Location

Allow

Deny

Location

</Location>

<Location>

/admin

/classes

/jobs

/printers

• 

MaxClients

MaxClients

• 

Order

BrowseOrder

Allow

Deny

Order Allow, Deny

Allow

Order Deny, Allow

• 

Port

Port

Файл

/etc/cups/cupsd.conf

<Location /printers>

 BrowseAllow from 127.0.0.1

 BrowseAllow from 172.22.0.0/16

 Allow from 127.0.0.1

 Allow from 172.22.0.0/16

</Location>

Поскольку в директиве

Location

/printers

/admin

/jobs

Рассмотренные выше директивы, предназначенные для включения в файл

/etc/cups/cupsd.conf

cups-lpd

Программа

cups-lpd

inetd

xinetd

cups-lpd

/usr/lib/cups/daemon

/etc/inetd.conf

printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd \

 cups-lpd

Учитывая различия между

inetd

xinetd

cups-lpd

xinetd

Внимание

В CUPS не предусмотрены никакие средства для контроля доступа клиентов, использующих протокол LPD. При передаче заданий от таких клиентов используется адрес сервера, и директивы в файле

/etc/cups/cupsd.conf

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

Для добавления принтеров к системе CUPS используется утилита lpadmin, вызываемая из командной строки или доступная посредством специального

графического

://localhost:631

localhost

lpadmin

# lpadmin -р Имя_Принтера -Е -v lpd: //имя_сервера/имя_очереди\

 -m ppdfile.ppd

В данном примере

Имя_Принтера

имя_сервера

имя_очереди

lpd

ipp

-v

parallel:/dev/lp0

-m

/usr/share/cups/model

http://www.linuxprinting.org/driver_list.cgi

Совет

Если вы сконфигурировали клиент и сервер для просмотра принтеров, вам нет необходимости специально указывать принтеры IPP. Клиент автоматически получит список доступных принтеров. Описанная операция нужна лишь при использовании очередей печати LPD.

Если вы хотите модифицировать существующую очередь печати, для этого также можно применить инструмент

lpadmin

-v

Если вы предпочитаете инструменты с графическим пользовательским интерфейсом, можете воспользоваться средствами Web. В стандартном пакете CUPS предусмотрена возможность выполнения операций администрирования по протоколу HTTP. Соответствующая Web-страница показана на рис. 9.1. Для того чтобы приступить к администрированию, надо ввести URL компьютера, на котором установлен сервер, и указать порт 631. Затем CUPS запросит у вас имя и пароль администратора. После этого вы сможете выбрать конкретный пункт, например Do Administration Tasks или Manage Printers. Результат выбора Manage Printers показан на рис. 9.1. На этой странице отображается информация о двух принтерах. Первый из них,

hp4000

lexmark

Рис. 9.1. Web-интерфейс CUPS упрощает настройку как локальных, так и сетевых принтеров

Традиционно в Linux использовалась система печати BSD LPD, но в последние годы она перестала соответствовать требованиям, предъявляемым к подобным системам. Существуют альтернативные системы, которые в последние годы все чаще включаются в состав дистрибутивных пакетов Linux. К таким системам относятся LPRng и CUPS. В них улучшены средства защиты, а в системе CUPS реализованы инструменты администрирования, предоставляющие Web-интерфейс.

Настраивая компьютер для выполнения функций сервера печати, обязательно надо учитывать требования безопасности. Лучше всего использовать средства фильтрации пакетов, сконфигурировав их так, чтобы обращаться к портам 515 и 631 могли только те компьютеры, для которых разрешено взаимодействие с сервером печати (порты 515 и 631 используются соответственно при работе с помощью протоколов LPD и IPP). Кроме того, в качестве дополнительных мер защиты следует применять средства, реализованные в конкретных системах печати. LPRng предоставляет возможность управлять взаимодействием посредством протокола LPD, a CUPS обеспечивает контроль при использовании средств IPP.

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

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

Работа программы, реализующей временной сервер, может показаться несколько необычной. Дело в том, что эта программа выполняет функции как сервера, так и клиента. В частности, она не только предоставляет сведения клиентам, но и корректирует показания часов того компьютера, на котором она выполняется. Если в вашей сети есть несколько машин, работающих под управлением UNIX или Linux, вы можете настроить одну из них так, чтобы она получала сведения о точном времени от внешнего сервера, а остальные сконфигурировать для получения данных от первого компьютера. Такая конфигурация снижает нагрузку на внешние серверы. Существуют серверы, специально выделенные для поддержки информации о времени и предоставления ее клиентам. На некоторых из таких серверов для отсчета времени применяются атомные часы, а на других показания часов синхронизируются по радиосигналу, который передает официальная служба времени. Если вы не хотите устанавливать полнофункциональный временной сервер на клиентских компьютерах, можете использовать простую программу, которая выполняет лишь функции клиента. Чтобы показания часов оставались корректными, вам необходимо обеспечить периодический запуск этой программы.

Из протоколов, обеспечивающих работу временных серверов, наиболее популярен NTP (Network Time Protocol — сетевой протокол времени), который описан в документе RFC 1305 (

http://www.ietf.org/rfc/rfc1305.txt

http://www.eecis.udel.edu/~ntp/

На заметку

Существует упрощенный вариант NTP, который называется SNTP (Simple NTP — простой NTP). Клиенты SNTP осуществляют синхронизацию времени, взаимодействуя с серверами NTP.

Работа временных серверов начинается с получения сведений о времени от официальных источников. Эти сведения получаются путем считывания показаний атомных часов, приема специальных радиосигналов и т.д. Служба GPS (Global Positioning System — глобальная система позиционирования) принимает временные сигналы со спутников, поэтому может быть использована в качестве официального источника данных о времени. (Информацию об устройствах отсчета времени можно получить, обратившись по адресу

http://www.eecis.udel.edu/~ntp/hardware.html

Атомные часы, устройства приема радиосигналов и прочее оборудование принято называть эталонными временными серверами, или серверами уровня 0. Эти серверы не поддерживают сетевые соединения (они взаимодействуют с компьютерами через последовательные порты, и для обмена данными с ними требуются дополнительные устройства). Компьютеры, которые синхронизируют свои системные часы, используя такие устройства, называются серверами уровня 1. Может показаться, что на них поддерживается наиболее точное время в Internet, однако исследования показали, что приблизительно треть из них имеют погрешность в секунду и больше. Компьютеры, которые используют для синхронизации серверы уровня называются серверами уровня 2 и т.д.

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

Полнофункциональный сервер NTP работает постоянно и время от времени опрашивает вышестоящий сервер (первоначально обращения осуществляются каждые 64 секунды, но при некоторых вариантах конфигурации системы интервал между обращениями может увеличиться до 1024 секунд). Сервер NTP корректирует показания часов компьютера, на котором он выполняется, различными способами. Большие расхождения во времени (порядка секунды или больше) сначала игнорируются — сервер считает, что они могут быть вызваны ошибками при обмене данными. Но если такая ситуация сохраняется в течение некоторого времени, NTP компенсирует ошибку; он либо непосредственно устанавливает требуемое значение времени, либо ускоряет или замедляет ход системных часов до тех пор, пока системное время и время внешнего сервера не сравняются. (Процедура ускорения и замедления хода называется подстройкой системных часов.) Сервер NTP также поддерживает специальный файл (обычно это

/etc/ntp/drift

/var/state/ntp.drift

Совет

Если ошибка превышает 1000 секунд, сервер NTP прекращает свою работу, так как предполагает, что подобная ситуация требует непосредственного вмешательства системного администратора. Поэтому перед запуском сервера NTP необходимо установить хотя бы приблизительное значение системного времени. Для установки системных часов перед запуском сервера NTP можно также использовать программу

ntpdate

, работа которой будет рассмотрена далее в этой главе. В некоторых случаях вызов

ntpdate

предусматривают в сценарии запуска сервера NTP.

В обычных условиях сервер NTP, работающий в небольшой сети, использует для синхронизации данные, предоставляемые тремя внешними серверами. (Число три выбрано произвольно, при желании вы можете увеличить или уменьшить количество внешних серверов, с которым будет взаимодействовать сервер NTP в вашей сети. Использование трех серверов обеспечивает избыточность данных, требуемую для надежной работы.) Для небольшой сети роль внешних серверов, как правило, выполняют серверы уровня 2. Количество серверов уровня 1 относительно невелико, и они обычно используются для синхронизации серверов NTP, которые обслуживают сотни клиентов. Клиентские компьютеры в небольшой сети практически постоянно обращаются к серверу уровня 3 для получения сведений о текущем времени. Вместо серверов на компьютерах могут быть установлены клиенты NTP, в этом случае опрос сервера может производиться не так часто. Если ваша сеть насчитывает несколько десятков компьютеров и для их работы необходимо обеспечивать точные показания системных часов, в ней имеет смысл установить два сервера NTP уровня 3. Это позволит избежать проблем, если сервер выйдет из строя или станет работать ненадежно. Если по каким-либо причинам необходимо, чтобы системные часы клиентских компьютеров работали особенно точно, вам следует рассмотреть возможность приобретения специального устройства и организации в вашей сети сервера уровня 1. Необходимое для этого устройство может стоить несколько сотен долларов.

В системе NTP используется универсальное время (Coordinated Universal Time — UTC), которое практически совпадает с гринвичским временем (Greenwich Mean Time — GMT) без учета переходов на летнее и зимнее время. UTC отличается от GMT лишь некоторыми деталями. В частности, UTC не определяется исходя из скорости вращения Земли, а отсчитывается на основании показаний высокоточных и высоконадежных атомных часов. При необходимости значение UTC можно привести в соответствие со скоростью вращения Земли, прибавляя или вычитая около секунды в день. Локальное время отличается от UTC смещением часового пояса. Кроме того, при определении локального времени также должны учитываться правила перехода на летнее и зимнее время.

Большинство операционных систем, установленных на компьютерах x86, требуют, чтобы системные часы показывали локальное время. Linux может работать с системным таймером, отсчитывающим либо локальное время, либо UTC, а также поддерживает отдельные программные часы, установленные в соответствии с UTC. Если на компьютере установлена только система Linux, желательно применять UTC, так как при этом нет необходимости переводить таймер на летнее и зимнее время. Если же на компьютере кроме Linux инсталлирована Windows (или другая операционная система, использующая локальное время), вам придется установить таймер по локальному времени. Кроме того, при этом возникает проблема при переходе на летнее и зимнее время. Устранить ее можно, запуская средства поддержки временного протокола при загрузке системы. Заметьте, что преимущества применения NTP в Linux не распространяются на другие системы, так как при коррекции системных часов Linux не изменяет значение аппаратного таймера. Для приведения аппаратного таймера в соответствие с системными часами можно использовать команду

hwclock --systohc --localtime

--localtime

--utc.

Сервер NTP для работы в Linux реализуется с помощью программы

ntp

xntp

xntp3

xntpd

Большинство пакетов NTP содержат сервер NTP и несколько вспомогательных программ. Компоненты пакета описаны ниже.

• 

ntpd

xntpd

• 

ntpdate

ntpd

ntpdate

ntpdate

• 

ntptrace

• 

ntpq

• 

xntpdc

ntpq

Помимо NTP, в Linux для согласования времени могут быть использованы и другие программы. Одной из таких программ является

rdate

ntpdate

rdate

ntpdate

ntpdate

rdate

Для настройки средств NTP используется файл

ntp.conf

/etc

#

• 

server адрес [key ключ] [version номер] [prefer]

ntp.conf

server

key

prefer

• 

fudge адрес stratum номер

• 

driftfile имя_файла

• 

broadcast адрес [key ключ] [version номер] [ttl номер]

• 

broadcastclient [yes|no]

В файле

ntp.conf

/usr/share/doc/xntp-версия

Файл

ntp.conf

http://www.eecis.udel.edu/~mills/ntp/servers.htm

Совет

Для того чтобы сравнить время передачи данных при обмене с различными серверами NTP, можно воспользоваться утилитой

ping

. Для синхронизации желательно использовать тот сервер, от которого ответы на ping-пакеты приходят быстрее.

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

Если вы приобретете GPS либо другое устройство, позволяющее принимать эталонные данные времени, вы можете установить в своей сети сервер уровня 1. Для работы с таким оборудованием вам понадобятся специальные драйверы. Эти драйверы устанавливают принадлежность устройства сети 127.127.0.0/16, в результате для работы с ним можно использовать обычную опцию

server

http://www.eecis.udel.edu/~ntp/hardware.html

После редактирования

ntp.conf

ntpdate

ntpd

ntpd

ntpd

Помимо визуального контроля показаний часов с помощью программы

xclock

ntpq

ntpq

• 

host имя_узла

ntpq

host

ntpq

ntpq remote.threeroomco.com

• 

hostnames [yes | no]

yes

ntpq

no

-n

ntpq

• 

ntpversion номер_версии.

• 

quit

ntpq

• 

peers

host

ntp.conf

*

ntpq

peers

lpeers

opeers

• 

associations

lassociations

passociations

lpassociations

• 

readvar идентификатор_соответствия имя_переменной

readvar

rv

mreadvar

• 

readlist идентификатор_соответствия

readvar

readlist

rl

mreadlist

• 

pstatus идентификатор_соответствия

pstatus

readlist

• 

writevar идентификатор_соответствия имя_переменной

Программа

ntpq

ntpq

ntpq

ntpd

+

*

Рис. 10.1. Программа

ntpq

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

ntpq

ntpd

ping

Обеспечение точного отсчета времени

В большинстве компьютеров работа внутреннего таймера основана на использовании генератора — электронного устройства, вырабатывающего периодический сигнал. Например, сигнал с частотой 100 Гц изменяет свое состояние 100 раз в секунду. Считая изменения сигнала, вырабатываемого генератором, компьютер отсчитывает время. Как было сказано ранее в этой главе, компьютерные таймеры чаще всего работают неточно. Это происходит по разным причинам. Во-первых, частота сигнала, вырабатываемого генератором, может отличаться от ожидаемой. Если, например, вместо 100 Гц частота сигнала составляет 100,1 Гц, то системные часы будут спешить более чем на минуту в день. Во-вторых, частота сигнала может изменяться в зависимости от внешних факторов, например от температуры. В этом случае погрешность системных часов будет зависеть от температуры в комнате, от того, сколько времени компьютер проработал после включения и т.д.

Погрешность в работе системных часов может также быть вызвана причинами, не связанными с работой генератора. Как правило, при поступлении очередного сигнала (этот сигнал носит название "тик") генерируется прерывание (на компьютерах x86 прерывание с номером 0). Если в это время процессор компьютера занят обработкой более приоритетных событий, некоторые из прерываний таймера могут остаться необработанными, т.е. некоторые "тики" могут быть пропущены.

Описанные причины приводят к возникновению "дрейфа" системных часов, что затрудняет работу пользователей и приводит к сбоям в выполнении некоторых важных программ. В ряде случаев, например при управлении научными экспериментами, отсчет времени должен производиться с высокой точностью. (Обычные версии Linux плохо справляются с такими задачами. Для управления научными экспериментами обычно используется разновидность данной системы, которая называется Real-time Linux; дополнительную информацию о ней можно получить по адресу

http://fsmlabs.com/community/

.) Если вам необходимо организовать работу высокоточных часов, установите опцию ядра Enhanced Real Time Clock в меню Character Devices.

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

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

ntpd

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

ntpd

ntpd

ntpd

ntpd

ntpdate

rdate

ntpdate

На заметку

В настоящий момент разработчики NTP занимаются модернизацией программы

ntpd

. Они реализуют в ней возможность однократной коррекции времени так, как это происходит при использовании

ntpdate

. В последующих версиях NTP программа

ntpdate

не будет поставляться. Уже сейчас некоторые пакеты NTP 4 распространяются без

ntpdate

.

Для того чтобы запустить программу

ntpdate

• 

-B

ntpdate

• 

-b

• 

-о версия

• 

-р число_показаний_времени

ntpdate

С помощью данной опции вы можете увеличить или уменьшить это значение (но оно должно оставаться в диапазоне от 1 до 8).

• 

-q

-q

• 

-s

cron

• 

-u

ntpdate

После запуска программа

ntpdate

-q

ntpdate

Для периодического запуска программы

ntpdate

cron

ntpdate

ntpdate

ntpd

Внимание

Если вы используете для синхронизации времени общедоступный сервер, не планируйте вызов

ntpdate

на полуночь. Почему-то многие администраторы считают, что полночь — наилучшее время для коррекции системных часов, в результате в это время на сервер обрушивается лавина запросов. Указывайте для вызова

ntpdate

любое другое подходящее время, например 1:23 или 3:48. Это обеспечит более равномерную нагрузку на сервер, а ваша служба времени будет работать более точно и надежно, так как при обращении к серверу не возникнут непредвиденные задержки.

Как вы уже имели возможность убедиться, NTP — чрезвычайно полезный протокол, позволяющий поддерживать с высокой точностью показания системных часов на компьютерах под управлением Linux. Кроме NTP, существуют и другие протоколы подобного назначения. Один из них реализован в составе протоколов SMB/CIFS, используемых для разделения файлов и принтеров. (Эти протоколы и реализующий их продукт Samba рассматривались в главе 7.) Если вы планируете запустить сервер NTP на компьютере, на котором установлен сервер Samba, примите во внимание тот факт, что гораздо проще сконфигурировать Samba для предоставления данных о времени, чем инсталлировать клиенты NTP на каждом из Windows-компьютеров. (Samba не позволяет устанавливать системное время, обращаясь к серверу SMB/CIFS, работающему под управлением Windows.)

Как вы уже знаете, конфигурационный файл

smb.conf

[global]

smb.conf

time server = Yes

Данное значение опции указывает на то, что сервер Samba должен отвечать на запросы клиентов SMB/CIFS и предоставлять им сведения о текущем времени. Вы можете задавать данное значение опции независимо от того, используется ли на вашем компьютере

ntpdate

rdate

На заметку

Протокол SMB/CIFS не обеспечивает такой точности установки времени, как NTP. Сразу после выполнения процедуры синхронизации времени разница в показаниях системных часов различных Windows-клиентов может составлять около секунды.

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

С:\> NET TIME\\SERVER /SET /YES

В данном случае

SERVER

.ВАТ

SETTIME.ВАТ

AUTOEXEC.BAT

На заметку

Windows 2000 и XP обеспечивают непосредственную поддержку NTP. Команда

NET TIME /SETSNTP:NTP_сервер

позволяет выполнять синхронизацию времени с использованием сервера

NTP_сервер

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

Временной сервер дает возможность синхронизировать показания системных часов компьютеров вашей сети друг с другом, а также с внешним сервером, который, в свою очередь, получает сведения от эталонного источника времени. Использование временного сервера позволяет устранить проблемы, возникающие из-за неодинаковой настройки системных часов разных узлов сети. Одним из самых популярных протоколов, предназначенных для обеспечения работы временных серверов, является NTP. Сервер, поддерживающий NTP (обычно он реализуется с помощью программы

ntpd

xntpd

ntpd

ntpdate

Для получения данных о времени и коррекции системных часов предназначены также клиент-программа

rdate

NET

NET

Электронная почта — одна из наиболее популярных служб Internet. Большинство пользователей глобальной сети ежедневно прибегают к ее услугам. С ее помощью можно одинаково просто послать сообщение сотруднику, работающему за соседним столом, и адресату, находящемуся на другом континенте. В системе Linux реализована поддержка различных почтовых протоколов. В данной главе рассматривается один из классов почтовых протоколов, а именно протоколы получения почты. При использовании этих протоколов доставка писем осуществляется по инициативе получателя. Кроме протоколов получения существуют также протоколы передачи почты, которые осуществляют передачу писем по инициативе отправителя. (Наиболее популярный на сегодняшний день протокол передачи почты SMTP будет рассмотрен в главе 19.) Протокол передачи почты является непременным участником процесса доставки писем. Протоколы получения используются, как правило, на последней стадии, в редких случаях — на промежуточных этапах доставки сообщений.

На заметку

Несмотря на то что протокол передачи почты будет рассматриваться лишь в главе 19, необходимо заметить, что, для того, чтобы вы могли пользоваться протоколом получения почты, в вашем распоряжении должен быть действующий сервер, реализующий протокол передачи. Готовый к работе сервер SMTP поставляется практически со всеми версиями Linux, поэтому в системе Linux с самого начала реализованы по крайней мере минимальные средства передачи писем. Если у вас возникнут проблемы с использованием сервера передачи или вам потребуется установить конфигурацию этого сервера, отличную от конфигурации, заданной по умолчанию, ознакомьтесь с материалом, изложенным в главе 19.

В начале данной главы будут обсуждаться протоколы получения почты и использование двух протоколов такого типа, наиболее популярных в настоящее время. Затем речь пойдет о настройке Linux для использования этих протоколов. В заключение будет рассмотрен продукт Fetchmail, который реализует протокол получения, но может также перенаправлять письма по другому адресу, используя протокол передачи.

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

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

pine

mutt

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

Первый подход широко применялся тогда, когда сервер UNIX был единственным компьютером в лаборатории или другом подразделении организации, а пользователи работали за удаленными терминалами. В настоящее время пользователи предпочитают для работы с почтой программы с графическим интерфейсом, выполняющиеся в среде Windows или MacOS. В системе Linux существуют программы просмотра почты с графическим интерфейсом, но для работы с ними с удаленных компьютеров необходимо использовать серверы X Window. Такие серверы крайне редко применяются в системах Windows и MacOS. Таким образом, для пользователей, работающих на компьютерах под управлением Windows или MacOS, второй подход предпочтительнее первого. Для его реализации на пользовательском компьютере должна быть установлена программа просмотра почты. В ней необходимо указать имя или IP-адрес узла, на котором инсталлирован сервер получения почты. При наличии такой программы, чтобы инициировать доставку почты на свой компьютер, пользователю достаточно щелкнуть мышью на кнопке в окне. Более того, доставка почты может осуществляться и без участия пользователя, так как многие средства просмотра автоматически проверяют наличие почты.

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

В предыдущем разделе были описаны лишь общие принципы доставки почты. Для того чтобы понять работу протокола получения почты, надо более подробно рассмотреть функционирование почтовой системы и вопросы взаимодействия протокола получения с другими компонентами доставки почты. В данной главе обсуждаются два основных протокола получения: POP (Post Office Protocol — протокол почтового отделения) и IMAP (Internet Message Access Protocol — протокол доступа к сообщениям Internet). Приведенные ниже рассуждения в равной степени относятся к обоим протоколам, несмотря на то, что они существенно различаются между собой. На практике достаточно использовать один протокол получения. Представляя себе круг задач, на которые ориентирован каждый протокол, вы сможете обоснованно выбрать для себя наиболее подходящий из них.

Как было сказано ранее, при организации почтового сервера необходимо установить сервер передачи почты. Без него использование сервера получения не будет иметь смысла, так как письма, предназначенные для доставки пользователям, попросту не будут поступать на почтовый сервер. В большинстве случаев письмо, подготовленное на компьютере пользователя, попадает на сервер передачи почты (не исключено, что на пути к получателю оно побывает на нескольких серверах передачи) и в конечном итоге попадает на сервер получения. В ответ на очередное обращение клиента сервер получения передает ему письмо.

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

sammy@threeroomco.com

mail.threeroomco.com

gingko.threeroomco.com

larch.threeroomco.com

trilobite.pangaea.edu

franklin.pangaea.edu

osgood.pangaea.edu

trilobite.pangaea.edu

gingko.threeroomco.com

gingko.threeroomco.com

larch.threeroomco.com

Рис. 11.1. В процессе доставки электронных писем может участвовать несколько серверов передачи, выполняющих роль ретрансляторов. Как правило, доставку сообщения на клиентскую машину осуществляет сервер получения

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

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

franklin.pangaea.edu

ponyexpress.pangaea.edu

ponyexpress.pangaea.edu

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

• При получении почты с двух различных компьютеров. В этом случае многие предпочитают оставлять копии сообщений на сервере, независимо от того, применяют ли они протокол POP или IMAP. Следует заметить, что при использовании протокола POP накопившиеся на сервере сообщения вскоре начинают мешать работе, так как POP предоставляет очень несовершенные средства для идентификации отдельных сообщений и их обработки.

• При использовании протокола IMAP. В этом случае есть возможность организовывать "папки" сообщений на сервере. Поэтому, если вы работаете на различных компьютерах, вы можете разместить сообщения на сервере удобным вам способом и не испытывать ненужных трудностей, возникающих вследствие дублирования сообщений. IMAP также предоставляет возможность копировать на пользовательский компьютер только заголовки сообщений (содержащие, в частности, адрес отправителя и тему письма), поэтому для просмотра корреспонденции с помощью данного протокола не требуется высокая пропускная способность линии связи.

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

На самом деле POP — это несколько взаимодействующих между собой протоколов. На сегодняшний день наиболее популярна версия POP-3, которая использует TCP-порт 110. (Более ранняя версия POP-2 использовала порт 109.) Подобно многим другим протоколам, применяемым в Internet, POP-взаимодействие основано на обмене текстовыми сообщениями между клиентом и сервером. В POP-3 предусмотрено более десяти команд. Среди них можно отметить команды

USER

PASS

RETR

DELE

QUIT

telnet

Листинг 11.1. Пример сеанса взаимодействия по протоколу POP-3

$ telnet nessus 110

Trying 192.168.1.3...

Connected to nessus.rodsbooks.com.

Escape character is '^]'.

+OK POP3 nessus.rodsbooks.com v7.64 server ready

USER rodsmith

+OK User name accepted, password please

PASS password

+OK Mailbox open, 1 messages

RETR 1

+OK 531 octets

>From rodsmith Wed Aug 8 14:38:46 2001

Return-Path: <ben@pangaea.edu>

Delivered-To: rodsmith@nessus.rodsbooks.com

Received: from speaker.rodsbooks.com (speaker.rodsbooks.com

[192.168.1.1])

 by nessus.rodsbooks.com (Postfix) with SMTP id EB2A01A2BD

 for <rodsmith@nessus.rodsbooks.com>; Wed, 8 Aug 2001 14:38:26 -0400 (EDT)

Message-Id: <20010808183826.EB2A01A2BD@nessus.rodsbooks.com>

Date: Wed, 8 Aug 2001 14:38:26 -0400 (EDT)

From: ben@pangaea.edu

To: undisclosed-recipients:;

Status:

This is a test message.

.

DELE 1

+OK Message deleted

QUIT

+OK Sayonara

Connection closed by foreign host.

Как видно из листинга 11.1, при использовании протокола POP сообщения идентифицируются по номерам. В данном примере на сервере присутствует лишь одно сообщение; на это указывает строка

+OK mailbox open, 1 messages

RETR 1

DELE 1

На заметку

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

From:

и

Return-Path:

указано, что отправителем письма является пользователь

ben@pangaea.edu

. Тем не менее эти поля заголовка нетрудно подделать. Кроме того, в заголовке каждого письма присутствует поле

Received:

, в котором указан сервер, использованный при получении письма, и адрес, с которого письмо попало на этот сервер. Я отправил это сообщение с одного компьютера, подключенного к моей сети, на другой компьютер; этот факт отражен в поле

Received:

. Как видно из листинга, письмо отправлено с

speaker.rodsbooks.com

и доставлено на

nessus.rodsbooks.com

. Компьютер

pangaea.edu

в передаче письма не участвовал.

Как и POP, IMAP представляет собой протокол получения почты, однако IMAP позволяет использовать расширенные средства управления сообщениями. Применяя IMAP, пользователь, перед тем как копировать письма на свой компьютер, может ознакомиться с их заголовками. Наличие дополнительных возможностей предполагает реализацию дополнительных команд; таковых в IMAP-4 предусмотрено больше двадцати. (IMAP-4 является текущей версией данного протокола и использует при работе порт 143.) Пример сеанса взаимодействия по протоколу IMAP приведен в листинге 11.2. В ходе этого сеанса достигается такой же результат, как и при использовании протокола POP (листинг 11.1). Отличие лишь в том, что листинг 11.2 включает команду копирования сообщения в папку IMAP.

Листинг 11.2. Пример сеанса IMAP-4

$ telnet nessus 143

Trying 192.168.1.3...

Connected to nessus.rodsbooks.com.

Escape character is '^]' .

* OK nessus.rodsbooks.com IMAP4rev1 v12.264.phall server ready

A1 LOGIN rodsmith password

A1 OK LOGIN completed

A2 SELECT Inbox

* 1 EXISTS

* NO Trying to get mailbox lock from process 29559

* 1 RECENT

* OK [UIDVALIDITY 997295985] UID validity status

* OK [UIDNEXT 4] Predicted next UID

* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)

* OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)]

Permanent flags

* OK [UNSEEN first unseen message in /var/spool/mail/rodsmith

A2 OK [READ-WRITE] SELECT completed

A3 FETCH 1 BODY [HEADER]

* 1 FETCH (BODY[HEADER] {494}

>From rodsmith Wed Aug 8 16:02:47 2001

Return-Path:

Delivered-To: rodsmith@nessus.rodsbooks.com

Received: from speaker.rodsbooks.com (speaker.rodsbooks.com [192.168.1.1])

 by nessus.rodsbooks.com (Postfix) with SMTP id 2C7121A2BD

 for <rodsmith@nessus.rodsbooks.com>; Wed, 8 Aug 2001 16:02:25 -0400 (EDT)

Message-Id: <20010808200225.2C7121A2BD@nessus.rodsbooks.com>

Date: Wed, 8 Aug 2001 16:02:25 -0400 (EDT)

From: ben@pangea.edu

To : undisclosed-recipients: ;

)

* 1 FETCH (FLAGS (\Recent \Seen))

A3 OK FETCH completed

A4 FETCH 1 BODY [TEXT]

* 1 FETCH (BODY[TEXT] {25}

This is a test message.

)

A4 OK FETCH completed

A5 COPY 1 demos

A5 OK COPY completed

A6 LOGOUT

* BYE nessus.rodsbooks.com IMAP4rev1 server terminating connection

A6 OK LOGOUT completed

Connection closed by foreign host.

Листинг 11.2 демонстрирует дополнительные возможности IMAP, которые отсутствуют в протоколе POP. IMAP требует от клиента передавать ему нумерованные команды, например, вместо

LOGOUT

A6 LOGOUT

A3

A4

A2

A5

FETCH

http://www.ietf.org/rfc/rfc2060.txt

Несмотря на то что рассмотрение низкоуровневых команд позволяет получить представление о работе IMAP, вам, как системному администратору, вряд ли необходимо знать детали функционирования этого протокола. Однако наличие некоторых команд оказывает влияние на конфигурацию сервера. Поскольку IMAP позволяет работать с папками, эти папки надо где-то хранить. Расположение папок зависит от используемого сервера. В настоящее время наиболее популярен сервер IMAP, разработанный в Вашингтонском университете (UW IMAP;

http://www.washington.edu/imap/

INBOX

/var/spool/mail/имя_пользователя

INBOX

Выбор протокола получения почты зависит от имеющихся в наличии ресурсов и от того, какие клиентские программы применяют пользователи. Не секрет, что на решение вопроса большое влияние оказывают вкусы и привычки самого системного администратора. При использовании протокола POP требования к ресурсам сервера и пропускной способности линии минимальны, поскольку подавляющее большинство пользователей не хранят письма на сервере, а копируют их на клиентские машины. Некоторые пользователи предпочитают работать с сервером IMAP. Чтобы организовать функционирование такого сервера, необходимы дополнительные ресурсы, в частности, для хранения писем на сервере потребуется жесткий диск большего объема. В составе почтовых систем серверы POP используются чаще, чем IMAP, поэтому, если вы установите сервер IMAP, желательно установить на том же компьютере и сервер POP. При этом дополнительная нагрузка на компьютер практически не будет ощущаться, но пользователи, которые работают с клиентскими программами, не поддерживающими IMAP, смогут получать свои письма. POP-клиент может очистить папку

INBOX

Внимание

По умолчанию серверы POP и IMAP передают всю информацию, включая пароль, в незашифрованном виде. Поэтому пароли, используемые для получения почты, не следует применять в других целях, а в особенности для регистрации в системе. Существуют также защищенные варианты серверов POP и IMAP, в которых для передачи данных используется SSL-соединение. Несмотря на то что такие серверы сложнее настроить, это необходимо сделать, если в письмах могут содержаться секретные данные. Принять меры защиты особенно важно, когда обращение к серверам POP и IMAP может осуществляться через Internet. Если вы хотите ограничить доступ к серверам получения почты только компьютерами локальной сети, вы можете применить TCP Wrappers либо задать соответствующие правила

xinetd

. Кроме того, запретить обращение к серверам извне можно, настроив соответствующим образом брандмауэр.

Как правило, для обеспечения работы сервера POP не приходится затрачивать больших усилий. Чаще всего, настройка не требуется, и вам достаточно лишь запустить сервер. Тем не менее следует убедиться, что выбранная вами программа сервера совместима с сервером SMTP. He менее важно обеспечить совместимость с форматом хранения писем. В настоящее время используются два таких формата:

mbox

maildir

sendmail

mbox

qmail

maildir

qmail

mbox

maildir

Серверы POP входят в состав практически каждого дистрибутивного пакета Linux. Как правило, самым простым решением является использование сервера, поставляемого вместе с системой, но если вы перенастроите сервер SMTP для хранения писем в другом формате, вам, возможно, придется заменить сервер POP программой, в которой предусмотрена поддержка этого формата. Ниже перечислены некоторые программные продукты, обеспечивающие работу сервера POP.

• UW IMAP. Сервер IMAP, созданный в Вашингтонском университете (

http://www.washington.edu/imap/

mbox

• Cyrus IMAP. Подобно UW IMAP, Cyrus IMAP (

http://asg.web.cmu.edu/cyrus/imapd/

mbox

• 

nupop

nupop

http://nupop.sourceforge.net

maildir

qmail

• Courier. Продукт Courier (

http://ww.courier-mta.org

http://www.inter7.com/courierimap/

maildir

• QPopper. Несмотря на свое название, данный пакет (

httр://www.eudora.com/qpopper/

qmail

mbox

• 

qmail-pop3d

qmail

http://www.qmail.org

maildir

qmail

qmail-pop3d

Здесь приведена информация лишь о незначительной части продуктов, реализующих обмен по протоколу POP. На сервере

http://www.sourceforge.net

Как правило, серверы POP запускаются с помощью суперсервера (вопросы использования суперсерверов рассматривались в главе 4). При инсталляции некоторых серверов автоматически устанавливается конфигурация

xinetd

/etc/inetd.conf

inetd

xinetd

По умолчанию UW IMAP и большинство других серверов POP полагаются на результаты выполнения стандартной процедуры аутентификации Linux. Поэтому, чтобы сервер обслуживал пользователей вашей системы, не надо принимать никаких специальных мер. Если для пользователя создана учетная запись и если сервер SMTP получает его корреспонденцию, сервер POP будет доставлять письма на удаленный компьютер. Пользователю лишь необходимо указать в клиент-программе POP свое имя и пароль. Поскольку действия, выполняемые сервером POP, чрезвычайно просты, в большинстве программ специальный конфигурационный файл не используется.

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

Многие из пакетов, сведения о которых были приведены в предыдущем разделе, в частности UW IMAP, Cyrus IMAP и Courier, обеспечивают также работу сервера IMAP. В 2002 г. в стадии разработки находился ряд проектов по созданию серверов IMAP, но реально работающий код еще не был доступен. Информацию об этих проектах можно найти на сервере

http://www.sourceforge.net

Наиболее популярный сервер для Linux, UW IMAP, использует для организации большинства почтовых папок рабочие каталоги пользователей. Если пользователь время от времени регистрируется и работает на этом компьютере, такое решение нежелательно, так как пользователь может непреднамеренно удалить или переместить каталоги с папками. (Местоположение папок можно изменить; для этого надо модифицировать исходный код программы и перекомпилировать ее. Соответствующие действия описаны в файле

CONFIG

mbox

В состав большинства версий Linux входит продукт UW IMAP, соответствующий пакет обычно носит имя

imap

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

.fetchmailrc

fetchmailconf

На заметку

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

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

• Компьютер под управлением Linux, подключенный к Internet по коммутируемой линии. В большинстве случаев на компьютере Linux, даже если он подключен к Internet через PPP-соединение, присутствует почтовый сервер. Этот локальный сервер позволяет организовать обмен письмами между несколькими локальными пользователями или передавать пользователям сообщения, сгенерированные системой. Для того чтобы интегрировать эти сообщения с письмами, которые приходят на сервер провайдера, надо извлечь письма с помощью протокола POP или IMAP и включить их в очередь локального почтового сервера. В результате пользователь получает возможность читать все сообщения (как локальные, так и удаленные) с помощью одной программы; при этом он избавлен от необходимости обращаться к серверу посредством протокола POP или IMAP.

• Локальная сеть, подключенная к Internet по коммутируемой линии. В небольших компаниях компьютеры часто объединяют в локальную сеть, которая, помимо выполнения других задач, позволяет организовать обмен почтовыми сообщениями между пользователями. Подобная сеть может быть подключена к Internet по коммутируемой линии; при этом письма, адресованные пользователям локальной сети, доставляются на сервер провайдера. Администратору локальной сети приходится решать задачу получения писем и перенаправления их на пользовательские компьютеры в пределах локальной сети.

• Получение почты, приходящей по нескольким адресам. Если у вас есть несколько учетных записей, на которые приходят письма, вы можете автоматизировать процесс получения корреспонденции. Работая на компьютере под управлением Linux, подключенном к Internet по коммутируемой линии, вы можете использовать протокол получения почты для того, чтобы собрать письма из нескольких источников и перенаправить их на одну учетную запись. (Эта учетная запись может располагаться как на локальном, так и на удаленном компьютере.) Альтернативным решением данной проблемы является организация перенаправления почты на тех серверах, на которые она поступает, либо использование почтовой программы, опрашивающей различные учетные записи.

• Использование одного почтового ящика несколькими абонентами. Бывают случаи, когда на одну учетную запись приходят письма, адресованные нескольким пользователям. Если существуют правила, позволяющие рассортировать письма, вы можете сделать это, используя средства фильтрации Fetchmail (либо реализовать фильтрацию посредством отдельной программы) и разместить сообщения в отдельных очередях.

• Преобразование POP в IMAP. Предположим, что почта, адресованная пользователям вашей сети, приходит на внешний сервер, на котором установлен сервер POP, но пользователи предпочитают работать посредством протокола IMAP. С помощью компьютера под управлением Linux вы можете получать почту с сервера POP и помещать ее в локальную очередь. Установив IMAP на локальном компьютере, вы обеспечите для пользователей возможность работать с корреспонденцией, применяя средства, обеспечиваемые протоколом IMAP.

Планирование получения почты

Если адресованные вам письма приходят на PPP- или IMAP-сервер, вы должны принимать специальные меры для их получения. Вы не можете ожидать, пока программа оповестит вас о приходе очередного письма, как это происходит при работе на том компьютере, на котором присутствует сервер передачи почты. Чтобы письма оказались на вашей машине, вам надо специально вызвать клиентскую программу (вручную или с помощью инструмента, обеспечивающего периодическое выполнение некоторых действий, например

cron

). Если вы планируете периодические вызовы программы Fetchmail с помощью инструмента

cron

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

cron

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

Если ваш компьютер подключается к Internet по коммутируемой линии, вам нет смысла постоянно вызывать Fetchmail. Лучше предусмотреть вызов этой программы в сценарии запуска сетевых средств. Например, вы можете включить вызов Fetchmail в сценарий

ppp-on-dialer

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

interface

и

monitor

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

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

Настраивая программу Fetchmail, важно обеспечить ее работу в качестве клиента как сервера получения, так и сервера передачи. (Fetchmail может не использовать сервер передачи, но такая конфигурация применяется крайне редко). Поскольку в составе Fetchmail объединены два клиента, эта программа требует, чтобы оба сервера были доступны. Fetchmail может работать как в пакетном режиме, так и в режиме демона. В пакетном режиме данная программа опрашивает один или несколько серверов получения и перенаправляет полученные письма с помощью сервера передачи. В режиме демона Fetchmail работает постоянно, опрашивая сервер получения через заданные интервалы. Этот режим нежелателен, поскольку, как показывает опыт, при длительной работе в режиме демона в работе Fetchmail происходят сбои. Поэтому предпочтительнее запускать этот инструмент в пакетном режиме. Исключение составляют случаи, когда работа в режиме демона продолжается недолго. Если вы хотите организовать периодический опрос сервера, можно планировать вызовы Fetchmail с помощью

cron

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

fetchmailconf

.fetchmailrc

fetchmailconf

В состав большинства версий Linux программа

fetchmailconf

fetchmailconf

1. Зарегистрировавшись как обычный пользователь, введите в окне

xterm

fetchmailconf

На заметку

Конфигурировать и запускать Fetchmail может также пользователь root, но ему не предоставляются никакие преимущества по сравнению с другими пользователями. Поэтому, для того, чтобы уменьшить риск, который неизбежен при регистрации под именем root, лучше зарегистрироваться для работы с Fetchmail как обычный пользователь. (Если в защите Fetchmail обнаружатся недостатки, то, работая с данной программой как root, вы создаете угрозу для безопасности всей системы в целом.) Зная необходимые пароли, любой пользователь может получать почту, предназначенную для других пользователей. В некоторых ситуациях подобная конфигурация может быть оправданной, но в большинстве случаев желательно настраивать Fetchmail так, чтобы пользователь имел доступ только к своим письмам.

2. Щелкните на кнопке Configure Fetchmail в окне Fetchmail Launcher. На экране отобразится окно Fetchmail Configurator, в котором вы сможете указать, предпочитаете ли вы использовать средства, ориентированные на начинающего или на опытного администратора. Конфигурация, предназначенная для начинающего, позволяет использовать лишь подмножество тех опций, которые представляются опытному администратору. При изложении материала данного раздела я в основном буду ориентироваться на расширенный набор опций, поступающих в распоряжение более квалифицированного администратора.

3. Щелкните на кнопке Expert Configuration в окне Fetchmail Configurator. Программа выведет диалоговое окно Fetchmail Expert Configurator, показанное на рис. 11.2. Если вы собираетесь запускать Fetchmail в режиме демона, введите в поле Poll Interval интервал между последовательными обращениями к серверу, выраженный в секундах (например, 1200 секунд соответствуют 20 минутам). Если вы хотите, чтобы программа Fetchmail выполнялась в пакетном режиме, оставьте в этом поле значение по умолчанию, равное 0. В поле Postmaster указывается имя пользователя, которому следует сообщать о проблемах, возникших в процессе работы Fetchmail. По умолчанию принимается имя пользователя, который запустил данную программу. Большинство опций, расположенных в средней части окна, можно оставить без изменений. Щелкнув на кнопке Help, вы получите информацию об их назначении.

Рис. 11.2. Диалоговое окно Fetchmail Expert Configurator позволяет задавать глобальные опции и указывать почтовый сервер, к которому программа Fetchmail должна обращаться для получения почты

4. Наиболее важный компонент окна Fetchmail Expert Configurator — панель, расположенная в нижней его части. С помощью этой панели вы можете задать имя почтового сервера, с которого собираетесь получать почту. Введите имя узла, и после нажатия клавиши <Enter> отобразится новое диалоговое окно Fetchmail Host Имя_узла (рис. 11.3). Заданное вами имя должно также появиться в списке, расположенном в окне Fetchmail Expert Configurator ниже поля New Server. Если вы собираетесь получать почту с нескольких серверов, вам надо ввести их имена, но задать имя следующего сервера можно лишь после установки всех конфигурационных параметров для предыдущего сервера.

Рис. 11.3. Информация о сервере получения почты задается в диалоговом окне Fetchmail Host Имя_узла

5. Наиболее важными в окне Fetchmail Host Имя_узла являются разделы Protocol, User Entries for Имя_узла и Security. В разделе Run Controls задаются опции, определяющие временные соотношения при получении почты, и имя сервера (если оно отличается от введенного ранее). В области Multidrop Options указываются правила, используемые при дублировании или перенаправлении сообщения. Конкретное решение принимается на основании анализа указанных в этом разделе полей заголовка. Данный раздел используется в том случае, если надо обеспечить распределение писем, приходящих на одну учетную запись, однако в некоторых случаях, например при участии в списке рассылки, такое распределение может привести к возникновению проблем.

6. В разделе Protocol окна Fetchmail Host Имя_узла надо указать протокол получения почты. По умолчанию предполагается значение Auto; такая установка обеспечивает работу с некоторыми серверами, но если вы знаете, какой протокол поддерживается на сервере, желательно указать его явно. Для проверки протокола можно воспользоваться кнопкой Probe for Supported Protocols, но средства, активизируемые с ее помощью, не всегда работают корректно. Лучше запросить необходимую информацию у провайдера или провести сеанс вручную, используя клиентскую программу

telnet

telnet

7. Средства, доступные посредством раздела Security, особенно важны в тех случаях, когда взаимодействие с сервером получения производится по коммутируемой линии, причем эта линия не всегда активна. В поле Interface to Monitor введите имя интерфейса, например

ppp0

/

ppp0

ppp0

8. В разделе User Entries for Имя_узла есть поле New User. Введите в нем имя, под которым вы зарегистрированы на почтовом сервере. После нажатия клавиши <Enter> отобразится окно Fetchmail User Имя_пользователя Querying Имя_узла (рис. 11.4). Как и при указании имени сервера, следующую учетную запись вы можете указать только после завершения работы с этим окном.

Рис. 11.4. Многие опции Fetchmail определяют работу с конкретными учетными записями на почтовом сервере

9. Наиболее важным элементом в окне Fetchmail User Имя_пользователя Querying Имя_узла является поле Password в разделе Authentication. Информация, задаваемая в этом поле, необходима для получения почты с сервера. Следует убедиться, что в поле Local Names перечислены все локальные пользователи, которые должны получать письма посредством данной учетной записи. По умолчанию предполагается, что локальное имя совпадает с именем на сервере; при необходимости вы можете задать другое имя. Раздел Forwarding Options позволяет указать узел для передачи почты. По умолчанию в качестве такого узла используется локальная система, но с помощью Fetchmail можно также организовать получение писем с одного узла и передачу их на другой узел. Опции в разделах Forwarding Options, Processing Options и Resource Limits используются редко, и назначение большинства опций понятно из их названий. При первом запуске Fetchmail целесообразно установить флажок опции Suppress Deletion of Messages After Reading в разделе Processing Options, чтобы исключить риск потери писем вследствие некорректной работы Fetchmail. После того как вы убедитесь, что программа работает корректно, опцию можно отключить. В разделе Remote Folders указываются папки IMAP, которые программа Fetchmail проверяет, помимо папки

INBOX

Внимание

Пароли, используемые для получения почты, Fetchmail хранит в незакодированном виде в конфигурационном файле

.fetchmailrc

. Программа Fetchmail не будет запускаться, если права доступа заданы менее строго, чем 0600 (

rw-------

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

10. Щелкните на кнопке OK в окне Fetchmail User Имя_пользователя Querying Имя_узла, а затем на такой же кнопке в окне Fetchmail Host Имя_узла. Для того чтобы установки сохранились в файле

.fetchmailrc

11. Для того чтобы проверить конфигурацию программы, щелкните на кнопке Test Fetchmail в окне Fetchmail Launcher. В результате программа Fetchmail будет запущена в режиме отладки, т.е. вы увидите команды, которые данная программа передает серверу получения и серверу передачи почты, а также ответы этих серверов. Эта информация позволяет выявить и устранить проблемы, возникающие при работе Fetchmail. Убедившись в работоспособности программы, завершите ее работу щелчком на кнопке Quit.

Внимание

Несмотря на то что при отладке отображается дополнительная информация, в этом режиме письма не сохраняются на почтовом сервере. Поэтому, если при работе Fetchmail возникнут проблемы, письма будут утеряны (так, например, может случиться, если локальный почтовый сервер не работает или отвергает переданные ему сообщения). Поэтому на время тестирования желательно запретить удаление писем с сервера (соответствующая опция рассматривалась выше в п. 9).

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

fetchmailconf

.fetchmailrc

Если вы работаете с

fetchmailconf

.fetchmailrc

fetchmailconf

.fetchmailrc

Листинг 11.3. Пример файла

.fetchmailrc

# Fetchmail file for retrieving mail from mail.abigisp.net

# and imap.asmallisp.com

set postmaster rodsmith

set bouncemail

set daemon 1800

set syslog

poll mail.abigisp.net with proto POP3

 user rodericksmith there with password abc123

 is rodsmith here fetchall forcecr

 smtphost speaker.rodsbooks.com

poll imap.asmallisp.com with proto IMAP

 user rodsmith there with password A1B2C3

 is rodsmith here

Как и в других конфигурационных файлах, символ

#

set

fetchmailconf

Fetchmail поддерживает большое количество опций и в этом разделе невозможно обсудить их все. Исчерпывающую информацию об опциях данной программы вы можете получить на страницах справочной системы, посвященных Fetchmail, а также в других документах. Значением некоторых опций является строка символов (например, посредством опции может задаваться пользовательское имя). Если в строке содержатся пробелы, строка помещается в кавычки. Некоторые из наиболее важных глобальных опций описаны ниже.

• 

set postmaster имя_пользователя

postmaster

root

postmaster

postmaster

--postmaster имя_пользователя

• 

set bouncemail

set bouncemail

set no bouncemail

postmaster

• 

set daemon интервал

set daemon

--daemon интервал

--daemon 0

.fetchmailrc

• 

set logfile имя_файла

• 

set syslog

В файле

.fetchmailrc

poll

poll имя_сервера опции-сервера описание_пользователя

Ключевое слово

server

poll

skip

.fetchmailrc

.fetchmailrc

and

with

has

wants

options

:

;

,

poll

Некоторые из наиболее важных опций сервера приведены ниже.

• 

proto имя

protocol имя

.fetchmailrc

-p

• 

interface интерфейс/IP-адрес/маска_подсети

eth1

ppp0

eth1/192.168.1.0/255.255.255.0

eth1

-I

• 

monitor интерфейс

-М

Ниже перечислены опции, наиболее часто применяющиеся в описании пользователя.

• 

user имя

username имя

poll

here

there

-u

• 

pass пароль

password пароль

• 

is имя

to имя

user имя with pass пароль

here

there

• 

smtphost имя_узла

localhost

-S

• 

keep

-k

keep

• 

fetchall

fetchall

-а

• 

forcecr

qmail

forcecr

Если вы зададите больше одного локального имени, Fetchmail будет анализировать заголовки писем и пытаться определить, кто является получателем конкретного сообщения. Например, если вы укажете локальные учетные записи

jack

jill

jill

jill

Совет

Доставку писем, обработанных с помощью Fetchmail, может выполнять грамма Procmail, которая будет описана в главе 19. Procmail предоставляет возможность идентифицировать и удалять нежелательные сообщения, распределять поступающие письма по папкам и выполнять другие подобные действия.

Серверы получения почты часто инсталлируют на том же компьютере, на котором располагается главный сервер SMTP. В результате пользователи могут просматривать свою почту с клиентских машин, подключенных к сети организации, и даже из Internet. Поддержка протокола получения почты избавляет пользователей от необходимости регистрироваться на сервере с помощью Telnet, SSH или других средств удаленного доступа и дает возможность запускать программы просмотра писем на своих компьютерах. Наиболее популярными протоколами получения почты в настоящее время являются POP-3 и IMAP-4. Протокол IMAP предоставляет пользователям более обширные возможности обработки почты по сравнению с POP, но он предъявляет более высокие требования к объему жесткого диска и пропускной способности линии связи. По этой причине администраторы предпочитают устанавливать на своих компьютерах серверы POP.

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

В главе 11 обсуждалась работа серверов получения почты. Эти серверы позволяют пользователям принимать сообщения, адресованные непосредственно им. В данной главе рассматриваются средства обработки сообщений другого типа — серверы новостей. Если электронная почта обеспечивает взаимодействие типа "один к одному", то служба новостей (Usenet) реализует среду для обмена сообщениями "один ко многим". Если пользователь отправит сообщение на сервер новостей, любой другой пользователь сможет прочитать его. Более того, серверы новостей взаимодействуют между собой, в результате чего сообщения распространяются по всему миру. Установив сервер новостей, вы предоставите своим пользователям удобный инструмент для взаимодействия.

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

На заметку

Следует заметить, что обычная электронная почта также может обеспечить режим взаимодействия "один ко многим". Составляя письмо, вы можете указать в нем несколько получателей. Такой режим, называемый списками рассылки, позволяет организовать дискуссионные группы, аналогичные группам Usenet. В отличие от Usenet, процедура подписки на списки рассылки практически не стандартизована.

Сервер новостей предоставляет следующие возможности.

• Поддержка групп новостей Usenet. Глобальная сеть серверов новостей носит название Usenet. Если сервер принимает участие в обмене сообщениями, он тем самым способствует распространению материалов групп по всему миру. Серверы новостей Usenet поддерживают многие провайдеры, университеты, а также коммерческие предприятия.

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

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

Независимо от того, обеспечивает ли сервер полную поддержку Usenet или организует обмен материалами внутри предприятия, для него используется одно и то же программное обеспечение. Различие состоит лишь в наличии или отсутствии обмена с другими серверами. Полнофункциональный сервер Usenet предъявляет гораздо более высокие требования к ресурсам, чем сервер, поддерживающий ограниченное число групп новостей. Только для хранения содержимого материалов Usenet нужен жесткий диск на десятки и даже сотни мегабайт. Для того чтобы сервер новостей можно было разместить на обычном компьютере, подключенном посредством линий со средней пропускной способностью, необходимо ограничить число групп новостей, поддерживаемых этим сервером.

Внимание

Как правило, серверы новостей хранят материалы групп в каталоге

/var/spool/news

. Если при установке Linux вы не планировали инсталляцию сервера новостей, то этот каталог, вероятнее всего, находится в корневом разделе либо в небольшом разделе в каталоге

/var

. На компьютере, специально предназначенном для сервера новостей, каталог

/var

или

/var/spool/news

размещается в разделе диска очень большого объема. Принимая решение об установке сервера, необходимо убедиться, что в разделе, в котором находится каталог

/var/spool/news

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

Совет

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

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

http://www.giganews.com

http://www.supernews.com

http://www.newsguy.com

http://www.newsservers.net

http://groups.google.com

Работа с материалами групп новостей в автономном режиме обычно обеспечивается клиентскими программами новостей (программами просмотра), но для этой цели также можно использовать сервер новостей с ограниченными функциональными возможностями, например, программу Leafnode, которая будет рассматриваться ниже в этой главе. С точки зрения клиента программы, подобные Leafnode, работают так же, как и обычные серверы новостей, но их конфигурация отличается от конфигурации серверов Usenet. Если ваша сеть постоянно подключена к Internet, вам, возможно, не придется устанавливать специальный сервер; проще будет использовать сервер новостей провайдера. Собственный сервер новостей полезен, если вашим пользователям необходимо работать с материалами групп, а сервер провайдера перегружен. В этом случае вы можете сконфигурировать Leafnode так, чтобы копирование материалов выполнялось в наиболее удобное время. Использование внутреннего сервера новостей оправдано также в том случае, когда большинство пользователей просматривают материалы одних и тех же групп. Копируя эти группы на внутренний сервер, вы уменьшите сетевой трафик.

Современные серверы новостей используют для обмена между собой и для взаимодействия с клиентами протокол NNTP (Network News Transfer Protocol — протокол передачи сетевых новостей). Как правило, серверы NNTP используют порт 119. Следует заметить, что распространение групп новостей не всегда осуществлялось посредством протокола NNTP. Более того, на ранних этапах развития данной службы материалы передавались в сетях, отличных от TCP/IP. Несмотря на то что NNTP — не единственный протокол, применяемый для поддержки новостей, в сетях TCP/IP он используется для этой цели наиболее часто.

При работе протокола NNTP происходит обмен сообщениями, которые также называют статьями. Сообщение — это отдельный документ, автором которого является один пользователь. (Существуют средства для работы нескольких пользователей над одним документом, но на практике подобное взаимодействие осуществляется крайне редко.) Сообщения объединяются в группы. Одно сообщение может быть отправлено одновременно в несколько групп, но такое дублирование во многих случаях нежелательно. Группы новостей, в свою очередь, объединяются в категории, организуя иерархию групп. Полное имя группы состоит из нескольких компонентов, разделяемых точками. Имена групп создаются по тому же принципу, что и имена каталогов файловой системы. В начале расположено имя, определяющее общую тему, а затем тема уточняется. Например, группы

comp.os.linux.misc

comp.os.linux.hardware

comp.os.linux

comp.dcom.modems

comp.os.linux.misc

comp.os.linux.hardware

rec.arts.sf.dune

Когда пользователь посылает сообщение, сервер добавляет к нему поле заголовка

Message-Id

Для взаимодействия серверов новостей используются два типа протокола NNTP: протокол передачи (push protocol) и протокол получения (pull protocol). Во время передачи данных один из серверов выступает в роли клиента, а другой — в роли сервера. При использовании протокола передачи клиент сообщает серверу о каждом имеющемся у него сообщении, передавая его идентификатор. Сервер ищет это сообщение в своей базе данных и определяет, нужно ли оно ему. Процесс повторяется для каждого сообщения, которые присутствуют на сервере, выполняющем в процессе взаимодействия роль клиента. При этом производятся многочисленные обращения к базе данных. Альтернативой протоколу передачи является протокол получения, при использовании которого принимающий сервер выступает в роли клиента. Сначала принимающая система получает полный список сообщений, поступивших на сервер с указанного момента, а затем запрашивает конкретные сообщения. Такой протокол работает более эффективно, но при этом необходимо принимать меры предосторожности, чтобы сервер не передал сообщение, предназначенное для внутреннего использования.

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

Независимо от используемого протокола и времени хранения сообщений, в передаче материалов групп может участвовать несколько компьютеров. Серверы новостей взаимодействуют друг с другом, образуя сложную структуру. Передача материалов групп от одного сервера другому называется поставкой новостей. Как правило, небольшие серверы, подключенные через линии с относительно невысокой пропускной способностью, получают материалы групп у крупных серверов. Например, сервер, находящийся в небольшом колледже (назовем его условно Tiny College), может получать содержимое групп новостей у сервера большого университета (Pangaea University). Это означает, что основная часть сообщений, находящихся на сервере

news.tiny.edu

news.pangaea.edu

news.tiny.edu

news.pangaea.edu

news.tiny.edu

news.pangaea.edu

В службе новостей не соблюдается строгая иерархия. Например, не исключено, что на сервере

news.pangaea.edu

news.tiny.edu

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

Необходимо помнить, что поток сообщений передается в обоих направлениях. Если бы новые сообщения не передавались от сервера, получающего материалы, серверу, выступающему в роли поставщика, то у поставщика не было бы материалов групп. Крупные серверы выполняют функции "накопителей", на которые стекаются новые сообщения от пользователей. Но следует заметить, что небольшие серверы получают от поставщиков новостей гораздо больший объем материалов, чем они генерируют сами.

Среди серверов новостей, предназначенных для выполнения в системе Linux, наиболее популярным является InterNetNews, или INN (

http://www.isc.org/products/INN

innd

nnrpd

innxmit

nntpsend

/etc/news

/var/lib/news

Сервер INN в составе операционной системы Linux обычно поставляется в пакете под названием

inn

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

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

http://www.newsguy.com

Поддержка групп новостей при наличии ограниченных ресурсов

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

binary

или

binaries

. Как правило, такие группы находятся в категории

alt

, но они также встречаются в

comp

и других категориях.

Если же собираетесь предоставлять пользователям материалы групп в полном объеме, но имеющиеся ресурсы не позволяют сделать это, вы можете организовать получение материалов из внешнего источника (outsourcing). Для этого надо заключить соответствующий договор с поставщиком новостей и создать на своем сервере NDS запись, указав в ней IP-адрес сервера поставщика. У пользователей создастся впечатление, что они работают с вашим сервером новостей, но на самом деле основную работу по их обслуживанию будет выполнять внешний сервер. Так часто поступают провайдеры, предоставляющие услуги небольшим компаниям. Недостаток подобного подхода состоит в том, что администратор внешнего сервера может не согласиться поддерживать группы новостей для локального использования абонентами вашей сети.

Чтобы организовать полнофункциональный сервер новостей, необходимо затратить значительные средства как на приобретение оборудования и организацию быстродействующего соединения, так и на оплату услуг поставщика новостей. Например, на момент написания данной книги стоимость получения материалов групп на сервере NewsGuy составляла 1200 долларов в месяц, а для взаимодействия с этим сервером требовался компьютер не ниже, чем Pentium 400, с объемом оперативной памяти не менее 500 Мбайт, оснащенный жестким диском объемом не меньше 64 Гбайт. Для получения данных требовалась пропускная способность соединения не ниже 3 Мбод. Планируя пропускную способность соединения, необходимо также учитывать, что на сервер будут обращаться клиенты. В зависимости от набора поддерживаемых вами групп новостей, времени хранения сообщений и других характеристик сервера, требования к ресурсам могут увеличиваться или уменьшаться. Поскольку количество групп и объем сообщений в них ежегодно возрастает, не исключено, что приведенные выше требования вскоре придется пересмотреть.

Настройка INN предполагает установку большого количества опций в различных конфигурационных файлах. В пакете, предназначенном для инсталляции, указаны такие значения опций, которые практически обеспечивают функционирование сервера. Вам остается лишь привести некоторые установки в соответствии с требованиями системы. Например, вам понадобится объявить поддерживаемые группы новостей и настроить средства для контроля доступа. (Если вы хотите установить полнофункциональный Usenet-сервер, администратор поставщика новостей, скорее всего, сообщит вам установки, необходимые для доступа к его серверу.) Необходимо также определить политику удаления сообщений по истечении срока их действия и сообщить INN, как следует обрабатывать специальные управляющие сообщения (например, команды на удаление статей, создание новых групп и т.д.).

Основным конфигурационным файлом является

/etc/news/inn.conf

имя_опции: значение

Такой же синтаксис используется и в других конфигурационных файлах. Значения большинства опций в файле

inn.conf

• 

organization

organization

• 

server

localhost

• 

pathhost

Path

news.threeroomco.com

• 

moderatormailer

%s@uunet.uu.net

• 

domain

threeroomco.com

• 

fromhost

From

• 

complaints

complaints

В файле

inn.conf

inn.conf

В файле

inn.conf

active

newsgroups

pathdb

inn.conf

/var/lib/news

Файл

active

имя_группы максимальный_номер минимальный_номер флаги

В первом поле указывается полное имя группы, например

comp.os.linux.misc

• 

y

• 

n

• 

m

• 

j

• 

x

• 

=группа_новостей

Сервер новостей, который допускает только локальные операции, может поддерживать лишь несколько групп. Имена этих групп задаются произвольно, но они должны соответствовать схеме, принятой в Usenet. При желании вы можете назначать локальным группам имена, начинающиеся с имени вашей организации, например, на сервере новостей, расположенном в домене

threeroomco.com

threeroomco.support

threeroomco.support.bigproduct

threeroomco.accounting

active

В процессе работы сервера INN значения полей

максимальный_номер

минимальный_номер

active

максимальный_номер

минимальный_номер

минимальный_номер

Файл

newsgroups

active

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

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

/etc/news/newsfeeds

/etc/news/newsfeeds

идентификатор_узла:шаблон[,шаблон...]:флаг[, флаг...]:параметр

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

\

• 

идентификатор_узла

• 

шаблон

*

comp.os.*

comp.os

!

@

!comp.os.linux

comp.os.linux

comp.os.linux.hardware

comp.os.linux.hardware

@comp.os.linux

newsfeeds

comp.os.*, !comp.os.linux

comp.os

!comp.os.linux

comp.os.*

!comp.os.linux

• 

флаг

<размер

Gчисло

• 

параметр

newsfeeds

Файл

newsfeeds

/etc/news/nntpsend.ctl

newsfeeds

nntpsend.ctl

идентификатор_узла: имя_узла: максимальный_размер: [параметры]

Значение в поле

идентификатор_узла

newsfeeds

имя_узла

максимальный_размер

2m

innxmit

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

Сервер INN может управлять доступом со стороны других серверов и клиентов. Основной демон,

innd

innd

/etc/news/incoming.conf

innd

Атрибуты и их значения, задаваемые в файле

incoming.conf

ключ : значение

peer

incoming.conf

Листинг 12.1. Пример файла

incoming.conf

# Глобальные установки

streaming: true

max-connections: 50

# Allow NNTP posting from localhost

peer ME {

 hostname: "localhost, 127.0.0.1"

}

# Разрешение на передачу групп fiveroomco.com.

peer fiveroom {

 hostname : news.f iveroomco.com

 patterns: *,!threeroomco.*

}

Наиболее важным является ключ

hostname

patterns

newsfeeds

incoming.conf

Возможно, вы захотите осуществлять проверку пользователей на право доступа к вашему серверу. Поскольку

innd

/etc/news/nnrp.access

имя_узла: полномочия: имя_пользователя: пароль: группы_новостей

Назначение каждого поля описано ниже.

• 

имя_узла

*

*.threeroomco. com

threeroomco. com

• 

полномочия

R

P

N

NEWNEWS

L

• 

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

+

• 

пароль

• 

группы новостей

newsgroups

*

Если в файле

nnrp.access

Содержимое файла

/etc/news/expire.ctl

шаблон:флаг:хранение:время_по_умолчанию:удаление

• 

шаблон

*

comp.os.*

comp.os

• 

флаг

M

U

А

• 

хранение

Expires

хранение

Expires

Expires

never

never

• 

время_по_умолчанию

Expires

never

• 

удаление

Expires

Expires

хранение

время_по_умолчанию

never

Сервер INN выполняется в режиме демона и запускается посредством сценариев SysV. Если вы инсталлировали сервер новостей с помощью пакета, поставляемого в комплекте с операционной системой, вы можете непосредственно вызывать соответствующий сценарий для запуска сервера.

Некоторые описанные выше задачи демон

innd

cron

crontab

/etc/cron.d

/etc/cron.interval

crontab

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

ctlindd

ctlindd -h

Сервер INN обычно используется крупными провайдерами или организациями, специализирующимися на предоставлении пользователям материалов групп новостей. Как было сказано выше в данной главе, в некоторых случаях необходимо иметь небольшой сервер новостей с ограниченными возможностями для ограниченного числа групп новостей. Кроме того, часто возникает необходимость организовать работу с группами новостей в рамках локальной сети при временном отсутствии связи с Internet. Сервер, решающий такую задачу, должен за время соединения скопировать материалы некоторых групп с внешнего сервера новостей и передать на этот сервер сообщения, отправленные в эти группы локальными пользователями. Такие сеансы взаимодействия обычно производятся один-два раза в день. Желательно выбрать для этого время, когда внешний сервер не слишком загружен. Необходимые для этого действия может выполнять сервер INN, но мощность данного инструмента несоизмерима с поставленной задачей. INN взаимодействует с другими серверами новостей как равноправный партнёр, поэтому вам трудно будет найти поставщика новостей, который согласился бы планировать активность своего сервера в соответствии с графиком работы вашего сервера INN. Для решения поставленной задачи лучше использовать специальный сервер новостей с ограниченным набором возможностей. На роль подобного сервера хорошо подходит продукт Leafnode (

http://www.leafnode.org

На заметку

Leafnode — не единственный сервер, позволяющий организовать работу с группами новостей в автономном режиме. С такой задачей также хорошо справляются NNTPCache (

http://www.nntpcache.org

), Noffle (

http://noffle.sourceforge.net

), sn (

http://infa.abo.fi/~patrik/sn/

) и NewsCache (

http://www.infosys.tuwien.ac.at/NewsCache/

).

Подобно INN, функционирование продукта Leafnode обеспечивает несколько взаимодействующих между собой программ. Наиболее важные из них перечислены ниже.

• 

leafnode

• 

fetchnews

cron

fetchnews

• 

texpire

/var/spool/news

texpire

cron

• 

newsq

Leafnode осуществляет динамическую загрузку материалов групп. Если пользователь предпринимает попытку работы с группой, то при следующем запуске

fetchnews

Одна из особенностей программы Leafnode состоит в том, что при ее использовании не требуется настройка для работы с источником новостей. Leafnode (если быть точным, программа

fetchnews

На заметку

С одной стороны, Leafnode потребляет больше ресурсов, чем обычная программа просмотра новостей, но, с другой стороны, она экономит ресурсы. Получение материалов обычной группы не занимает много времени и может осуществляться в течение одного сеанса связи с провайдером по протоколу PPP. Чтобы пользователь мог работать с группой, обычная программа просмотра новостей должна поддерживать постоянное соединение с внешним сервером. Если Internet-услуги предоставляются на условиях поминутной оплаты, Leafnode, безусловно, экономит ресурсы. В то же время Leafnode копирует все сообщения группы, даже те, которыми не заинтересуется ни один локальный пользователь. Но если с Leafnode работают несколько пользователей, которые интересуются приблизительно одинаковым набором материалов групп, общий объем переданной информации получается меньше, чем если бы каждая клиентская программа непосредственно взаимодействовала с внешним сервером.

В начале 2002 г. последней версией Leafnode была версия 1.9.19. Следующая версия (2.0) в это время находилась в стадии разработки. В версии 2.0 планируется реализовать поддержку локальных групп новостей. В версии 1.9.x такая возможность отсутствует.

Важно помнить, что продукт Leafnode разрабатывался для небольших узлов. Масштабируемость данного пакета ограничена, поэтому при обслуживании большого количества пользователей и поддержке большого числа групп новостей производительность Leafnode резко снижается. Наилучшим образом данный пакет обслуживает 20-25 пользователей. Если большая нагрузка приводит к снижению эффективности работы Leafnode, целесообразно рассмотреть возможность перехода к использованию INN или другого полнофункционального сервера новостей.

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

fetchnews

Настройка пакета Leafnode сводится к настройке трех программ:

leafnode

fetchnews

texpire

Основной конфигурационный файл Leafnode называется

config

#

опция = значение

Минимальная конфигурация Leafnode предполагает наличие лишь двух опций:

server

expire

config

• 

server

server = news.abigisp.net

server

• 

expire

• 

username

• 

password

Внимание

Следует заметить, что пароль хранится в незашифрованном виде. По умолчанию файл

config

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

• 

port

• 

nodesc

nodesc = 1

• 

timeout

fetchnews

• 

groupexpire имя_группы

comp.os.linux

comp.os.linux.*

• 

maxfetch

maxfetch

• 

initialfetch

initialfetch

• 

delaybody

maxfetch

delaybody

• 

maxcrosspost

maxcrosspost

• 

maxage

maxage

• 

maxlines

maxlines

• 

minlines

minlines

• 

maxbytes

• 

timeout_short

• 

timeout_long

• 

timeout_active

• 

filterfile

• 

hostname

Перечисленные выше опции имеют отношение ко всем трем основным программам Leafnode:

leafnode

fetchnews

texpire

Как было сказано ранее, сервер

leafnode

inetd

xinetd

inetd.conf

nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/leafnode

В дистрибутивных пакетах, в которых используется суперсервер

xinetd

leafnode

/etc/xinetd.d

inetd

xinetd

leafnode

Внимание

В конфигурационном файле Leafnode не предусмотрены опции контроля доступа. Для того чтобы управлять взаимодействием с компьютерами локальной сети и внешними узлами, вы можете установить соответствующую конфигурацию TCP Wrappers.

При каждом запуске программы

fetchnews

newsq

/etc/leafnode/config

fetchnews

При вызове программы

fetchnews

• 

-v

v

v

-vvvv

fetchnews

• 

-х число

• 

-1

• 

-n

• 

-f.

• 

-P

fetchnews

Совет

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

fetchnews

. Чтобы новые сообщения стали доступны после очередного выполнения

fetchnews

, надо предварительно вызвать

fetchnews

с опцией

-P

. В Leafnode 2.0 задержка при получении собственных сообщений не возникает, поэтому предварительный вызов

fеtchnews

не требуется.

Принимая меры для организации работы Leafnode, необходимо решить, каким способом следует вызывать программу

fetchnews

ppp-on-dialer

fetchnews

cron

fetchnews

fetchnews

Программа

texpire

/etc/leafnode/config

texpire

cron

/etc/cron.daily

texpire

crontab

Принимая решение об удалении сообщений, программа

texpire

Подобно

fetchnews

texpire

-v

-f

texpire

-f

texpire

-f

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

obnoxious@annoying.com

/etc/leafnode/filters

/etc/leafnode/filters

obnoxious@annoying.edu

^From:.*obnoxious@annoying\.edu

Данное выражение начинается с символа

^

From:

*

obnoxious@annoying.edu

\

На заметку

Более подробно регулярные выражения будут рассмотрены в главе 19.

Для фильтрации сообщений вам надо указать Leafnode расположение файлов фильтров. Для этого можно использовать опцию

filterfile

/etc/leafnode/config

/etc/leafnode/filters

Серверы новостей потребляют значительные ресурсы. Для поддержки групп новостей Usenet необходимо ежедневно передавать большой объем данных, кроме того, эти данные приходится хранить в течение нескольких дней. Чтобы инсталлировать полнофункциональный сервер новостей, необходим отдельный компьютер с дисковым пространством в десятки и даже сотни гигабайт. Если ваши потребности более скромны, вы можете установить сервер новостей, не реализуя взаимодействие его с Usenet. С помощью такого сервера можно обеспечить работу нескольких локальных групп новостей и даже групп, доступных для всего мира. Как для поддержки Usenet в полном объеме, так и для организации локальных групп используется сервер INN, который может выполняться в среде Linux. Функционирование этого сервера обеспечивает несколько взаимодействующих друг с другом программ; для их настройки используется несколько конфигурационных файлов. С помощью этих файлов вы можете описывать группы новостей, которые должны поддерживаться на сервере, задавать политику взаимодействия с другими серверами и клиентами, а также определять прочие характеристики сервера.

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

Многие серверы предоставляют доступ лишь к отдельным ресурсам компьютера, на котором они выполняются. Например, временной сервер, рассмотренный в главе 10, сообщает о показаниях системных часов, а сервер шрифтов, который будет обсуждаться в главе 15, передает клиентам битовые карты символов того или иного шрифта. Существуют, однако, серверы, которые предоставляют более или менее полный доступ к ресурсам компьютера и называются серверами удаленной регистрации (remote login server). Такие серверы позволяют пользователям регистрироваться в системе и запускать в ней различные программы так же, как это происходит при работе за консольным терминалом. Сервер удаленной регистрации организует работу нескольких пользователей на одном компьютере.

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

pine

mutt

gcc

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

rlogind

rlogind

rlogind

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

Внимание

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

Сервер

rlogind

rlogin

rlogind

in.rlogind

rlogind

rlogind

Сервер

rlogind

/etc/inetd.conf

rlogind

xinetd

rlogind

/etc/xinetd.d

rlogind

На выполнение

rlogind

• 

-n

rlogind

-n

• 

-а

•

-h

rlogind

.rhosts

-h

• 

-l

.rhosts

-h

• 

-L

.rhosts

hosts.equiv

Внимание

Несмотря на то что опции

-h

,

-l

и

-L

входят в официальный набор опций

rlogind

, в новых версиях Linux они обычно не оказывают влияния на работу сервера. Причина в том, что в новых версиях системы используются модули РАМ; в результате действие указанных опций отменяется.

Средства защиты всех утилит, реализующих r-команды, в лучшем случае могут считаться устаревшими. А если подходить к этому вопросу с позиции современных требований, следует признать, что защита в них вовсе отсутствует. В частности, работа сервера

rlogind

rlogind

rlogind

Рассмотрим принцип работы базовых средств защиты

rlogind

rlogind

1. Сервер проверяет порт клиента, выступающего инициатором установления соединения. Обычно клиент-программы

rlogin

rlogind

rlogin

root

root

2. Сервер удаленной регистрации обращается к серверу DNS, чтобы преобразовать IP-адрес клиента в доменное имя.

3. Если имя, полученное в результате DNS-преобразования, принадлежит тому же домену, что и сервер, или если при запуске

rlogind

-а

-L

-l

rlogind

~/.rhosts

/etc/hosts.equiv

rlogind

4. Если IP-адрес, полученный в результате DNS-преобразования, и IP-адрес, указанный в запросе, не совпадают, либо если была задана опция

-L

-l

rlogind

rlogind

При выполнении описанной выше процедуры регистрации предполагается, что программа

rlogind

rlogin

-l

rlogin -l s jones

Поскольку

rlogind

.rhosts

rlogind

.rhosts

rlogind

rlogind

[rodsmith@nessus rodsmith]$ rlogin speaker

Last login: Mon Aug 12

14:48:58 2002 from nessus on 4

[rodsmith@speaker rodsmith]$

Еще одна особенность

rlogind

rlogind

Таким образом, если вам необходимо, чтобы соединение с сервером удаленной регистрации устанавливалось быстро и чтобы для установления соединений можно было использовать сценарий, имеет смысл рассмотреть целесообразность применения

rlogind

rlogind

Если вы обращаетесь к

rlogind

• Создать запись в файле

/etc/hosts.equiv

julia

fred

• Создать запись в файле

~/.rhosts

.rhosts

Внимание

Тот факт, что файл

~/.rhosts

доступен для пользователя, означает, что вы как системный администратор делегируете вашим пользователям право настраивать средства защиты системы. Это одна из причин, по которым применять сервер

rlogind

не рекомендуется. Если же по каким-либо причинам вам приходится запускать на компьютере

rlogind

, используйте TCP Wrappers либо другие средства ограничения доступа.

Оба описанных выше файла управляют использованием всех r-команд на сервере, в частности

rlogin

rcp

rsh

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

[+|-][имя_узла] [имя_пользователя]

Символ

+

-

+

-

Внимание

Используя символ

+

, будьте внимательны. Если в строке указан только этот символ (а имя узла отсутствует), доступ разрешается для всех клиентов. Подобная политика защиты является одним из недостатков r-команд. Если вы по ошибке введете пробел между символом

+

и именем узла, система будет интерпретировать имя узла как имя пользователя и предоставит возможность обращаться к серверу со всех компьютеров.

Для идентификации узла может использоваться IP-адрес (например, 192.168.34.56) или имя (например,

gingko.threeroomco.com

gingko

@,

Если вы включите в состав записи имя пользователя, то указанному пользователю будет предоставлен доступ к системе. Запись в файле

.rhosts

.rhosts

.rhosts

julia

172.21.13.14 jbrown

В этом случае пользователь

jbrown

julia

jbrown

rlogin

-l julia

Записи в файле

/etc/hosts.equiv

root

/etc/hosts.equiv

jbrown

julia

root

/etc/hosts.equiv

-

Доступ к

rlogind

~/.rhosts

/etc/hosts.equiv

rlogind

inetd

xinetd

rlogind

Протокол Telnet часто используется для удаленной регистрации в сети Internet. Клиент-программа Telnet (как правило, она называется

telnet

rlogind

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

rlogind

В некоторых случаях сервер Telnet инсталлируется по умолчанию при установке операционной системы, но иногда приходится инсталлировать этот сервер самостоятельно. Пакет, содержащий сервер Telnet, в различных системах называется по-разному. Например, в Caldera он называется

netkit-telnet

telnetd

telnet-server

tcpipl

nkitserv

telnet

telnetd

telnet

telnetd

in.telnetd

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

• 

-D режим_отладки

telnetd

options

report

netdata

ptydata

• 

-h

telnetd

-h

• 

-L программа_регистрации

telnetd

/bin/login

• 

-n

rlogind

telnetd

-n

При вызове сервера могут быть также указаны другие опции, большинство из которых управляет шифрованием данных и поддержкой прочих расширенных средств защиты. Поскольку в большинстве версий Telnet-серверов расширенные средства защиты отсутствуют, эти опции применяются крайне редко. Следует заметить, что разновидности Telnet-серверов, обеспечивающие шифрование данных, не пользуются большой популярностью, так как задача обмена закодированными данными гораздо лучше решается с помощью SSH. Если в вашей сети установлена система Kerberos, в ее состав обычно входят керберизованные версии клиента и сервера Telnet, которые можно использовать для повышения уровня защиты при удаленной регистрации пользователей на сервере.

При получении запроса на установление соединения сервер

telnetd

/etc/issue.net

-h

telnetd

На заметку

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

/etc/issue

. (При установлении соединения с помощью X Window данный файл не используется. Вопросы удаленной регистрации средствами X Window будут рассматриваться в главе 14.)

Многие системы позволяют непосредственно редактировать файл

/etc/issue.net

telnetd

Таблица 13.1. Переменные, используемые в файле

/etc/issue.net

Предположим, что текст в файле

/etc/issue.net

Welcome to %h.

Current time is %d.

Notice: For authorized users only!

Если ваш компьютер имеет имя

maple.threeroomco.com

$ telnet maple.threeroomco.com

Trying 172.21.32.43...

Connected to maple.threeroomco.com.

Escape character is '^]'.

Welcome to maple.threeroomco.com.

Current time is 10:57 on Monday, 12 August 2002.

Notice: For authorized users only!

В некоторых разновидностях Linux (в частности, в Caldera, Mandrake и некоторых версиях Red Hat) файлы

/etc/issue

/etc/issue.net

/etc/rc.d/rc.local

# Этот сценарий создает файл /etc/issue при каждой

# загрузке системы. Чтобы сохранить изменения, внесенные

# в файл /etc/issue, надо изменить код сценария.

if [ -х /usr/bin/linux_logo ]; then

 /usr/bin/linux_logo -c -n -f > /etc/issue

 echo "" >> /etc/issue

else

 echo "" > /etc/issue

fi

echo "$R" >> /etc/issue

echo "Kernel $(uname -r) on $ a $SMP$ (uname -m) / \1" >> /etc/issue

if [ "$SECURITY" -le 3 ]; then

 echo "Welcome to %h" > /etc/issue.net

 echo "$R" >> /etc/issue.net

 echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue.net

else

 echo "Welcome to Mandrake Linux" > /etc/issue.net

 echo "-------------------------" >> /etc/issue.net

fi

На заметку

Начиная с версии 7.2 в системе Red Hat используются статические файлы

issue

и

issue.net

. В Caldera 3.1 и Mandrake 8.1 эти файлы по-прежнему формируются с помощью сценария

/etc/rc.d/rc.local

.

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

/etc/issue

/etc/issue.net

/etc/rc.d/rc.local

/etc/issue

/etc/issue.net

После отображения начального сообщения, содержащегося в файле

/etc/issue.net

telnetd

/bin/login

-L

/bin/login

login:

password:

/bin/login

Поскольку большинство серверов Telnet не шифрует данные, пересылаемые по сети, пользовательское имя и пароль передаются в незакодированном виде. Несмотря на то что при вводе пароля символы не отображаются на экране, пароль может быть перехвачен по пути следования от клиента к серверу. Если вы не указываете при вызове

telnetd

-L

telnetd

rlogind

Как известно, при передаче данных по Internet информационные пакеты проходят через несколько шлюзов. Если злоумышленник получит контроль хотя бы над одним из шлюзов, он сможет перехватить пароль, передаваемый при регистрации на сервере Telnet, и получит доступ к вашему компьютеру. Перехват данных можно организовать также в локальной сети, к которой подключен клиент или сервер. Компьютер, подключенный к локальной сети, но непосредственно не участвующий в процессе обмена данными, может быть переведен в режим сбора сетевых пакетов. Наряду с остальными пакетами пароль, переданный клиентом, окажется на этом компьютере.

Отсутствие шифрования передаваемых данных чревато не только перехватом пароля, но и утечкой другой важной информации. Злоумышленник может узнать содержимое важного письма, которое вы читали, или файла, который вы редактировали. Если во время сеанса Telnet вы используете команду

su

rlogind

rlogind

Что же можно предпринять для уменьшения риска потери данных? Очевидно, что радикальной мерой является переход к использованию протокола, обеспечивающего кодирование передаваемой информации. Если же это по каким-либо причинам невозможно или нежелательно, то, чтобы уменьшить вероятность утечки важных сведений, рекомендуется придерживаться ряда правил. Не просматривайте файлы, содержащие секретные данные, или важные письма при работе посредством Telnet. He регистрируйтесь из сеанса Telnet на другом компьютере. Даже если второе соединение устанавливается по защищенному каналу, информация будет поступать на ваш компьютер в незакодированном виде и может стать доступна злоумышленнику. Не используете команду

su

root

Из протоколов, обеспечивающих защиту передаваемых данных, среди пользователей Linux наиболее популярен SSH (Secure Shell — защищенная оболочка). Данные, предназначенные для передачи по сети посредством данного протокола, шифруются. Очевидно, что шифрованные данные могут быть перехвачены на маршрутизаторе или в локальной сети, но технология, позволяющая декодировать их, в настоящее время отсутствует. (Теоретически достаточно мощный компьютер способен справиться с задачей расшифровки информации, но для этого ему потребуется очень много времени. Кроме того, компьютеры необходимой мощности встречаются достаточно редко, и получить доступ к ним очень трудно.)

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

На заметку

В 2001 году бурно обсуждался вопрос использования названия SSH в качестве торговой марки. Не исключено, что в ближайшее время протокол SSH и одна из его реализаций (OpenSSH) изменят свое название. Что же касается коммерческого продукта, реализующего этот протокол (SSH), то он и далее будет поставляться под тем же названием. На момент написания данной книги этот вопрос еще не был решен, поэтому я использую здесь названия, указанные на Web-узлах соответствующих продуктов. Изменения, скорее всего, будут относиться к названию пакета и не затронут название программ, содержащихся в его составе.

Существуют два основных пакета SSH, предназначенных для работы в системе Linux: коммерческий продукт SSH (

http://www.ssh.com/products/ssh/

http://www.openssh.org

На заметку

Проект OpenSSH имеет непосредственное отношение к операционной системе OpenBSD. Двоичные коды OpenSSH различаются для разных систем. В документе

http://www.openssh.org/portable.html

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

В декабре 2001 года была создана версия 3.1 продукта SSH. В том же месяце был выпущен пакет OpenSSH 3.0.2. В версиях 3.0.x этих продуктов поддерживался приблизительно одинаковый набор возможностей и использовалась одна и та же технология кодирования. В версии 3.1 SSH была добавлена поддержка PKI (Public Key Infrastructure — инфраструктура открытого ключа), позволяющая использовать для идентификации участников взаимодействия сертификаты, реализована возможность аппаратной идентификации, а также включены другие дополнительные средства. Продукт SSH несколько опережает по своему развитию OpenSSH; это вполне объяснимо, так как протокол SSH был разработан компанией SSH.

Программы SSH и OpenSSH могут взаимодействовать между собой, поэтому, организуя обмен по протоколу SSH, не слишком важно, какой тип клиента и сервера используется на компьютерах. Существуют незначительные несоответствия между конкретными версиями пакетов, которые нетрудно учесть. Протокол SSH разработан так, что компьютеры, на которых установлено программное обеспечение, поддерживающее различные версии SSH, могут использовать средства, присутствующие в обеих версиях. Например, если на одном компьютере поддерживается SSH 2, а на другом — SSH 3, они могут взаимодействовать по протоколу SSH 2.

В большинстве случаев пакет OpenSSH поставляется в виде нескольких файлов. Наиболее важными являются

openssh

openssh-client

openssh-server

Протокол SSH распространен не так широко как Telnet, поэтому вам необходимо специально установить клиентские программы SSH на компьютеры ваших пользователей. Такие программы существуют для различных операционных систем. Информация о бесплатно распространяемых клиентах SSH находится на сервере

http://www.freessh.org

Основное отличие SSH от большинства протоколов удаленной регистрации заключается в том, что SSH обеспечивает шифрование передаваемых данных. Кроме того, данный протокол поддерживает перенаправление, или туннелирование, сетевых портов между клиентом и сервером. Это значит, что посредством SSH-соединения могут передаваться пакеты других протоколов. Возможна конфигурация, при которой SSH-соединение будет автоматически использоваться для обмена данными по некоторому протоколу, например, такое взаимодействие реализовано для X Window. (Подробно вопрос установления соединений средствами X Window будет рассмотрен в главе 14.) Затратив определенные усилия для настройки системы, можно реализовать туннелирование сообщений любого протокола посредством защищенного соединения. Вы можете даже использовать средства PPP для создания сетевого интерфейса, предполагающего туннелирование средствами SSH. В результате можно получить виртуальную частную сеть (VPN — Virtual Private Network). Необходимые действия по настройке такой сети описаны в документе VPN HOWTO (

http://www.linuxdoc.org/HOWTO/VPN-HOWTO.html

Заслуживает внимания еще одна возможность протокола SSH — непосредственная реализация инструментов, не связанных с регистрацией в системе. В частности, в состав пакета SSH входит программа под названием

scp

scp [[пользователь1]узел1:]имя_файла1 \

 [[пользователь2]узел2:]имя_файла2]

Вызов

scp

rcp

scp

rcp

rcp

Дополнительные интерактивные возможности при передаче файлов обеспечивает программа

sftp

ftp

http://gftp.seul.org

Стандартный сервер SSH (программа

sshd

ssh

scp

sftp

Независимо от того, какую реализацию протокола SSH вы используете, сервер обычно запускается с помощью сценария SysV. Запуск сервера может осуществляться также посредством суперсервера, но такая возможность используется крайне редко. Дело в том, что запуск старых версий сервера происходил с большой задержкой, так как некоторые операции, выполняемые при запуске, создавали большую нагрузку на процессор. Если сервер выполняется на современном оборудовании, задержка практически не заметна, поэтому при желании вы можете сконфигурировать

sshd

-i

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

• 

-d

-d

sshd

d

• 

-D

-d

• 

-е

sshd

• 

-f конфигурационный_файл

/etc/ssh/sshd_config

• 

-i

inetd

xinetd

sshd

• 

-p порт

• 

-q

• 

-4

sshd

sshd

• 

-6

При запуске

sshd

sshd

Перед первым запуском

sshd

# ssh-keygen -q -t rsa1 -f /etc/ssh/ssh_host_key -C '' -N ''

# ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -C '' -N ''

# ssh-keygeh -q -t dsa -f /etc/ssh/ssh_host_dsa_key -C '' -N ''

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

.pub

ssh_host_key

ssh_host_key.pub

ssh_host_rsa_key

ssh_host_rsa_key.pub

ssh_host_dsa_key

ssh_host_dsa_key.pub

/etc/ssh

Работой сервера

sshd

sshd_config

/etc/ssh

sshd_config

ssh_config

sshd_config

Опция значение

Подобно другим конфигурационным файлам, строка, начинающаяся с символа

#

sshd_config

sshd

PermitRootLogin

sshd_config

• 

Port

• 

HostKey

/etc/ssh/ssh_host_key

• 

KeyRegenerationInterval

• 

PermitRootLogin

sshd

root

no

root

PermitRootLogin

root

su

• 

IgnoreRhosts

yes

~/.rhosts

IgnoreRhosts

RhostsAuthentication

yes

sshd

rlogind

IgnoreRhosts

• 

RhostsAuthentication

IgnoreRhosts

RhostsAuthentication

RhostsAuthentication

no

• 

RSAAuthentication

yes

RSAAuthentication

• 

PubkeyAuthentication

RSAAuthentication

• 

PasswordAuthentication

yes

PasswordAuthentication

• 

X11Forwarding

yes

X11Forwarding

ForwardX11

/etc/ssh/ssh_config

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

sshd

В процессе обмена сервер и клиент SSH используют различные способы кодирования передаваемых данных. Упрощенно это выглядит так. Участники взаимодействия договариваются о временном использовании метода кодирования с помощью открытого ключа. Ключ представляет собой достаточно большое число и применяется для шифрования информации, передаваемой по сети. При получении данных система декодирует их с помощью закрытого ключа. Такой способ кодирования используется для передачи другого типа ключа, называемого секретным ключом. Секретный ключ используется в другом методе шифрования и обеспечивает более высокое быстродействие по сравнению с кодированием посредством открытого и закрытого ключей. По завершении передачи секретного ключа компьютеры, обменивающиеся по протоколу SSH, начинают использовать для кодирования данных секретный ключ. Помимо передачи секретного ключа, открытый и закрытый ключи применяются также при аутентификации; идентификатор пользователя, зашифрованный с помощью закрытого ключа, позволяет убедиться в том, что пользователь — именно тот, за кого он себя выдает.

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

1. Клиент предпринимает попытку аутентификации, основанной на принципе доверия, однако в большинстве случаев значения опций

RhostsAuthentication

IgnoreRhosts

2. Клиент пытается использовать способ аутентификации, представляющий собой сочетание принципа доверия и RSA-аутентификации. В большинстве случаев такая попытка тоже не имеет успеха.

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

4. Если все предшествующие попытки аутентификации окончились неудачей, пользователь должен ввести пароль. Этот пароль передается серверу в закодированном виде и применяется для аутентификации пользователя.

Сервер хранит файлы, содержащие ключи, в каталоге

/etc/ssh

~/.ssh

ssh

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!        @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

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

.ssh/known_hosts

~/.ssh/known_hosts2

В отличие от

telnetd

sshd

/bin/login

sshd

sshd

login

UseLogin

sshd_config

sshd

telnetd

login

login

sshd

Пользователи могут генерировать ключи и использовать их для регистрации на сервере. Эти ключи хранятся на клиентской машине в каталоге

~/.ssh

1. Зарегистрируйтесь на компьютере, выполняющем роль клиента при SSH-обмене.

2. Введите команду генерации ключей, соответствующих версии 2 SSH. Эта команда приведена ниже; для ее выполнения потребуется несколько секунд.

$ ssh-keygen -q -t rsa -f ~/.ssh/id_rsa -C '' -N ''

На заметку

Если вы не укажете опцию

-N ''

, утилита

ssh-keygen

запросит фразу пароля. Если перед нажатием клавиши <Enter> вы введете какие-либо символы, вам придется указывать их при каждом соединении с сервером. С точки зрения пользователя использование фразы пароля при регистрации принципиально не отличается от указания пароля.

3. Скопируйте файл

~/id_rsa.pub

.pub

scp

$ scp ~/.ssh/id_rsa.pub server:.ssh/id_rsa.client

4. Зарегистрируйтесь на сервере. Для этого вы можете использовать

ssh

5. Сделайте каталог

~/.ssh

id_rsa.client

6. Добавьте открытый ключ в файл

authorized_keys2

$ cat id_rsa.client >> authorized_keys2

С этого момента вы можете устанавливать соединение с сервером, используя протокол SSH 2. Если вы не указали фразу пароля, при регистрации вам не придется вводить какие-либо идентификационные данные. Опция

-2

$ ssh -2 server

Внимание

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

rlogind

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

Для того чтобы обеспечить RSA-аутентификацию при использовании протокола SSH 1, ваши действия должны несколько отличаться от приведенных выше. Новая процедура и процедуры, описанные ранее, имеют следующие отличия.

• В п. 2 вместо

-t rsa -f ~/.ssh/id_rsa

-t rsa1 -f ~/.ssh/identity

• В п. 6 открытый ключ из

identity.pub

authorized_keys2

authorized_keys

• При установлении соединения, вызывая ssh, не надо указывать опцию

-2

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

RSAAutentification

PubkeyAuthentication

/etc/ssh/sshd_config

Заметьте, что пользоваться SSH-соединением можно, не настраивая программы для аутентификации с помощью открытого ключа. Подобная аутентификация лишь исключает необходимость ввода пароля либо обеспечивает дополнительную степень защиты за счет использования фразы пароля.

SSH-аутентификацию можно также организовать с помощью инструмента, который называется

ssh-agent

ssh-agent

ssh-agent

• Создайте закрытый и открытый ключи, выполнив описанную выше процедуру, и скопируйте открытый ключ в свой рабочий каталог на сервере SSH. При вызове

ssh-keygen

-N ''

• На компьютере, на котором выполняется клиентская программа SSH, задайте команду

ssh-agent /bin/bash

ssh-agent

ssh-agent

• Чтобы добавить RSA-ключ SSH к кэшу ключей

ssh-agent

ssh-add ~/.ssh/id_rsa

~/.ssh/id_rsa

ssh-add

С этого момента вы можете обращаться к серверу SSH с помощью SSH-клиента; причем вам не придется вводить ни пароль, ни фразу пароля. Программа

ssh-agent

ssh-agent

ssh-agent

ssh-agent

ssh

ssh-agent

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

ssh

ssh-agent

ssh-add

ssh-agent

ssh-agent

• Вы можете внести изменения в файл

/etc/passwd

ssh-agent

/etc/passwd

/bin/bash

/usr/bin/ssh-agent/bin/bash

ssh-agent

ssh-agent /bin/bash

ssh-add ~/.ssh/id_rsa

ssh

ssh-agent

• Если вы регистрируетесь в текстовом режиме и запускаете X Window с помощью

startx

ssh-agent startx

ssh-agent

• Если вы используете инструменты регистрации с графическим интерфейсом, вам надо сохранить файл

.xsession

.xsession-nosshagent

ssh-agent ~/.xsession-nosshagent

ssh-agent

ssh-add

После запуска

ssh-agent

ssh-add -1

ssh-add -d

ssh-add -d

Одно из преимуществ использования

ssh-agent

ssh-agent

ssh-agent

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

Наиболее часто в системе Linux используются серверы удаленной регистрации

rlogind

rlogind

В главе 13 рассматривались серверы удаленной регистрации

rlogind

rlogind

Серверы удаленного доступа, поддерживающие графический интерфейс, в основном нужны тогда, когда компьютер должен выполнять роль рабочей станции для нескольких пользователей, работающих на удаленных компьютерах. Например, для рабочей группы, насчитывающей около десяти сотрудников, может быть приобретен один мощный компьютер и несколько компьютеров малой мощности, которые будут выполнять функции терминалов центральной машины. На центральном компьютере можно запускать приложения, интенсивно потребляющие ресурсы, например StarOffice, The GIMP, KMail и др. Пользователи, работающие на маломощных машинах, могут регистрироваться в центральной системе и запускать приложения на удаленном компьютере. Такая структура имеет ряд преимуществ по сравнению с конфигурацией, при которой каждый пользователь запускает необходимые ему программы на своей рабочей станции. Эти преимущества описаны ниже.

• Централизованное администрирование программного обеспечения. Для добавления, удаления или обновления приложений необходимо изменить конфигурацию лишь одного компьютера. (Альтернативой такому подходу является хранение приложений на файловом сервере и выполнение их на рабочих станциях.)

• Простая конфигурация рабочих станций. При использовании центрального компьютера аппаратное и программное обеспечение рабочих мест пользователей может быть очень простым. Для поддержки пользовательских компьютеров приходится затрачивать минимальные усилия. Администрирование подобных рабочих станций часто осуществляется с удаленного компьютера. По сути, в такой системе можно использовать X-терминалы — чрезвычайно простые компьютеры, поддерживающие X Window.

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

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

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

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

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

Средства удаленной регистрации, поддерживающие графический интерфейс, чаще всего применяются в локальных сетях. Поскольку для отображения графических элементов приходится передавать большой объем данных, использование соответствующих протоколов при работе в Internet существенно снизит скорость отображения информации. Даже в сети с пропускной способностью 100 Мбод применение протоколов удаленной регистрации заметно уменьшает быстродействие программ по сравнению с выполнением их на локальной машине, однако скорость работы остается в допустимых пределах. Подобно инструментам, которые осуществляют регистрацию в текстовом режиме, серверы, поддерживающие графический интерфейс, предоставляет пользователю все привилегии, необходимые для работы на удаленном компьютере. Однако при регистрации производится передача пароля в незакодированном виде, что создает опасность для системы. (Инструмент VNC предусматривает шифрование паролей; это несколько снижает риск, но остальные данные передаются в незашифрованном виде. Использование SSH в дополнение к средствам удаленной регистрации обеспечивает кодирование как паролей, так и всей информации, передаваемой в течение сеанса.)

Графическая среда, реализуемая средствами X Window, очень часто используется в системе Linux. Как было сказано ранее, система X Window поддерживает взаимодействие по сети. Даже если все компоненты X-программы выполняются на одном и том же компьютере, для отображения окон, меню, диалоговых окон и других элементов графического интерфейса используются сетевые протоколы. Чтобы правильно сконфигурировать клиент и сервер для обеспечения удаленного доступа с поддержкой графического интерфейса, необходимо ясно представлять себе работу этих протоколов.

Пользователи, не искушенные в вопросах применения вычислительной техники и сетевых протоколов, представляют себе сервер как большой мощный компьютер, находящийся в отдельной комнате. Пользователи работают за клиентскими машинами и время от времени обращаются к серверу. Такое представление, хотя и не идеально с технической точки зрения, не слишком далеко от истины. Действительно, в качестве сервера обычно используется мощный компьютер, а мощность клиентских компьютеров, взаимодействующих с сервером, часто бывает ограничена. Однако по отношению к системе X Window данная схема неприменима; в X Window все обстоит совершенно по-другому. Пользователи работают за компьютерами, представляющими собой серверы X Window, причем эти компьютеры могут быть низкоуровневыми. Клиент-программы X Window, как правило, выполняются на компьютерах, которые значительно превышают по мощности машины, выполняющие роль X-серверов.

Для того чтобы понять, почему так происходит, надо рассмотреть процесс обмена данными с точки зрения клиентской программы. Когда клиентская программа работает в сети, она устанавливает соединения с серверами, предназначенные для передачи данных. Программа-сервер предоставляет некоторые услуги клиенту. Рассмотрим в качестве примера текстовый процессор WordPerfect и его взаимодействие с сервером NFS. С помощью интерфейсных средств WordPerfect пользователь задает команду на получение файла из каталога, экспортируемого средствами NFS. В результате WordPerfect инициирует передачу данных по сети, т. е. передает серверу NFS запрос, означающий, что тот должен доставить файл. (На самом деле роль клиента NFS выполняет модуль ядра Linux, WordPerfect лишь задает модулю команду передачи данных.) В ответ на запрос сервер NFS предоставляет клиенту необходимый ресурс, в данном случае файл. Теперь представьте себе, что WordPerfect выполняется на удаленном узле и взаимодействует с пользователем посредством сервера X Window. Чтобы отобразить окно выбора файла, текстовый редактор должен запросить у сервера X Window услуги по выводу диалогового окна, текста и других данных. С точки зрения WordPerfect сервер X Window принципиально не отличается от других серверов, поддерживающих ввод-вывод данных. Тот факт, что выводимые данные будут представлены пользователю, не имеет значения для программы. Взаимодействие клиента X Window с серверами условно показано на рис. 14.1.

Рис. 14.1. Сервер X Window обеспечивает интерфейс между пользователем и программой, выполняющейся на удаленном компьютере

Сервер X Window представляет устройство отображения и одно или несколько устройств ввода (обычно клавиатуру и мышь). Сам X-сервер может выступать в роли клиента по отношению к другим серверам, например серверу шрифтов (он будет рассмотрен в главе 15). В ответ на запрос X-сервера сервер шрифтов доставляет ему шрифты, необходимые для отображения данных.

На заметку

Принцип взаимодействия клиента и сервера VNC противоположен принципу, реализованному в системе X Window. Детально работа VNC будет рассмотрена далее в этой главе. Отличие между данными протоколами приводит к тому, что одна система может успешно использоваться там, где вторая работает неэффективно либо не работает вовсе. В качестве примера можно привести конфигурацию сети, в которой между клиентом и сервером расположен брандмауэр. Если на пользовательских компьютерах выполняются X-серверы, необходимо специально сконфигурировать брандмауэр. При использовании VNC специальная настройка таблиц брандмауэра не требуется. Средства SSH создают иллюзию того, что клиент и сервер X Window "поменялись местами" и взаимодействие между ними осуществляется так же, как и в большинстве сетевых служб.

X-серверы в различных операционных системах

Программы, реализующие сервер X Window, доступны не только в Linux и UNIX, но и в других операционных системах. Если вы хотите использовать в качестве терминала компьютер под управлением Windows, OS/2 или MacOS, вы должны лишь инсталлировать в системе X-сервер. Для этого хорошо подходят продукты XFree86 (

http://xfree86.cygwin.com

— для Windows,

http://ais.gmd.de/~veit/os2/xf86os2.html

— для OS/2 и

http://mrcla.com/XonX/

— для MacOS X), MI/X — для Windows и MacOS Classic (

http://www.microimages.com/freestuf/mix/

), Exceed — для Windows (

http://www.hcl.com/products/nc/exceed/

), Xmanager — для Windows (

http://www.netsarang.com/products/xmanager.html

) и Xtools — для MacOS X (

http://www.tenon.com/products/xtools/

). Данный список не охватывает все доступные продукты. Так, например, только для Windows существует множество серверов. специально предназначенных для получения доступа к системе Linux. Материалы дискуссии, позволяющей оценить возможности различных серверов X Window, находятся по адресу

http://www.microimages.com/mix/prices.htm

.

Как было сказано ранее, существуют специальные устройства, называемые X-терминалами. Они поддерживают функции сервера X Window, обеспечивают обмен по сети TCP/IP, и этим их возможности практически исчерпываются. X-терминал по сути представляет собой выделенный X-сервер. X-терминалы поставляют некоторые компании, например Network Computing Devices (NCD;

http://www.ncd.com

) и Hewlett Packard (

http://www.hp.com

). Для работы этих устройств, как правило, необходимо, чтобы в сети выполнялся сервер TFTP (Trivial File Transfer Protocol — простой протокол передачи файлов); он нужен для передачи загрузочных файлов. (Сервер TFTP не обязательно должен находиться на компьютере, использующем X-терминал.) Кроме того, X-терминалы также требуют, чтобы на компьютере, для работы с которым они предназначены; присутствовал сервер регистрации, поддерживающий графический интерфейс. В качестве X-терминала может быть использован компьютер старой модели. На этом компьютере надо установить минимальные средства Linux и изменить конфигурационные файлы так, чтобы система обеспечивала регистрацию на удаленном компьютере.

Большинство дистрибутивных пакетов Linux позволяет после установки операционной системы на компьютер установить требуемую конфигурацию X-сервера. Этот сервер может использоваться для поддержки доступа локального компьютера к средствам отображения. Такая конфигурация позволяет одному и тому же компьютеру выступать в роли как клиента, так и сервера X Window, т.е. на компьютере, выступающем в роли X-сервера (рис. 14.1), могут выполняться свои X-программы. X-сервер в системе Linux может также применяться для взаимодействия с X-клиентами, выполняющимися на других компьютерах. Для того чтобы подобное взаимодействие стало возможным, надо выполнить несколько команд, которые будут описаны далее.

Для того чтобы компьютер выполнял роль X-клиента, дополнительное программное обеспечение не требуется; клиентами X Window являются сами программы, которые запускаются в системе. В большинстве случаев этим клиентам в процессе работы требуются различные графические библиотеки, например Qt или GTK+. При инсталляции программ в системах, базирующихся на RPM или Debian, вы получите информацию о том, какие библиотеки нужны им для работы. Теоретически вам нет необходимости устанавливать X-сервер на компьютере, выполняющем роль клиента, однако на практике проще сделать это, так как из-за взаимной зависимости пакетов вам все равно приходится инсталлировать большинство компонентов X Window. X-сервер представляет собой отдельную программу, обеспечивающую интерфейс с монитором, мышью, клавиатурой и другими устройствами. Наличие локального X-сервера упрощает проверку X-программ. Для того чтобы программные средства X-сервера вступили в действие, надо запустить X-программу либо локально, либо на удаленном компьютере.

Подобно другим типам серверов, сервер X Window отвечает на запросы клиентов. В большинстве дистрибутивных пакетов Linux по умолчанию не предусмотрена работа в качестве X-терминала; считается, что компьютер будет выполнять функции рабочей станции или сервера, поддерживающих другие протоколы. Поэтому, чтобы использовать компьютер под управлением Linux как X-сервер для программ, выполняющихся на других узлах сети, необходимо изменить конфигурацию системы. Сделать это можно двумя способами: с помощью программ

xhost

xauth

Программа

xhost

xterm

$ xhost +biggie.threeroomco.com

В результате ее выполнения X-сервер получает указания о том, что он должен принимать обращения от компьютера

biggie.threeroomco.com

xhost +

На заметку

Большинство X-серверов для Windows, MacOS и других систем настроены так, что с ними может взаимодействовать любой узел сети. В системе Linux подобная конфигурация задается посредством команды

xhost +

.

Программа

xhost

xhost

xauth

Программа

xauth

xauth

xhost

В процессе работы

xauth

.Xauthority

xauth

.Xauthority

xauth

xauth

.Xauthority

.Xauthority

.Xauthority

.Xauthority

.Xauthority

1. На компьютере, на котором выполняется сервер X Window, введите команду

xauth

xauth

xauth

2. Введите команду

list

.Xauthority

term.threeroomco.com:0

/unix

list

localhost

MIT-MAGIC-COOKIE-1

3. Введите команду

extract имя_файла имя_дисплея

extract xfer-auth term.threeroomco.com:0

.Xauthority

4. Введите команду

exit

xauth

5. Скопируйте файл, созданный при выполнении команды

extract

6. Зарегистрируйтесь на компьютере, выполняющем функции X-клиента.

7. Задайте команду

xauth

xauth

8. Введите команду

merge имя_файла

extract

9. Задайте команду

list

10. Введите команду

exit

xauth

xauth

quit

quit

Если на обоих компьютерах инсталлированы средства SSH, вы можете вместо описанной выше процедуры выполнить единственную команду.

# xauth list x_сервер:0 | sed -e 's/^ /add /' | ssh \

 x_клиент -х xauth

В данном случае

xauth

sed

add

xauth

• Вместо

x_сервер

x_клиент

• Между

add

/

xauth

add

• Если конфигурация SSH предполагает ввод пароля либо фразы пароля, вам придется ввести соответствующие данные.

С этого момента X-сервер будет принимать обращения от X-клиентов, но, чтобы эти программы могли работать совместно, вам придется установить на клиентском компьютере опцию, позволяющую взаимодействовать с X-сервером (этот вопрос будет подробнее рассмотрен в следующем разделе). При установлении соединения клиент X Window обратится к файлу

.Xauthorit

Поскольку работа

xauth

xhost

xauth

На заметку

Не все X-серверы сконфигурированы для работы с

xauth

. Соответствующая опция обычно устанавливается в том случае, когда X-сервер запускается посредством XDM, GDM или KDM. Если вы запускаете X-сервер с помощью

startx

, поддержка

xauth

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

startx

(он обычно располагается в каталоге

/usr/X11R6/bin

) так, чтобы в нем присутствовала опция

-auth файл_авторизации

; в качестве файла авторизации обычно указывается файл

.Xauthority

, находящийся в рабочем каталоге. Часто в редактировании

startx

нет необходимости.

Независимо от того, используете ли вы

xhost

xauth

term.threeroomco.com

biggie.threeroomco.com

wrongone.threeroomco.com

При запуске X-программа читает значение переменной окружения

DISPLAY

$ echo $DISPLAY

biggie.threeroomco.com:0.0

Если отображаемая с помощью этой команды строка (в данном случае

biggie.threeroomco.com:0.0

DISPLAY

$ export DISPLAY=term.threeroomco.com:0

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

xhost

xauth

Из материала, рассмотренного ранее в данной главе, следует, что для инициализации Х-соединения используются два отдельных, независимых друг от друга протокола. Во-первых, работая на компьютере, выполняющем роль X-сервера, вы используете клиент-программу удаленной регистрации, работающую в текстовом режиме, например программу

telnet

xclock

xclock

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

• В конфигурационном файле

/etc/ssh/ssh_config

yes

ForwardX11

ssh

-X

-х

• В файле

/etc/ssh/sshd_config

X11Forwarding

yes

При туннелировании X-соединения сервер SSH "подменяет" локальный X-сервер. Если конфигурация установлена правильно, средства поддержки SSH устанавливают переменную окружения

DISPLAY

DISPLAY

Такой подход имеет ряд преимуществ по сравнению с обычным X-обменом. Для взаимодействия двух компьютеров используется лишь одно соединение, что упрощает настройку сетевых средств. Если вы хотите спрятать X-сервер за брандмауэром или маршрутизатором, выполняющим NAT-преобразование, это проще сделать при работе посредством SSH, чем в случае, когда используется Telnet или другой протокол удаленной регистрации. Кроме того, протокол SSH предполагает кодирование передаваемых данных. Поэтому если информация будет перехвачена по пути от одного компьютера к использовать ее вряд ли удастся. Туннелирование X-соединения средствами SSH имеет один недостаток. Как известно, для кодирования информации приходится выполнять большой объем вычислений, поэтому использование SSH создает дополнительную нагрузку на процессоры компьютеров на обоих концах соединения. В результате скорость обмена X-клиента с X-сервером снижается. Замедление работы вследствие использования SSH заметно при скорости процессора около 200 МГц, однако во многих случаях повышение уровня защиты оправдывает уменьшение производительности компьютеров. Чтобы снизить требования к пропускной способности линий, можно использовать сжатие информации. С другой стороны, сжатие данных создает дополнительную нагрузку на процессор, что может еще больше уменьшить скорость обмена. Желательно испробовать обмен данными со сжатием и без сжатия и экспериментально определить, какой режим более благоприятен для компьютера и сетевых средств.

Сказанное выше предполагает, что на обоих концах соединения используются компьютеры под управлением Linux или UNIX. Если X-сервер выполняется в среде Windows, MacOS, OS/2 или в другой операционной системе, следует выяснить, поддерживает ли клиент SSH туннелирование X-соединений. Если клиент SSH предоставляет такую возможность, вам надо уметь активизировать данные средства. Подробную информацию вы получите, прочитав документацию на программы поддержки SSH.

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

1. Запуск X-сервера. Если вы используете систему Linux, средства X-регистрации могут быть предусмотрены при загрузке. Некоторые конфигурации системы предполагают запуск X-сервера по команде

startx

2. Настройка X-сервера для установления соединения. Для того чтобы X-взаимодействие могло осуществляться, необходимо сообщить серверу X Window о том, что он должен обрабатывать запросы от удаленных компьютеров на установление соединений. Это можно сделать, запуская программу

xhost

xauth

3. Установление соединения с X-клиентом. Для соединения с компьютером, на котором выполняется X-клиент, вы можете использовать любой протокол удаленного доступа, например Telnet или SSH. Заметьте, что на удаленном компьютере выполняется сервер удаленной регистрации и клиент X Window.

4. Настройка X-клиента для работы с требуемым X-сервером. Чтобы определить, какой компьютер должен использоваться в качестве X-сервера, X-клиент использует переменную окружения

DISPLAY

export DISPLAY=term.threeroomco.com:0

5. Запуск X-программы. Для того чтобы запустить X-программу, достаточно ввести ее имя в окне, посредством которого вы осуществляли удаленную регистрацию. Например, если вы регистрировались в окне

xterm

В зависимости от способа соединения и аутентификации, некоторые стадии данной процедуры, например этапы 2 и 4, могут быть пропущены. В системах Windows и MacOS ряд действий выполняется автоматически. Например, в состав некоторых X-серверов входят минимальные средства удаленной регистрации с использованием Telnet или других протоколов. Эти средства автоматически вызываются при выводе

xterm

xterm

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

Если в сети не используется брандмауэр или маскирующий маршрутизатор, способный повлиять на обмен данными между клиентом и сервером, то каждый компьютер, на котором выполняется X-сервер, может быть использован как дисплей для любого X-приложения. Однако в некоторых случаях этого недостаточно; необходимо, чтобы X-сервер работал как локальный сервер удаленной системы, отображая ее окружение. Процедура регистрации, использующая Telnet, SSH или другой протокол удаленной регистрации, не всегда удобна для управления удаленной системой. Часто бывает удобнее работать с протоколом регистрации, входящим в систему X Window. Таким протоколом является XDMCP (X Display Manager Control Protocol — протокол управления диспетчером X-отображения). В состав большинства систем Linux входит программное обеспечение, необходимое для организации работы сервера XDMCP (сервер XDMCP располагается на том же компьютере, что и X-клиент), но, как правило, эти системы сконфигурированы так, что доступ к серверу XDMCP ограничен локальной системой. Если вы измените конфигурацию сервера, он будет обслуживать различные клиенты XDMCP (они располагаются на тех же компьютерах, что и X-серверы). Компьютер под управлением Linux можно также использовать как клиент XDMCP, но для этого надо модифицировать X-конфигурацию так, чтобы средства поддержки XDMCP представляли окно регистрации, генерируемое на удаленном компьютере.

В предыдущих разделах был рассмотрен принцип использования X-соединений, предполагающий применение протокола удаленной регистрации, например Telnet. Сервер Telnet располагался на том же компьютере, что и X-клиент; с его помощью пользователь регистрировался на удаленном компьютере, после чего устанавливалось X-соединение между клиентом и сервером. Сервер XDMCP успешно заменяет Telnet, SSH и другие протоколы удаленной регистрации, обеспечивающие взаимодействие в текстовом режиме. Когда пользователь обращается к удаленной системе с помощью Telnet, сервер Telnet регистрирует его и предоставляет текстовую оболочку. Средства XDMCP действуют подобным образом, но вместо текстовой оболочки сервер XDMCP инициирует процедуру регистрации X Window; при этом отображается окно для ввода пользовательского имени и пароля и загружается диспетчер окон, среда рабочего стола и другие компоненты графического интерфейса. Эти программы запускаются посредством X-соединения; XDMCP автоматически конфигурирует клиентскую и серверную программы, используя

xauth

Сервер XDMCP применяется не только для установления X-соединений. Он также обеспечивает обращение системы Linux к X-серверу при загрузке. Отображаемое при этом окно регистрации показано на рис. 14.2. Внешний вид окна зависит от конфигурации сервера XDMCP.

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

Для настройки сервера XDMCP используются конфигурационные файлы, которые обычно находятся в каталогах

/etc

/etc/X11

XDM — наиболее простой среди серверов XDMCP; он был разработан раньше других продуктов подобного назначения. В отличие от GDM и KDM, XDM не связан с окружением рабочего стола Linux. Он дает возможность пользователям вводить имена и пароли, но не позволяет указывать дополнительные сведения, например задавать диспетчер окон. Для управления регистрационными параметрами пользователя служит файл

.xsession

Xsession

/etc/X11

/etc/X11/xdm

.xsession

Доступом удаленных компьютеров XDM управляет основной конфигурационный файл

/etc/X11/xdm/xdm-config

DisplayManager.requestPort: 0

Данная запись указывает XDM на то, что он не должен принимать обращения через UDP-порт 177. Если вы хотите, чтобы пользователи с других компьютеров могли регистрироваться посредством XDMCP, вам надо закомментировать данную строку (включить в ее начало символ

#

Помимо редактирования файла

xdm-config

/etc/X11/xdm/Xaccess

#

CHOOSER

BROADCAST

CHOOSER

*

*

* CHOOSER BROADCAST

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

*

threeroomco.com

*.threeroomco.com

bronto.pangaea.edu

stego.pangaea.edu

bronto.pangaea.edu CHOOSER BROADCAST

stego.pangaea.edu CHOOSER BROADCAST

На заметку

Ограничить доступ к XDMCP можно не только средствами, предусмотренными в конфигурационном файле XDM. Блокировать обращения к серверу может также брандмауэр.

В файле

/etc/X11/xdm/xservers

:0 local /usr/X11R6/bin/X

Данная запись указывает на то, что сервер должен управлять локальным дисплеем (:0). При необходимости XDM запускает локальный X-сервер. Если вы хотите, чтобы XDM непосредственно управлял отображением на удаленных машинах, без использования окна регистрации, вы должны указать требуемые системы следующим образом:

term.threeroomco.com:0 foreign

В этом примере

foreign

Xservers

local

На заметку

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

Сервер был разработан для замены существующего XDM. По сравнению со своим предшественником, KDM предоставляет дополнительные возможности, наиболее важными из которых являются список Session Type, в котором пользователи могут выбирать диспетчер окон или среду рабочего стола, и кнопка Quit (или Shutdown), позволяющая завершать выполнение локального X-сервера (при удаленном выполнении) или останавливать работу всей системы (при локальном запуске). Окно регистрации, отображаемое посредством KDM, показано на рис. 14.2.

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

kdmrc

/opt/kde2/share/config

/usr/share/config

SessionTypes

Xsession

Xsession.d

/etc/X11

/etc/X11/xdm

SESSION

chksession

.xsession

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

/etc/X11/gdm

gdm.conf

Как и большинство систем, использующих серверы XDMCP, системы, включающие GDM, конфигурируются так, чтобы пользователи не могли регистрироваться с удаленных узлов. Чтобы отказаться от этого ограничения, надо изменить одну или две записи в разделе

[xdmcp]

gdm.conf

Enable=0

Enable=1

HonorIndirect=0

HonorIndirect=1

Если вы хотите, чтобы GDM был доступен для удаленных узлов, а локальный X-сервер не запускался, вам надо закомментировать строку, соответствующую локальным серверам в разделе

[servers]

0=/usr/bin/X11/X

Эта запись указывает GDM на то, что X-сервер (программа

/usr/bin/X11/X

Подобно KDM, GDM позволяет пользователю выбрать диспетчер окон или окружение рабочего стола. (В GDM для этого предназначено меню Session.) Для добавления или удаления сеансов надо создать соответствующие сценарии в каталоге

/etc/X11/gdm/Sessions

/etc/X11/xdm/Xsession

Чтобы обеспечить запуск сервера XDMCP, надо настроить компьютер для работы с X Window и приема запросов на регистрацию. В большинстве дистрибутивных версий для этой цели зарезервирован уровень выполнения 5, но в некоторых случаях используются и другие уровни. Например, в версиях SuSE, предшествующих версии 7.2, регистрация с применением графического интерфейса производится на уровне 3, а в Slackware для этого используется уровень 4. В Debian и системах, созданных на ее основе, средства X Window выполняются на всех уровнях, допускающих работу нескольких пользователей.

Уровень по умолчанию задается с помощью специальной записи в файле

/etc/inittab

id:5:initdefault:

Во многих дистрибутивных пакетах данной записи предшествуют комментарии, объясняющие ее назначение. Номер уровня содержится во втором поле; именно на этот уровень система переходит после загрузки. Если на компьютере установлены средства X Window, сервер XDCMP также будет загружен.

Для изменения уровня выполнения служит утилита

telinit

telinit 5

telinit

Совет

Если вы вносите изменения в конфигурацию сервера XDMCP, вам надо обеспечить, чтобы новая конфигурация была учтена при работе сервера. Сделать это вы можете, перейдя на уровень, обеспечивающий работу только в текстовом режиме, а затем вернувшись на уровень, допускающий выполнение X-программ. Для перехода на другой уровень используется утилита

telinit

. Кроме того, вы можете остановить работу сервера XDMCP, вызвав команду

kill

или

killall

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

SIGHUP

; в этом случае завершать работу сервера нет необходимости.

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

• 

prefdm

prefdm

/etc/X11

/etc/sysconfig/desktop

KDE

GNOME

AnotherLevel

• Сценарии запуска SysV. В Debian и системах, созданных на ее основе, запуск сервера XDMCP осуществляется посредством сценария SysV, например

/etc/init.d/xdm

DISPLAYMANAGER

/etc/rc.config

• Прочие сценарии запуска. Для запуска сервера XDMCP в системе Slackware применяется сценарий

/etc/rc.d/rc.4

rc.4

xdm

/etc/rc.d/rс.gui

Подобно другим серверам, XDMCP-сервер сам по себе абсолютно бесполезен; его использование имеет смысл только тогда, когда он взаимодействует с одним или несколькими клиентами. Как правило, клиенты XDMCP встраиваются в состав X-серверов. Клиент XDMCP может либо непосредственно взаимодействовать с сервером XDMCP, либо предоставлять список доступных X-серверов. (X-сервер для Windows, отображающий список компьютеров, показан на рис. 14.3.) Если вы выберете компьютер и щелкнете на кнопке Connect (или активизируете другой интерактивный элемент аналогичного назначения), вы увидите окно регистрации, представленное на рис. 14.2. После окончания регистрации X-сервер отобразит рабочий стол компьютера. В зависимости от конфигурации X-сервера, изображение рабочего стола либо займет весь экран либо будет выведено в отдельном окне.

Рис. 14.3. Выбрав сервер XDMCP из списка, вы можете запустить X-программу на этом компьютере

Большинство X-серверов, предназначенных для работы в системе Windows или MacOS, предоставляют диалоговое окно, которое позволяет задать особенности выполнения операций XDMCP. Диалоговое окно, предоставляемое одним из X-серверов, выполняющихся в системе Windows, показано на рис. 14.4. Основными элементами являются переключатели опций, расположенные в верхней части окна. С их помощью задается способ, которым клиент XDMCP, встроенный в X-сервер, устанавливает соединение с сервером XDMCP. В различных программах имена опций могут различаться. Назначение этих опций описано ниже.

Рис. 14.4. Большинство клиентов XDMCP позволяют выбирать способ взаимодействия с серверами XDMCP

• Do Not Use XDM (Passive). Данная опция предполагает, что соединение с X-сервером устанавливается вручную с использованием Telnet или другого инструмента регистрации либо что сервер XDMCP настроен для управления отображением на X-сервере (это можно сделать с помощью записи

foreign

/etc/X11/xdm/Xservers

• XDM Query. Если задана эта опция, X-сервер передает запрос на регистрацию тому узлу, имя или IP-адрес которого вы зададите. Если на указанном компьютере выполняется сервер XDMCP, будет выведено окно регистрации, подобное изображенному на рис. 14.2. Используя данную опцию, вы не можете непосредственно регистрироваться на другом компьютере. XDM Query заставляет X-сервер при каждом запуске передавать запрос серверу XDMCP. Такое поведение более приемлемо для пользователя, чем ситуация, когда сервер XDMCP управляет X-сервером.

• XDM Broadcast. Данную опцию лучше всего задавать, когда в локальной сети выполняется несколько X-серверов. В этом случае X-сервер передает широковещательный запрос по сети, определяет расположение всех серверов XDMCP и выводит их список, как показано на рис. 14.3. Некоторые серверы позволяют ограничить широковещательный запрос определенными адресами (для этого предназначена кнопка Register Hosts to Search, показанная на рис. 14.4).

• XDM Indirect. Данную опцию удобно применять, если вы хотите, чтобы пользователи могли регистрироваться на одном из нескольких компьютеров, принадлежащих внешней сети. Введите имя или IP-адрес сервера XDMCP в сети; в результате X-сервер обратится к этой системе для получения списка серверов. В данном случае сервер XDMCP должен быть сконфигурирован для обработки косвенных запросов.

Способностью отображать список доступных серверов XDMCP обладают не только X-серверы, предназначенные для выполнения в системе Windows. To же самое может делать XFree86, предназначенный для Linux. Режим работы данного продукта определяется опциями, задаваемыми при его запуске. Вы можете указывать опции

-query имя_узла

-broadcast

-indirect

$ /usr/X11R6/bin/X -indirect xdmcp-server.threeroomco.com

Приведенные выше опции действуют так же, как и опции X-сервера для Windows, за одним исключением. Опция

-broadcast

Совет

При желании вы можете сконфигурировать компьютер под управлением Linux как выделенный X-терминал. Конфигурацию следует задать так, чтобы X-сервер не запускался автоматически посредством сервера XDMCP. Затем следует создать сценарий запуска, который вызывал бы X-сервер с указанием требуемой опции:

-query

,

-broadcast

или

-indirect

. Если вы хотите отобразить список доступных локальных серверов, вам надо сконфигурировать один из серверов XDMCP так, чтобы он обрабатывал косвенные запросы, и указать при запуске X-сервера опцию

-indirect

. Таким образом, можно реализовать X-терминал даже посредством компьютера с процессором 386.

Средства X Window очень часто применяются для создания графической среды в системе Linux. Поскольку система X Window непосредственно разрабатывалась для работы в сети, ее очень удобно использовать в качестве инструмента удаленной регистрации. Однако X Window — не единственный инструмент, предоставляющий графический интерфейс для взаимодействия с удаленным компьютером. Эту задачу решают также средства VNC. Сетевая модель VNC отличается от X Window, и ей присущи свои преимущества и недостатки. Процедура инсталляции и настройки сервера VNC отличается от установки и выбора конфигурации X-сервера. Клиенты этих систем также различаются между собой.

Излагая материал данной главы, я пытался обратить внимание на роль различных клиентских и серверных программ в процессе сетевого взаимодействия. Как вы уже знаете, один и тот же компьютер может действовать как сервер по одному протоколу и выполнять функции клиента по другому протоколу. Рассматривая VNC, понять принцип взаимодействия программ несколько проще, так как в этом случае компьютер, за которым работает пользователь, является клиентом VNC, а удаленный компьютер — сервером VNC.

Если вы вспомните недавнее обсуждение принципов работы X Window, вам, наверное, покажется странным, как клиент VNC может обеспечивать работу пользовательского компьютера. Если X-сервер управляет клавиатурой, мышью и дисплеем, то как пользователь, не работающий за X-сервером, может выполнять X-программы? Дело в том, что VNC предполагает дополнительный уровень сетевого взаимодействия, скрытый от пользователя. На узле сети, выполняющем роль сервера VNC, присутствует X-клиент, который взаимодействует с X-сервером локального компьютера. X-сервер обменивается данными с сервером VNC так, как будто X-сервер работает с реальными устройствами ввода-вывода, однако вместо локальной клавиатуры, мыши и дисплея сервер VNC взаимодействует по сети с удаленным клиентом VNC, который поддерживает обмен с устройствами ввода-вывода. На рис. 14.5 показано, как работают компоненты сервера VNC. Для сравнения на этом же рисунке изображено взаимодействие X-клиента и X-сервера, работающих на отдельном компьютере и в сети.

Рис. 14.5. Сервер VNC взаимодействует с локальным X-сервером и удаленным клиентом VNC. Клиент, в свою очередь, взаимодействует с X-сервером и поддерживает обмен данными с клавиатурой, мышью и дисплеем

X-сервер, работающий совместно с сервером VNC, поддерживает свое текущее состояние даже в том случае, когда VNC-соединение разрывается. Например, если в работе сервера VNC возникнет сбой или если пользователь закроет клиент-программу, не завершив сеанс, сервер VNC продолжит свою работу, и когда пользователь возобновит соединение, приложения, работающие с сервером VNC, останутся открытыми. Такая возможность во многих случаях упрощает работу, например, она может быть очень полезна тогда, когда сеть функционирует ненадежно. Однако не стоит пользоваться ею без необходимости. Если вы надолго прервете сеанс взаимодействия, в работе сервера VNC может возникнуть ошибка; не исключено также, что соединением воспользуется злоумышленник, пытающийся получить доступ к важной информации. (Заметьте, что текущее состояние не поддерживается, когда средства VNC работают совместно с XDMCP.)

VNC обеспечивает уровень защиты выше, чем в Telnet, но ниже, чем XDMCP при X-взаимодействии посредством SSH. VNC кодирует пароль, но остальные данные передаются в незашифрованном виде. Таким образом, при использовании VNC существует опасность перехвата данных, особенно если соединение устанавливается через Internet.

Средства X Window разрабатывались специально для работы в сети. При обмене X-клиента с X-сервером информация пересылается в виде символьных строк; битовые карты формируются на том компьютере, на котором осуществляется вывод на дисплей. При работе X Window по сети часто передаются небольшие фрагменты данных. В отличие от X Window, средства VNC ориентированы на работу с битовыми картами. При работе сервер VNC поддерживает сравнительно небольшое число транзакций, но в рамках каждой транзакции передается значительный объем данных. Это означает, что в некоторых сетях и для некоторых приложений VNC будет работать медленнее обычного X-соединения. Например, если вы работаете с текстовым редактором, он передает X-серверу отдельные символы или слова, получив которые X-сервер генерирует битовую карту на локальной машине. Если же взаимодействие с редактором будет осуществляться посредством VNC, по сети будут передаваться битовые карты, объем которых значительно превышает объем самого подробного описания текста. Различия в скорости работы незначительны в быстродействующих сетях, но становятся все более заметными при уменьшении пропускной способности линий. Способ обмена между компьютерами практически не имеет значения при работе с графическими программами, генерирующими растровые изображения. VNC может работать быстрее на линиях с большой задержкой, например при связи через спутник; в этом случае частые обмены информацией, типичные для системы X Window, являются недостатком и замедляют взаимодействие. Если скорость обмена, обеспечиваемая клиентом и сервером VNC, не устраивает вас, вы можете использовать модифицированный вариант VNC, в котором используется кодирование данных, например Tight VNC (

http://www.tightvnc.com

http://www.developvnc.org

Одно из преимуществ VNC перед X Window состоит в том, что VNC можно использовать для управления системами Windows и MacOS. Сервер VNC получает контроль над устройствами ввода-вывода и передает информацию клиенту VNC. Функционирование серверов VNC для Windows и MacOS здесь описываться не будет, достаточно лишь сказать, что они работают подобно серверу VNC в Linux, но предоставляют ограниченные возможности, а настройка их осуществляется с помощью диалоговых окон. Обращение к серверу VNC, работающему в среде Windows или MacOS, выполняется так же, как и обращение к серверу VNC в Linux. Поскольку в системе Windows или MacOS сервер VNC перехватывает управление экраном, в каждый момент времени работать с компьютером может только один пользователь.

Программу, реализующую сервер VNC, можно получить с Web-узла VNC

http://www.uk.research.att.com/vnc/

vnc

vncserver

vnc

Если VNC входит в состав вашей версии Linux либо если вы имеете в своем распоряжении архив, содержащий двоичные файлы, инсталляция VNC сводится к выполнению следующих действий (предполагается, что вы инсталлируете версию 3.3.3r3 VNC).

1. Распакуйте архив, вызвав команду

tar xvfz vnc-3.3.3r2_x86_linux_2.0.tgz

vnc_x86_linux_2.0

2. Скопируйте файлы

vncviewer

vncserver

vncpasswd

vncconnect

Xvnc

PATH

vnc_x86_linux_2.0

/opt

PATH

3. Создайте в рабочем каталоге пользователя, который должен работать с VNC, подкаталог с именем

.vnc