Сетевые средства Linux

Смит Родерик В.

ЧАСТЬ II

Серверы в локальных сетях

 

 

Глава 5

Распределение IP-адресов с помощью DHCP

 

В главе 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. Такая программа нужна, только если в сети имеется сервер 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 переводит существенную часть ресурсов небольшой сети в категорию накладных расходов. Работоспособность сети в случае выхода сервера DHCP из строя можно повысить, увеличивая время аренды. В этом случае работающие клиенты реже пытаются обращаться к неработающему серверу DHCP.

Сервер 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. В результате ее выполнения будут выведены все записи, содержащиеся в таблице маршрутизации. Если маршрут 255.255.255.255 содержится в таблице, он должен находиться в начале списка.

 

Конфигурационные файлы DHCP

Большинство дистрибутивных пакетов Linux содержит сервер DHCP, разработанный Internet Software Consortium (http://www.isc.org/products/DHCP/). Internet Software Consortium (ISC) в конце 2000 г. выпустил версию 3.0 DHCP, но в начале 2002 г. многие версии Linux все еще поставлялись со старой версией 2.0 сервера DHCP. Большинство параметров настройки, рассматриваемых в данном разделе, применимо к версиям 2.0 и 3.0, но версия 3.0 поддерживает некоторые новые возможности, например, средства интеграции с DNS-сервером, которые будут обсуждаться далее в этой главе.

Для настройки сервера DHCP используется конфигурационный файл dhcpd.conf, который обычно располагается в каталоге /etc или /etc/dhdcp. Подобно остальным конфигурационным файлам Linux, dhcpd.conf — это текстовый файл, для редактирования которого можно использовать обычный текстовый редактор. Кроме того, во время работы программа dhcpd создает собственный файл состояния dhcp.leases, который обычно помещается в каталог /var/lib/dhcp. В файле dhcp.leases содержится информация об аренде адресов. В системе DHCP распределением IP-адресов занимается сервер DHCP. Он сообщает клиенту DHCP, что тому на определенный период времени выделяется некоторый IP-адрес. Другими словами, адрес дается клиенту в аренду, а клиент должен вовремя продлевать ее. В файле dhcp.leases также содержатся сведения об Ethernet-адресах клиентов. Файл dhcp.leases не является конфигурационным файлом в полном смысле слова; его нельзя редактировать, но при возникновении проблем или в случае, если вам потребуется выяснить аппаратный адрес, или MAC-адрес, клиента, вы можете просмотреть содержимое 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 игнорирует лишние пробелы за исключением тех случаев, когда они указаны в кавычках.

 

Динамическое распределение IP-адресов

 

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

 

Установка глобальных параметров

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

Листинг 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-time и max-lease-time) задают длительность аренды в секундах. Подобно тому, как домовладелец и наниматель договариваются о сроках аренды квартиры, клиент DHCP и сервер договариваются о времени, в течение которого клиент может пользоваться IP-адресом. Параметр default-lease-time определяет время аренды, наиболее приемлемое для сервера DHCP. В приведенном выше примере его значение составляет 7200 секунд, или 120 минут. Если клиент запросит более длительную аренду, сервер будет исходить из значения max-lease-time; в данном случае оно равно 10800 секундам, или 180 минутам. При создании реального конфигурационного файла вы можете увеличивать или уменьшать приведенные здесь значения в зависимости от собственных потребностей. Малая длительность аренды снижает работоспособность сети при выходе сервера DHCP из строя и увеличивает нагрузку на сеть. Слишком большая длительность аренды опасна тем, что имеющиеся в наличии IP-адреса будут исчерпаны. Подобная ситуация возможна, если компьютеры будут часто включаться на короткое время; при этом сервер DHCP будет хранить информацию об аренде адресов, которые на самом деле не используются. Для тестирования сервера DHCP целесообразно устанавливать малое время аренды, например 60 секунд; в этом случае вы сможете следить за результатами изменения конфигурации сервера. Если структура сети претерпевает постоянные изменения (например, портативные компьютеры часто подключаются к сети и отключаются от нее), лучше всего подходят значения, близкие к указанным в листинге 5.1. Если же основную часть сети составляют компьютеры, которые не выключаются в течение нескольких дней, то значения параметров default-lease-time и max-lease-time могут быть порядка сотен тысяч секунд.

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

• filename " имя_файла " . Сервер dhcpd может выполнять функции сервера загрузки для узлов сети. Настроенный подобным образом, сервер DHCP должен предоставлять клиенту сведения о расположении исходного файла загрузки; такая информация задается с помощью параметра filename. После этого клиент может скопировать содержимое данного файла с помощью соответствующего протокола.

• next-server " имя_узла " . Этот параметр задает имя компьютера, на котором расположен исходный файл загрузки, заданный с помощью параметра filename. Если данный параметр не указан, то по умолчанию считается, что файл находится на том же компьютере, что и сервер DHCP.

• server-name " имя_узла " . Этот параметр также управляет загрузкой по сети. Он используется для того, чтобы сообщать клиенту имя сервера, на котором расположены файлы, необходимые для загрузки.

• boot-unknown-clients флаг . Как правило, значение данного флага устанавливается равным true, в результате чего dhcpd предоставляет IP-адрес любому компьютеру, который передал запрос. Если значение флага равно false, сервер обслуживает только те компьютеры, для которых в составе конфигурационного файла содержится декларация host.

• option broadcast-address IP-адрес . Если в вашей сети используется нестандартный широковещательный адрес, его можно задать с помощью данного параметра. Обычно клиенты самостоятельно определяют нужный адрес.

• get-lease-hostnames флаг . Если значение флага установлено равным true, dhcpd обращается к серверу DNS, определяет доменное имя и передает его клиенту вместе с IP-адресом. Это позволяет запускать на клиентских компьютерах программы, использующие доменные имена при взаимодействии по сети (например, почтовые серверы). По умолчанию для данного параметра устанавливается значение false.

• use-host-decl-names флаг . Этот параметр почти эквивалентен параметру get-lease-hostnames. Если его значение равно true, dhcpd не обращается к серверу DNS, а передает клиенту доменное имя, заданное в декларации host. По умолчанию принимается значение true.

На заметку

Параметры get-lease-hostnames и use-host-decl-names определяют, должен ли сервер DHCP предоставлять клиентам доменные имена. Несмотря на то что при использовании get-lease-hostnames dhcpd обращается к серверу DNS для получения доменного имени, ни один из этих двух параметров не влияет на работу сервера DNS. Если вы хотите, чтобы при обращении к клиенту DHCP посредством доменного имени обеспечивалась достаточная надежность, вам надо сконфигурировать сервер DHCP так, чтобы он выделял компьютеру фиксированный IP-адрес, или принять меры для организации совместной работы серверов DHCP и DNS.

В файле dhcpd.conf могут присутствовать и другие параметры, многие из которых начинаются с ключевого слова option. Некоторые параметры указывают расположение различных серверов, например, серверов шрифтов X Window, серверов службы времени и серверов печати. Другие задают характеристики сетевых интерфейсов клиента, например, определяют, может ли клиент выполнять перенаправление IP-пакетов. Подробное описание этих параметров вы найдете на страницах справочной системы, посвященных структуре файла dhpcd.conf. Для использования многих параметров на клиентской машине необходимо установить дополнительные программные средства; например, стандартный клиент DHCP не поддерживает работу с серверами шрифтов X Window.

В большинстве случаев параметры указываются в начале файла 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, предшествующими 3.0, необходимо включать декларацию subnet для каждого интерфейса, независимо от того, обслуживается ли соответствующая сеть сервером DHCP. Например, если два сетевых интерфейса компьютера подключены к сетям 192.168.1.0/24 и 172.20.30.0/24, но сервер DHCP обслуживает только сеть 192.168.1.0/24, в файле 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, не приходится выяснять, какой именно адрес присвоен в данный момент тому или иному компьютеру. При наличии фиксированных IP-адресов появляется также возможность вместо адреса указывать при обращении к компьютеру доменное имя. (Далее в этой главе будет обсуждаться способ связывания доменных имен с динамическими IP-адресами.) Программа dhcpd позволяет присваивать компьютерам фиксированные IP-адреса. Для этого надо задать MAC-адреса и сконфигурировать dhcpd так, чтобы MAC-адресу соответствовал определенный IP-адрес. Конфигурация dhcpd для выделения фиксированных адресов несколько сложнее, чем конфигурация, при которой выполняется динамическое распределение IP-адресов.

 

Определение MAC-адреса клиента

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

На заметку

Первые три байта MAC-адреса Ethernet содержат код производителя сетевой карты; остальные три байта устанавливает предприятие, выпускающее Ethernet-карты. Информацию о кодах производителей можно найти по адресу http://www.coffer.com/mac_find/ или http://www.cavebear.com/CaveBear/Ethernet/vendor.html . Для настройки DHCP эти сведения не требуются, но вы можете воспользоваться ими, выясняя расположение компьютеров по широковещательным запросам клиентов DHCP. Заметьте, что производитель Ethernet-карты и производитель компьютера — это, как правило, разные компании.

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

Определение MAC-адреса с клиентской машины

При работе с Linux и другими подобными UNIX системами MAC-адрес можно определить с помощью команды ifconfig. Задайте команду ifconfig eth0 (или укажите при вызове ifconfig другое имя), и утилита ifconfig выведет информацию об указанном сетевом интерфейсе. Отображаемые данные будут выглядеть приблизительно следующим образом:

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

MAC-адрес следует за ключевым словом HWaddr; в данном случае это значение 00:80:C6:F9:3B:BA. Нужная информация будет получена только в том случае, если драйвер Ethernet загружен и интерфейс активен. При этом не имеет значения, связан ли интерфейс со стеком протоколов TCP/IP.

Используя Windows 2000, вы можете выяснить MAC-адрес посредством программы IPCONFIG, которая работает подобно утилите ifconfig системы Linux. Для получения исчерпывающей информации о сетевых интерфейсах, имеющихся в системе, надо задать команду IPCONFIG /ALL. В составе отображаемых данных будет содержаться следующая строка:

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

В Windows Me используется программа WINIPCFG, выполняющая те же функции, что и IPCONFIG, и предоставляющая графический пользовательский интерфейс. При запуске программы выводится окно, представленное на рис. 5.1, в котором MAC-адрес отображается в поле Adapter Address.

Рис. 5.1. WINIPCFG предоставляет информацию о сетевых интерфейсах и позволяет управлять клиентом DHCP в системе Windows 9х/Me

Если клиент 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-адреса с сервера

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-адреса, вы должны знать, какой IP-адрес выделен клиенту. Это можно определить по времени аренды либо обратиться за этими сведениями на клиентскую машину.

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, отличные от 1.

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

# 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

 

Описание узлов с помощью MAC-адресов

Для того чтобы программа dhcpd анализировала MAC-адреса клиентов и предоставляла им фиксированные IP-адреса, надо сначала реализовать динамическое распределение адресов. Вы можете использовать в качестве шаблона код, представленный в листинге 5.1, а затем модифицировать его, например, изменить адреса сервера DNS и шлюзов либо добавить глобальные параметры. Затем необходимо добавить для каждого клиента, которому необходимо выделять фиксированный IP-адрес, декларацию 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) задает тип сетевого интерфейса и MAC-адрес, к которому должна применяться эта декларация. В данном примере содержится запись для Ethernet-карты, а при работе в сети иного типа надо задать другой тип сетевого устройства; например, для сети Token Ring следует указать ключевое слово token-ring. Второй параметр (fixed-address) определяет IP-адрес, выделяемый клиенту. Следите за тем, чтобы этот адрес принадлежал сети, которую обслуживает сервер DHCP, и лежал за пределами диапазона, определенного с помощью параметра range, заданного в декларации subnet. В данном примере указан адрес 192.168.1.2, который не относится к диапазону 192.168.1.50-192.168.1.150, указанному в листинге 5.1, но принадлежит сети 192.168.1.0/24, указанной там же.

В файле dhcpd.conf можно определять любое число клиентов, которым должны выделяться фиксированные IP-адреса. Можно также сформировать конфигурационный файл так, что для одних компьютеров сервер DHCP будет выделять фиксированные адреса, а для других — распределять адреса динамически. Если в файле dhcpd.conf содержится и выражение range, и одна или несколько деклараций host, то компьютеры, MAC-адреса которых явно не указаны в декларациях host, будут получать адреса из диапазона, заданного с помощью декларации subnet.

 

Параметры для отдельных клиентов

Как было сказано ранее, в декларации, состоящей из нескольких строк, могут указываться параметры; они применимы только к текущей декларации. Параметрами являются выражения hardware и fixed-address в декларации host. Для конкретных компьютеров можно задать и другие параметры, в частности, в декларации можно указывать глобальные опции, которые были рассмотрены выше в данной главе. Часто для отдельных компьютеров указывают параметр option host-name " имя " ; в результате сервер DHCP будет передавать имя клиенту. В некоторых случаях этот параметр используется вместо 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), определяются при обращении к серверу DNS. Вторым двум клиентам (hindmost и louiswu) присваиваются имена, указанные в декларации host. Путем группировки декларации можно также решать другие задачи, например, использовать разные файлы загрузки для различных компьютеров (при этом указываются параметры filename и next-server) либо задавать для некоторых узлов сети специальные установки TCP/IP (таким образом можно повысить производительность отдельных компьютеров за счет снижения эффективности работы остальной части сети).

 

Интеграция с другими серверами

 

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

 

Включение информации NetBIOS

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

• option netbios-name-servers адреса_серверов . Традиционно NetBIOS применяет систему преобразования имен, которая не имеет ничего общего с системой, с которой работает большинство TCP/IP-клиентов. Компьютеры NetBIOS могут использовать широковещательную модель, согласно которой они передают широковещательные сообщения по локальной сети, либо применять в работе систему преобразования имен, отличную от DNS. Независимые серверы имен называются NBNS (NetBIOS Name Service — служба имен NetBIOS) или WINS (Windows Internet Name Service — межсетевая служба имен Windows). Для того чтобы сервер DHCP сообщал Windows-клиентам адреса серверов, в его конфигурационном файле используются параметры option netbios-name-servers. Обычно в файле dhcpd.conf указывается один подобный сервер, но система DHCP может предоставлять адреса нескольких серверов WINS.

• option netbios-node-type код_типа . Этот параметр используется с параметром, рассмотренным выше. Он сообщает клиенту, должен ли тот реализовывать широковещательный принцип преобразования адресов или обращаться к серверу WINS. Код типа — это числовое значение в диапазоне от 1 до 8. Значения 1 и 2 сообщают соответственно об использовании широковещательного преобразования имен и сервера WINS. Значения 4 и 8 позволяют применять оба способа: 4 означает, что клиент должен сначала предпринять попытку широковещательного преобразования, а в случае неудачи обращаться к серверу WINS, a 8 указывает на то, что в первую очередь клиент должен обратиться к серверу WINS, а лишь потом использовать широковещательное преобразование. В большинстве сетей, содержащих сервер WINS, указывается значение 8, поскольку при этом снижается трафик сети и в то же время обеспечивается достаточная надежность. Если этот сервер оказывается неисправным или не содержит данные для конкретного компьютера, преобразование все же выполняется.

• option netbios-dd-server адрес_сервера . Данный параметр связан с решением самых сложных вопросов обеспечения работы NetBIOS: он задает адрес сервера NBDD (NetBIOS Datagram Distribution — распространение дейтаграмм NetBIOS). Этот сервер передает широковещательный трафик клиентам, которые в обычных условиях не получали бы эти данные. Вероятнее всего, вам не придется использовать этот параметр.

• option netbios-scope строка . Данный параметр определяет область видимости NetBIOS — группу компьютеров, которым известно заданное имя NetBIOS. В большинстве случаев в системе NetBIOS область видимости остается неизменной, в результате любой NetBIOS-компьютер сети может распознавать имена остальных компьютеров. Если в сети устанавливается область видимости, вам придется использовать этот параметр. (При необходимости его можно включить в состав декларации 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

 

Взаимодействие с DNS-сервером

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

В версиях dhcpd, предшествующих версии 3.0, отсутствовали средства для поддержки взаимодействия с сервером В версии 3 были реализованы два способа обновления записей DNS: ad-hoc (метод, ориентированный на конкретный узел) и interim (промежуточный метод). Существуют также другие способы; после принятия их в качестве Internet-стандарта они будут реализованы в последующих версиях dhcpd.

На заметку

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

Для организации взаимодействия с сервером DNS используется параметр ddns-update-style, который может принимать одно из трех значений: ad-hoc, interim и none (последнее значение принимается по умолчанию). Чтобы разрешить динамическое обновления DNS, надо включить параметр ddns-update-style в качестве глобального в начало файла dhcpd.conf и присвоить ему либо значение ad-hoc, либо interim (попытки задать данный параметр для отдельных клиентов не дадут ожидаемого результата).

Внимание

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

Метод обновления ad-hoc

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

1. Если в декларации host содержится параметр ddns-hostname, используется значение этого параметра.

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

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

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

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

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

Метод обновления interim

Метод interim во многом похож на метод ad-hoc, но он предоставляет возможность клиенту обновить запись А сервера DNS. Чтобы разрешить или запретить клиенту самостоятельно выполнять действия по обновлению записей сервера DNS, в файл 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. При использовании метода ad-hoc клиент получает имя, принадлежащее threeroomco.com, даже если в его запросе был указан другой домен. Если же клиент имеет право изменять записи сервера DNS, он может задать любое имя, например dino.pangaea.edu. После обновления записи А по этому имени можно обращаться к клиенту. Если сервер DHCP корректно взаимодействует с сервером DNS, при создании записи 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.

 

Глава 6

Аутентификация средствами Kerberos

 

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

На заметку

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

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

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

 

Использование системы Kerberos

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

 

Взаимодействие компонентов Kerberos

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

Сетевые компоненты Kerberos

Основным компонентом системы Kerberos является KDC. Он отвечает за аутентификацию компьютеров в области (realm) Kerberos. Обычно область Kerberos совпадает с некоторым доменом или поддоменом Internet. Например, домен threeroomco.com может содержать единственную область Kerberos; в этом случае область скорее всего будет иметь имя THREEROOMCO.COM. В отличие от имен доменов Internet, имена областей Kerberos чувствительны к регистру символов. Для того чтобы подчеркнуть различия между доменом Internet и областью Kerberos, которая определяет тот же набор компьютеров, принято задавать имена областей символами верхнего регистра. Область Kerberos может занимать не весь домен либо включать компьютеры из нескольких доменов. Если в одном домене находятся две или более области Kerberos, то для их идентификации в начало имени области добавляются дополнительные компоненты, например REALM1.THREEROOMCO.COM и REALM1.THREEROOMCO.СОМ.

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

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

Kerberos предоставляет билеты принципалам, в роли которых выступают пользователи либо серверные программы. Для описания принципала применяется идентификатор, состоящий из трех компонентов: основы (primary), экземпляра (instance) и области (realm). Этот идентификатор записывается в формате основа / экземпляр @ область . Если билет получает пользователь, основа представляет собой пользовательское имя. В роли принципала может также выступать сервер; в этом случае основой является имя сервера, например ftp. Экземпляр — не обязательный компонент, он применяется в тех случаях, когда одна и та же основа используется в различных целях. Предположим, что пользователю fluffy поставлены в соответствие два принципала: один, используемый для решения обычных задач, и второй, предназначенный для выполнения действий по администрированию системы. Для идентификации второго принципала может быть использован экземпляр admin. Если область имеет имя THREEROOMCO.COM, то идентификаторы принципалов будут иметь вид [email protected] и fluffy/admin@THREEROOMCO.СОМ.

Задачи, выполняемые Kerberos

Для того чтобы понять работу средств 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

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

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

 

Версии и разновидности Kerberos

Наибольшей популярностью пользуется пакет Kerberos, доступный по адресу http://web.mit.edu/kerberоs/www/. На узле MIT размещены исходные тексты Kerberos V5 Release 1.2.1 и двоичные коды, подготовленные для различных операционных систем (версия для Linux отсутствует). Здесь же можно найти Kerberos V4 и версию данной системы для Windows и MacOS (как для MacOS Classic, так и для MacOS X). В версии Kerberos V5 реализованы новые возможности по сравнению с Kerberos V4, кроме того, в последних реализациях устранены недостатки, имевшие место в предыдущих версиях.

Подобно X Window, Kerberos распространяется в исходных кодах. Кроме того, существуют варианты системы, созданные на основе кода MIT, которые предоставляются на коммерческой основе. Одна из разновидностей Kerberos создана в Швеции Королевским технологическим институтом (Royal Institute of Technology) и доступна по адресу http://www.pdc.kth.se/kth-krb/. Этот вариант системы называется eBones, но имена файлов, входящих в состав пакета, начинаются с krb4. Официально посредством данного узла распространяются только исходные коды, но на FTP-сервере можно найти каталог binaries, в котором расположены двоичные пакеты, включая пакет для Linux. Если вы решите скопировать его, будьте внимательны: это может оказаться старая реализация системы. Система eBones (по крайней мере, eBones 1.1) базируется на Kerberos V4.

Центр параллельных вычислений (Center for Parallel Computers) реализовал систему Kerberos, известную под названием Heimdal; ее коды расположены по адресу http://www.pdc.kth.se/heimdal/. Эта разновидность системы базируется на MIT Kerberos V5. На указанном сервере находятся как исходные тесты, так и исполняемые коды для Linux, но часто двоичные коды новой версии появляются на сервере гораздо позже исходных текстов.

В настоящее время средства поддержки 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 является сервер Kerberos, или KDC. Как и для большинства серверов Linux, для настройки KDC используется текстовый файл, находящийся в каталоге /etc. Зная формат этого файла, вы можете устанавливать конфигурацию сервера Kerberos и, следовательно, воздействовать на работу других сетевых систем. В данном разделе приводятся основные сведения о конфигурации сервера. В последующих разделах обсуждается конфигурация клиентов и серверов приложений.

На заметку

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

Очевидно, что пакет Kerberos должен быть установлен на компьютере, предназначенном для размещения KDC. Для компиляции исходных кодов MIT и установки полученных программ надо вызвать сценарий configure, содержащийся в составе пакета, а затем вызвать команды make и make install. В результате этих действий будут инсталлированы сервер Kerberos, серверы приложений и клиенты. При выполнении сценария configure желательно задавать опцию --enable-shared; при этом будут созданы разделяемые библиотеки Kerberos, что позволит уменьшить размеры программ. Такая конфигурация используется многими пакетами независимых производителей. Если система поставляется в виде двоичных кодов, компоненты Kerberos часто распределяются по отдельным пакетам. Например, дистрибутивная поставка Kerberos для системы Red Hat состоит из пакетов, которые называются krb5-libs, krb5-server и krb5-workstation. Такой подход позволяет исключить при инсталляции ненужные пакеты.

 

Редактирование конфигурационных файлов сервера

Основным конфигурационным файлом сервера Kerberos является файл /etc/krb5.conf. Этот файл состоит из нескольких разделов; роль заголовка раздела выполняет ключевое слово, помещенное в квадратные скобки. Строки, следующие до появления очередного заголовка, определяют характеристики, соответствующие текущему разделу. Пример файла krb5.conf для KDC приведен в листинге 6.1.

Листинг 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], представленном в листинге 6.1, фигурными скобками выделены строки, связанные с областью THREEROOMCO.COM. Наличие подразделов позволяет создавать файлы, поддерживающие несколько областей.

На заметку

Большинство разделов, содержащихся в рассмотренном конфигурационном файле, используется для настройки серверов приложений и клиентов Kerberos. Не нужны лишь разделы [login] и [kdc] . Для некоторых программ могут потребоваться специальные параметры, которые обычно задаются в разделе [appdefaults] .

KDC также использует собственный конфигурационный файл kdc.conf. В этом файле содержатся данные, предназначенные только для KDC, в то время как информация в файле krb5.conf используется также клиентами и серверами приложений. Формат файла kdc.conf совпадает с форматом файла krb5.conf.

 

Определение области

Как правило, для определения областей в файлы krb5.conf и kdc.conf включаются специальные записи. Отредактировав файл, рассмотренный выше в качестве примера, вы измените конфигурацию KDC, серверов приложений и клиентов. Для того чтобы изменения были учтены сервером Kerberos и серверами приложений, надо перезапустить эти программы.

Редактирование файла krb5.conf

В файле krb5.conf находится раздел [realms], в котором определены основной и ведомые серверы. В разделе [domain_realm] указывается взаимосвязь между областью Kerberos и доменом Internet. Оба раздела содержатся в листинге 6.1.

В рассмотренном примере раздел [realms] определяет основной KDC и два ведомых KDC для области THREEROOMCO.СОМ. Традиционно эти серверы называются kerberos и kerberos- n , где n — это номер ведомого сервера в домене, соответствующем области. В данном примере домен и область Kerberos имеют одинаковые имена (отличающиеся только регистром символов), но в общем случае их имена не обязательно должны совпадать. В определении каждого из указан номер порта, по которому устанавливаются соединения с соответствующим сервером. Запись admin-server соответствует компьютеру, который используется для администрирования области. Обычно это тот же компьютер, на котором установлен но для выполнения функций администрирования используется другой порт (как правило, порт 749). Запись определяет имя домена, связанное с принципалами. По умолчанию в качестве такого имени используется имя области Kerberos, преобразованное в символы нижнего регистра. Очевидно, что в данном примере запись default_domain не обязательна.

В одном файле krb5.conf можно указать несколько областей. Для того чтобы сделать это, надо включить в раздел [realms] имена нескольких областей, а параметры, описывающие каждую из них, поместить в фигурные скобки.

Записи, содержащиеся в разделе [domain_realm], отображают имена компьютеров и доменов в области Kerberos. За именем узла или домена (имя домена начинается с точки) следует знак равенства, после него указывается область Kerberos, к которой относится компьютер или домен. Из листинга 6.1 видно, что все компьютеры, принадлежащие домену 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

В файле kdc.conf содержатся те же записи, что и в файле krb5.conf. Пример содержимого файла kdc.conf приведен в листинге 6.2. Информация об областях Kerberos помещается в раздел [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. Создавать резервную копию этого файла можно лишь в том случае, если носитель информации будет храниться в надежном месте. При выборе основного ключа следует руководствоваться теми же правилами, что и при выборе пароля: в качестве основного ключа нельзя использовать слово ни одного из существующих языков, его нельзя создавать на основе каких-либо данных, которые злоумышленник может узнать из официальных источников. В основном ключе должны присутствовать символы верхнего и нижнего регистра, цифры и знаки пунктуации. Ключ должен напоминать случайный набор символов и в то же время достаточно легко запоминаться. Основу ключа могут составлять начальные буквы слов некоторой фразы. Например, из фразы "yesterday I went to the dentist" формируется последовательность 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/[email protected]'

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 либо в другой каталог, используемый системой Kerberos, например в /usr/local/var/krb5kdc. Ниже приведен перечень файлов, создаваемых с помощью утилиты kdb5_util.

• Stash-файл с именем .k5. имя_области или .k5stash.

• Файлы principal и principal.ok, содержащие базу данных Kerberos. (В некоторых системах файл principal называется principal.db.)

• Файлы principal.kadm5 и principal.kadm5.lock, предназначенные для администрирования Kerberos.

Если вы по каким-то причинам не хотите создавать stash-файл, то, вызывая kdb5_util, не надо указывать опцию -s. В этом случае при каждом запуске сервера Kerberos придется задавать основной ключ.

 

Администрирование области

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

Определение базовых ACL

Информация о принципалах 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.СОМ. Подобное определение позволяет предоставить доступ к KDC всем администраторам.

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

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

Код Описание
а Позволяет добавлять принципалов или политики
А Запрещает добавлять принципалов или политики
d Позволяет удалять принципалов или политики
D Запрещает удалять принципалов или политики
m Позволяет модифицировать принципалов или политики
M Запрещает модифицировать принципалов или политики
с Позволяет изменять пароли принципалов
С Запрещает изменять пароли принципалов
i Позволяет передавать запросы базе данных
I Запрещает передавать запросы базе данных
1 Позволяет выводить списки принципалов или политик из базы данных
L Запрещает выводить списки принципалов или политик из базы данных
x или * Признак групповой операции

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

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

*/[email protected] *

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

Создание принципалов

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

При запуске программ kadmin и kadmin.local можно задавать различные параметры, определяющие имя принципала, область, администрирование которой будет выполняться, и т.д. Подробную информацию о поддерживаемых параметрах можно получить, обратившись к соответствующим разделам справочной информации. После запуска программы надо ввести команды и данные, которые она запрашивает. Например, чтобы добавить принципала admin/[email protected] необходимо задать команду addprinc.

# kadmin.local

Authenticating as principal root/[email protected] with

password.

kadmin.local: addprinc admin/[email protected]

WARNING: no policy specified for admin/[email protected];

defaulting to no policy

Enter password for principal "admin/[email protected]":

Re-enter password for principal "admin/[email protected]":

Principal "admin/[email protected]" 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 (эти два принципала являются стандартными компонентами Kerberos; вам нет необходимости создавать их).

В дополнение к принципалу, который соответствует администратору, вы должны создать принципалов для ваших пользователей, серверов администрирования и KDC. Для этого используется описанная выше команда addprinc. Предположим, например, что вам надо добавить принципала [email protected]. Для этого вы должны ввести следующую команду:

kadmin.local: addprinc [email protected]

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

Принципалы для серверов приложений создаются аналогичным образом, но идентификаторы обычно имеют вид имя_сервера / имя_узла @ имя_области (именем сервера может быть, например, pop или ftp). Необходимо также создать принципала, в идентификаторе которого в качестве основы вместо имени сервера будет указано слово host. Кроме того, надо создать ярлык принципала host, используя для этого команду ktadd. Каждый ярлык должен быть помещен в отдельный файл, т.е. для разных узлов необходимо задавать различные значения опции -k. Впоследствии этот файл следует переместить на узел, на котором выполняется сервер приложения. Можно поступить и по-другому: вызвать программу kadmin с компьютера, на котором расположен сервер приложения, создать принципала для сервера и использовать команду ktadd для того, чтобы поместить ярлык в файл на этом компьютере.

Вероятнее всего, вы решите создать принципала для каждого KDC. Идентификаторы таких принципалов создаются в формате host/ имя_узла @ имя_области , например host/kerberos-1.threeroomco.com/THREEROOMCO.COM. Для ведомых KDC создавать принципалы не обязательно, но они могут быть полезны, если на соответствующем компьютере будет разрешена регистрация обычных пользователей (что категорически не рекомендуется) или если вы захотите использовать ведомый KDC вместо ведущего. Ведущему KDC этот принципал понадобится для того, чтобы передать базу данных ведомому KDC.

Окончив работу с программой kadmin, надо завершить ее выполнение путем ввода команды quit.

 

Запуск KDC

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

Если сценарии SysV отсутствуют, вы можете использовать для запуска программы krb5kdc и kadmin, которые входят в состав пакета Kerberos. Каждая программа порождает процесс из оболочки, поэтому вам нет необходимости указывать после ее имени символ "&". Вызывать данные программы можно из локального сценария запуска (/etc/rc.d/rc.local).

 

Настройка ведомого KDC

Ведомый KDC настраивается практически так же, как и ведущий. Вам надо отредактировать файлы krb5.conf и kdc.conf, использовать kdb5_util для создания файлов базы данных, сформировать файл ACL и вызвать команду ktadd программы kadmin.local, чтобы записать ярлык в файл.

Каждому KDC требуется файл, в котором перечислены все KDC (или, точнее, принципалы, связанные со всеми KDC. Этот файл необходим для передачи данных из базы. Указанный файл имеет имя kpropd.acl и чаще всего хранится в каталоге /var/kerberos/krb5kdc либо /usr/local/var/krb5kdc. Содержимое этого файла выглядит приблизительно следующим образом:

host/[email protected]

host/[email protected]

Сформировав данный файл для каждого из 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, вам придется внести изменение в его конфигурационный файл (о настройке суперсерверов см. в главе 4). Если в файле /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

 

Настройка сервера приложений Kerberos

 

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

На заметку

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

 

Выбор конфигурации сервера приложения

При настройке серверов приложений совершаются многие из тех действий, которые выполнялись при выборе конфигурации KDC. В частности, настраивая сервер приложений, необходимо изменить содержимое разделов [realms] и [domain_realm] файла krb5.conf так, чтобы находящиеся в них данные отражали конфигурацию областей. Кроме того, для работы сервера приложений нужен файл, содержащий ярлык. В этом файле должны находиться данные для узла (host/ имя_узл а@ имя_области ) и для каждого из керберизованных серверов, которые выполняются на компьютере (например, если вы собираетесь использовать керберизованный сервер Telnet, идентификатор принципала будет выглядеть так: telnet/ имя_узла @ имя_области ). Файл, содержащий ярлык, можно создать с помощью программы kadmin.local на том компьютере, на котором выполняется KDC. Чтобы сделать это, вам придется добавить принципалов, вызвав команду addprinc, а затем записать ключи для этих принципалов в файл. Сеанс работы с программой kadmin.local может выглядеть так:

kadmin.local: addprinc \

 host/[email protected]

kadmin.local: addprinc \

 telnet/[email protected]

kadmin.local: ktadd -k gingko.keytab \

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

Файл gingko.keytab, полученный в результате описанных действий, надо переместить в каталог /etc компьютера, на котором выполняется сервер приложений, и присвоить ему имя krb5.keytab. Так как файл содержит чрезвычайно важную информацию, для его копирования надо применять средства, исключающие утечку данных, например перенести файл на дискету или использовать scp. Записав файл по месту назначения, надо установить права, позволяющие обращаться к нему только пользователю root, и удалить файл с компьютера KDC. Данный файл можно непосредственно создать на том компьютере, на котором установлен сервер приложений. В этом случае при вызове команды ktadd не надо указывать опцию -k gingko.keytab; система самостоятельно разместит файл в нужном каталоге. Данный метод пригоден, только если средства администрирования установлены и корректно сконфигурированы; кроме того, необходимо, чтобы была правильно выбрана базовая конфигурация Kerberos.

 

Запуск керберизованных серверов

Как правило, в состав стандартного пакета 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

 

Для того чтобы пользователь мог работать с системой Kerberos, надо в первую очередь создать принципала для этого пользователя. Принципалы пользователей имеют вид имя_пользователя @ имя_области , и для их создания применяются утилиты kadmin и kadmin.local. После создания принципала пользователь может обращаться к серверам с помощью клиентов, ориентированных на работу в системе Kerberos. Вам, как системному администратору, необходимо установить соответствующие клиентские программы. Пользователям также потребуются утилиты, предназначенные для получения TGT и управления ими. Если вы захотите, чтобы средства Kerberos использовались для управления регистрацией на отдельных рабочих станциях, вам надо модифицировать обычные инструменты регистрации.

 

Обеспечение доступа к серверам Kerberos

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

Использование сетевых утилит Kerberos

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

•  kinit. Эта программа получает TGT. Ее действие можно представить себе как "регистрацию" пользователя в области Kerberos; до запуска kinit воспользоваться клиентами Kerberos невозможно. При выполнении программа kinit обращается к KDC для получения TGT. Как было сказано в начале данной главы, TGT используется керберизованными приложениями для получения разрешения на пользование серверами приложений Kerberos. По умолчанию в качестве основы идентификатора принципала применяется имя пользователя; в этом же идентификаторе указывается имя области, принятое по умолчанию. Если вам необходимо, чтобы использовался другой идентификатор принципала, его надо указать при вызове программы. Соответствующая команда может иметь вид kinit [email protected]. Программа kinit также поддерживает и другие опции. Подробную информацию о них можно получить, обратившись к страницам справочной системы, посвященным kinit.

• klist. Данная программа выводит список билетов (в том числе TGT), выданных на текущий момент, а также информацию о сроке их действия. Если программа kinit еще не запущена, klist не выведет сведений ни об одном билете.

• kpasswd. Программа kpasswd не имеет отношения к поддержке конкретных сеансов Kerberos; она позволяет изменять пароль принципала в базе данных Kerberos. Эта программа по сути представляет собой аналог passwd. Для использования kpasswd необходимо иметь TGT.

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

Совет

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

Как используются перечисленные выше утилиты на практике? В большинстве случаев программы kinit и kdestroy вызываются соответственно в начале и в конце сеанса работы. Чтобы определить текущее состояние билетов, можно использовать утилиту klist. Рассмотрим следующий пример:

$ kinit

Password for [email protected]:

$ klist

Ticket cache: FILE:/tmp/krb5cc_500

Default principal: [email protected]

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 [email protected]:

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, вызываемая в начале работы, получает TGT, который затем отображается при вызове утилиты klist как krbtgt. Программа klist выводит также время выдачи билета и окончания его действия; в данном случае билет действителен в течение десяти часов (в зависимости от системы это значение может изменяться). Если вызвать klist после использования керберизованного клиента, данная утилита выведет сведения о другом билете. Для изменения пароля надо сначала указать текущий пароль, а затем дважды ввести новый. Как и при работе с kinit, символы, составляющие пароль, не отображаются на экране. После вызова kdestroy все билеты удаляются.

Использование керберизованных клиентов

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

• telnet. Программа telnet, ориентированная на работу с Kerberos, отличается от стандартной программы telnet лишь некоторыми опциями. Если вы вызовете программу с помощью команды telnet удаленный_узел , вам придется ввести пользовательское имя и пароль. Чтобы воспользоваться преимуществами однократной регистрации, вы должны задать опции -а (автоматическая регистрация) и -f (перенаправление билетов).

• rlogin. Стандартная программа rlogin может создавать серьезную угрозу безопасности системы (этот вопрос будет подробно рассмотрен в главе 13). Работая с керберизованной версией этой программы, можно воспользоваться средствами аутентификации Kerberos, для чего необходимо задать опцию -f. Результат получится приблизительно такой же, как при вызове telnet с опциями -а и -f.

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

На заметку

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

• rsh. Данная утилита позволяет запускать на другом компьютере программы, выполняющиеся в текстовом режиме, без использования telnet, rlogin и других подобных средств. Как и при работе с прочими керберизованными инструментами, при вызове данной программы надо задавать опцию -f.

• rcp. Стандартная программа rcp предназначена для передачи файлов; керберизованная версия данного инструмента поддерживает средства аутентификации Kerberos.

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

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

При установке системы Kerberos, поставляемой в виде исходных кодов, пользовательские программы по умолчанию размещаются в каталоге /usr/local/bin (инструменты, предназначенные для администрирования, располагаются в /usr/local/sbin). Некоторые пакеты, распространяемые в виде двоичных кодов, используют другие каталоги. Например, Kerberos для Red Hat помещает пользовательские программы в каталог /usr/kerberos/bin. Для того чтобы использовать керберизованные инструменты вместо стандартных программ, надо включить каталоги, в которых размещены эти инструменты, в состав строки, задаваемой в качестве значения переменной окружения PATH, и убедиться, что они находятся перед каталогами со стандартными программами. (Значение переменной окружения PATH обычно указывается в файле /etc/profile, а для пользователей, работающих с оболочкой Bash, — в файле .bashrc.

 

Применение Kerberos для регистрации пользователей

При обсуждении средств поддержки сеанса Kerberos предполагалось, что пользователь уже зарегистрирован в системе. Однако подобный подход крайне неудобен, так как пользователю приходится регистрироваться дважды: один раз в начале работы на компьютере, а второй раз при работе с серверами Kerberos (при запуске программы kinit). Решением этой проблемы могло бы быть использование программы, одновременно решающей обе задачи. В составе пакета Kerberos обычно поставляются два подобных инструмента: login.krb5 и ksu. Они предназначены для регистрации пользователя в текстовом режиме. Регистрацию можно было бы организовать и по-другому, модифицировав библиотеки Linux для работы с Kerberos. Такое решение сложнее в реализации, но обеспечивают большую гибкость.

Внимание

Рекомендуется перед использованием login.krb5 сначала проверить программу kinit для основных учетных записей, в том числе для записи root. Если kinit не работает, не будет работать и login.krb5 , следовательно, вам не удастся зарегистрироваться с консоли в текстовом режиме. Желательно также зарегистрироваться под именем root с одного из виртуальных терминалов. В случае, если у вас возникнут проблему с использованием login.krb5 , вы сможете изменить конфигурацию программы. Аналогичному подходу необходимо следовать и при работе с другими инструментами регистрации.

Выполнение аутентификации Kerberos в текстовом режиме

Процедура регистрации в системе Linux в текстовом режиме включает использование программы getty или одной из ее разновидностей (разновидностями getty являются mingetty, mgetty и vgetty). Они запускаются из /etc/inittab, контролируют консольный терминал и последовательные порты и передают управление программе /bin/login. Программы поддержки некоторых сетевых протоколов, например Telnet, также вызывают /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 регистрация пользователя на компьютере будет автоматически сопровождаться начальной регистрацией в системе Kerberos. Процедура начальной регистрации включает получение TGT, поэтому после нее нет необходимости в вызове kinit. Несмотря на то что описанная конфигурация предполагает наличие записи в файле /etc/passwd, рабочего каталога пользователя и прочих ресурсов, необходимых в обычных условиях для нормальной работы на компьютере, в системе будет выполняться только аутентификация Kerberos. Существуют также другие средства регистрации, которые надо модифицировать для работы с Kerberos. К ним относятся регистрация с помощью инструментов с графическим интерфейсом, а также регистрация посредством серверов, которые не используют /bin/login, например SSH.

Переход к новой учетной записи после регистрации

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

• Компьютер, на котором работает ksu, должен иметь ярлык (обычно он хранится в файле /etc/krb5.keytab).

• Для исполняемого файла ksu должен быть установлен признак SUID, так, чтобы программа, запускаемая от имени любого пользователя, выполнялась с правами root. Во многих пакетах Kerberos этот признак не установлен, поэтому вам необходимо сделать это самостоятельно (вызвать команду chmod a+s /usr/kerberos/bin/ksu).

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

Для того чтобы один пользователь мог перейти к учетной записи другого пользователя, целевой пользователь должен создать файл авторизации. Без этого файла ksu запросит пароль, который может быть передан по сети в незашифрованном виде (это произойдет, если пользователь регистрировался посредством незащищенного протокола, например Telnet). Файл .k5login предоставляет другому пользователю полный набор привилегий. Он состоит из набора строк, в каждой из которых указан принципал Kerberos. Файл .k5users предоставляет пользователю ограниченный доступ; в нем указаны списки программ, которые этот пользователь может запускать. Каждая строка файла начинается с идентификатора принципала Kerberos, за которым следуют имена программ, разделенных пробелами. Групповые операции обозначаются с помощью символа *. Ниже приведен пример записи, с помощью которой принципалу [email protected] предоставляются права на запуск программ /bin/ls и /usr/bin/zip.

[email protected] /bin/ls /usr/bin/zip

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

Если вы хотите непосредственно выполнить некоторую программу, вы можете сделать это с помощью опции -е имя_программы . Например, для того, чтобы запустить /bin/ls от имени пользователя fluffy, вам надо вызвать команду fluffy -e /bin/ls.

Использование РАМ

Замена программ login и su специальными инструментами, ориентированными на работу с Kerberos, помогает решать задачи аутентификации, но существуют ситуации, в которых подобный подход не приносит желаемых результатов. Особенный интерес вызывают случаи, когда возникает необходимость контролировать процесс регистрации на рабочей станции с помощью программы с графическим интерфейсом и выполнять аутентификацию в системе Kerberos. Существуют также другие локальные средства, выполняющие аутентификацию пользователей, которые необходимо связать с Kerberos; в качестве примеров таких средств можно привести vlock и xscreensaver (эти инструменты блокируют сеанс взаимодействия, осуществляемый как в текстовом, так и в графическом режиме, до тех пор, пока пользователь не введет пароль). Существуют универсальные инструменты связывания различных программы со средствами Kerberos, но на сегодняшний день эти инструменты нельзя назвать широко распространенными, и они не поставляются в комплекте с Kerberos. Средства для решения данной задачи базируются на поддержке модулей РАМ (Pluggable Authentication Module — встраиваемый модуль аутентификации) в системе Linux.

РАМ выполняет роль посредника между программами, которым требуется аутентификация (например, сервером FTP, программой login, инструментами регистрации, работающими в среде X Window), и базами данных, в которых хранится информация о пользователях, в частности пароли (/etc/passwd, /etc/shadow и другие файлы стандартного пакета Linux). Процедуры аутентификации оформляются в виде отдельной библиотеки. В этом случае файлы, применяемые для аутентификации, могут быть без труда модифицированы, а программы, использующие их, остаются без изменений. Для поддержки нового формата файлов модифицируются только РАМ. В этом смысле реализация средств поддержки Kerberos в виде РАМ является почти идеальным решением, позволяющим обеспечить совместную работу с Kerberos многих приложений. Любые изменения не затрагивают прикладные программы, которые взаимодействуют только с РАМ.

На заметку

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

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

• Модуль Деррика Брешера (Derrik Brashier). Этот модуль предназначен для использования совместно с Kerberos V4. Он расположен по адресу ftp://ftp.dementia.org/pub/pam/; имена файлов, содержащих этот модуль, начинаются символами pam_krb4. Выберите самый новый из файлов (во время написания данной книги все файлы датировались 1998 г.). Данный модуль распространяется в исходных кодах, поэтому перед использованием его надо скомпилировать.

• Модуль Фрэнка Кусека (Frank Cusack). Модуль РАМ, поддерживающий MIT Kerberos V5 и Heimdal, находится по адресу http://www.nectar.com/zope/krb/. Этот пакет доступен в исходных кодах; изначально коды были написаны для Solaris, но после компиляции они будут работать в системе Linux.

• Модуль Кертиса Кинга (Curtis King). Этот модуль доступен по адресу ftp://ftp.dementia.org/pub/pam/; имя файла — pam_krb5-1.1.3.tar.gz. Данный модуль также требует компиляции, в ходе которой могут возникнуть проблемы.

• Модуль для системы Red Hat. Модуль РАМ Kerberos V5 входит в состав дистрибутивного комплекта Red Hat под именем pam_krb5. Данный вариант РАМ поставляется в виде двоичного кода в формате поэтому чрезвычайно просто устанавливается в Red Hat и других подобных системах. При подготовке материала данной главы я использовал именно этот тип модуля, хотя следует отметить, что точно так же работает модуль Фрэнка Кусека.

• Модули для системы Debian. В Debian и других подобных системах работа с Kerberos V5 и Heimdal поддерживается соответственно модулями libpam-krb5 и libpam-heimdal. На Web-узле Debian эти пакеты найти достаточно сложно, поэтому лучше скопировать их, обратившись по адресам 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. В системе Red Hat библиотеки содержатся в файлах pam_krb5.so и pam_krb5afs.so. Для работы с этими библиотеками вы должны внести изменения в конфигурационные файлы РАМ, которые содержатся в каталоге /etc/pam.d. Имена конфигурационных файлов составляются на основании имен серверов и других программ, для которых необходимо выполнить аутентификацию. Например, содержимое файла /etc/pam.d/login определяет взаимодействие программы login с РАМ. При редактировании конфигурационного файла РАМ в нем надо изменить (или добавить) одну или несколько строк, определяющих использование нового модуля Kerberos. В пакете, предназначенном для системы Red Hat, содержится большое число файлов с примерами настройки. Эти файлы находятся в каталоге /usr/share/doc/pam_krb5- версия /pam.d , где версия — это номер версии пакета. Чтобы упростить настройку, надо скопировать соответствующие конфигурационные файлы в каталог /etc/pam.d. Файлы, которые могут потребоваться вам, перечислены ниже.

• login. Данный файл управляет взаимодействием с программой login. Настроив РАМ для работы с Kerberos, вы можете отказаться от login.krb5 и продолжать работу с привычной вам программой login.

• gdm. GNOME Display Manager, или GDM, является одним из трех широко распространенных средств регистрации с графическим интерфейсом. (О настройке GDM и других подобных инструментах речь пойдет в главе 14.)

• xdm. Вторым инструментом, предоставляющим графический интерфейс для регистрации, является X Display Manager, или XDM. Конфигурационные файлы XDM может также использовать KDE Display Manager. В описании утверждается, что данный файл должен обеспечить аутентификацию Kerberos при работе указанных средств регистрации, однако при установке конфигурации в системе Mandrake возникают проблемы.

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

• passwd. Этот файл настраивает РАМ так, что информация об изменении пароля, выполненном с помощью программы passwd, передается KDC.

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

• xlock и xscreensaver. Программы с такими именами предназначены для блокирования сеанса X Window (т.е. они выполняют действия, аналогичные vlock). Программа xscreensaver автоматически блокирует сеанс, если в течение определенного периода времени пользователь не выполняет никаких действий.

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

Если некоторая программа использует РАМ, то для обеспечения ее совместной работы с Kerberos вам необходимо добавить или заменить некоторые строки в конфигурационном файле РАМ. В составе такого файла содержатся записи, определяющие основные действия, связанные с аутентификацией: auth (аутентификация пользователя), account (проверка корректности учетной записи), password (изменение пароля) и session (начало и завершение сеанса). В листинге 6.4 показано содержимое файла gdm, входящего в состав Kerberos РАМ для Red Hat.

Листинг 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, которые настраивают РАМ для использования Kerberos при регистрации пользователя и завершении его работы. В записи auth содержится параметр use_first_pass, который сообщает Kerberos РАМ о том, что для поддержки сеанса используется первый пароль. В результате модуль действует подобно kinit, получая и сохраняя TGT. Аналогично могут быть настроены многие модули РАМ, но для установки конфигурации некоторых из них необходимо выполнить дополнительные действия. Так, например, может потребоваться дополнительная запись password, которая помещается после существующих и имеет следующий вид:

password required /lib/security/pam_krb5.so use_authtok

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

В некоторых случаях приходится удалять существующие записи из файлов, размещенных в /etc/pam.d. В частности, если вы добавляете запись, указывающую на а в файле уже есть запись такого же типа, которая ссылается на pam_pwdb.so, существующую запись необходимо удалить. Библиотека pam_pwdb.so обеспечивает непосредственный доступ к базе данных паролей, и если обе записи присутствуют, в аутентификации участвуют как локальная база паролей, так и база данных Kerberos. Возможно, в некоторых ситуациях, когда требуется чрезвычайно высокая степень защиты, такой подход оправдан, но в большинстве случаев он лишь уменьшает степень гибкости Kerberos, так как пользователь вынужден менять пароль и на и на рабочей станции. Если в конфигурационном файле РАМ password предусмотрена двойная проверка, при работе с одной рабочей станцией настройки легко согласовать с помощью инструмента passwd, однако отслеживать изменения во всей сети достаточно сложно.

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

 

Резюме

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

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

 

Глава 7

Совместное использование файлов и принтеров с помощью Samba

 

В конце 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, можно порекомендовать обратиться к специальным изданиям на эту тему, например, к моей книге Linux Samba Server Administration (Sybex, 2001), а также к книге Экштейна (Eckstein) и Коллиера-Брауна (Collier-Brown) Using Samba (O'Reilly, 1999).

 

Использование сервера Samba

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

Поскольку NetBIOS и SMB/CIFS наследуют некоторые характеристики систем DOS и Windows, очевидно, что Samba целесообразнее всего применять в сетях, использующих компьютеры под управлением именно этих операционных систем. Ряд свойств Samba упрощает обмен данными с DOS и Windows. Например, всем известно, что в именах файлов DOS и Windows не учитывается регистр символов; имена FILE.TXT, file.txt и File.txt представляют один и тот же файл. В Linux, напротив, имена файлов зависят от регистра символов. Обеспечивая совместную работу Windows и Linux, Samba позволяет обращаться к файлам без учета регистра. Кроме того, SMB/CIFS поддерживает такие особенности файловой системы DOS и Windows, как атрибуты скрытых файлов и файлов архивов. Скрытый файл — это файл, который в обычных условиях не доступен для пользователей, а файл архива — это файл, содержащий резервную копию данных. В файловой системе Linux скрытые файлы и файлы архивов отсутствуют, но Samba позволяет устанавливать и использовать соответствующие признаки. Подобные требования предъявляются при обмене файлами с другими операционными системами, например с системой OS/2, поэтому серверы Samba могут быть использованы и для работы с ними.

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

 

Настройка Samba

 

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

 

Конфигурационный файл Samba

Для настройки Samba используется файл smb.conf. В большинстве дистрибутивных пакетов Linux он помещается в один из следующих каталогов: /etc, /etc/samba или /etc/samba.d. Подобно многим другим конфигурационным файлам Linux, в smb.conf для обозначения комментариев в начало строки включается символ #. Остальные строки файла разбиты на разделы, каждый из которых содержит определение разделяемого объекта. В начале раздела находится имя разделяемого объекта, помещенное в квадратные скобки:

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

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

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

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

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

 

Идентификация сервера Samba

В сетях NetBIOS используется система имен, не связанная с доменными именами, применяемыми в сетях TCP/IP. Например, компьютеру harding.threeroomco.com может соответствовать имя BILLY, принадлежащее домену USPRES. Для того чтобы удобнее было отличать имена TCP/IP от имен NetBIOS, последние будут представляться в данной главе символами верхнего регистра. В системе NetBIOS предусмотрены два уровня имен: имена компьютеров и имена рабочих групп или доменов. (Домены NetBIOS не имеют никакого отношения к доменам TCP/IP.) В Samba предусмотрены средства поддержки как имен компьютеров, так и имен рабочих групп и доменов.

На заметку

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

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

workgroup = USPRES

Данный параметр указывает на то, что компьютер принадлежит рабочей группе USPRES. Система может взаимодействовать с членами других рабочих групп, но при выполнении ряда функций, например при просмотре сети средствами Windows, используется имя рабочей группы. Если имя группы будет задано некорректно, сервер Samba станет недоступным для броузеров Network Neighborhood и My Network Places. Эта проблема часто возникает при установке исходной конфигурации Samba.

По умолчанию Samba использует в качестве имени узла NetBIOS первый компонент доменного имени TCP/IP этого компьютера. Например, для компьютера harding.threeroomco.com Samba выберет NetBIOS-имя HARDING. Это значение можно изменить с помощью параметра netbios name. Параметр netbios aliases позволяет присвоить одному компьютеру несколько имен NetBIOS. Например, если в конфигурационном файле будут присутствовать приведенные ниже строки, то к компьютеру можно будет обращаться как по имени 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. Для того чтобы сервер Samba выполнял проверку закодированных паролей в файле smbpasswd, следует задать значение Yes этого параметра. Чтобы включить зашифрованный пароль пользователя в файл smbpasswd, надо выполнить следующую команду:

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

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

Дополнительные меры по защите обеспечивают параметры hosts allow и hosts deny. Они действуют подобно файлам /etc/hosts.allow и /etc/hosts.deny TCPWrappers, которые рассматривались в главе 4. Данные параметры позволяют задавать список узлов, которые имеют право взаимодействовать с сервером, и список узлов, для которых такое взаимодействие запрещено. Например, приведенное ниже выражение разрешает взаимодействие с системой только для узлов 192.168.7.0/24 и algernon.pangaea.edu.

hosts allow = 192.168.7. algernon.pangaea.edu

На заметку

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

 

Samba как сервер имен NetBIOS

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

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

• Применение файла lmhosts . Система может хранить информацию о соответствии имен IP-адресам в файле, который обычно называется lmhosts и выполняет те же функции, что и файл /etc/hosts в системе Linux.

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

• 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. В качестве значения первого параметра надо указать IP-адрес WINS-сервера. Второй параметр может принимать от одного до четырех значений, каждое из которых задает отдельный способ преобразования имен. Samba будет пытаться применить эти способы в том порядке, в котором они указаны в составе name resolve order. (Значения host и beast определяют соответственно обычный метод преобразования с использованием средств TCP/IP и широковещательную передачу, которая осуществляется для преобразования имен NetBIOS.) Пример использования указанных параметров приведен ниже.

wins server = 192.168.1.1

name resolve order = wins lmhosts host beast

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

 

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 указывает на то, что сервер Samba должен подготавливать список просмотра, который может совместно использоваться другими системами. По умолчанию принимается значение Yes данного параметра, поэтому он может не указываться. Для параметра local master по умолчанию также предполагается значение Yes. Это значение сообщает серверу Samba на то, что он должен участвовать в выборах, но не гарантирует победу. Если задано значение Yes параметра preferred master, сервер сразу после запуска выставит свою кандидатуру на выборы и, если не станет победителем, периодически будет повторять подобные попытки. По умолчанию для данного параметра устанавливается значение No. Если в сети работает несколько серверов Samba, значение Yes параметра preferred master можно задавать только на одном компьютере. В противном случае работа сети будет нарушена вследствие периодически повторяющихся процедур выборов. Параметр os level задает значение основного критерия, принимающегося во внимание при проведении выборов. Чем выше это значение, тем больше вероятность победы. Значение os level = 65 позволяет серверу одержать победу над компьютерами под управлением Windows (по крайней мере над системами Windows Me и Windows 2000), но не гарантирует победу над другими серверами Samba, так как в их конфигурационных файлах могут быть указаны более высокие значения os level. Если же вы не хотите, чтобы сервер Samba стал основным броузером, вам надо задать значение os level, равное 0.

Для настройки Samba в качестве основного броузера домена надо, во-первых, установить рассмотренные выше параметры так, чтобы компьютер выиграл выборы и стал основным локальным броузером, а во-вторых, задать параметр domain master = Yes. Вы также должны сконфигурировать систему для выполнения функций главного контроллера домена. Необходимые для этого действия будут рассматриваться в следующем разделе. Как и в случае основного локального броузера, вам не следует настраивать больше одной системы (Samba или Windows) в качестве основного броузера домена. Если сеть сконфигурирована так, что компьютеры объединяются в рабочие группы, параметр domain master указывать не следует.

 

Samba как контроллер домена

Как вы уже знаете, компьютеры в сетях 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 указывает на то, что запросы на доступ к разделяемым ресурсам должны обрабатываться с использованием имен и паролей Linux. (Такая установка принята по умолчанию для Samba 2.0.0 и более поздних версий данного продукта.) Параметр encrypt passwords управляет шифрованием паролей. Контроллер домена должен передавать все пароли в закодированном виде. Основным параметром, определяющим действия PBC, является domain logons. Если значение domain logons равно Yes, этот параметр указывает Samba на то, что сервер должен принимать запросы на регистрацию в домене и обрабатывать их с учетом содержимого файла smbpasswd. В системе Windows PBC выполняет также функции основного броузера домена и WINS-сервера. Желательно настроить подобным образом и сервер Samba.

На заметку

Для установки доменного имени надо использовать параметр 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 создает специальную учетную запись для компьютера NetBIOS с именем CLIENT. Символ $ после имени пользователя обязателен. Команда smbpasswd добавляет запись client в файл smbpasswd. Эта команда не требует указания символа $. Когда клиент Windows NT/2000/XP попытается обратиться к домену, он будет зарегистрирован с помощью доверительной учетной записи; при этом для аутентификации будет использована база паролей Samba.

Конфигурация домена требует также изменить способ настройки клиента. Это можно сделать с помощью управляющей панели. В 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 сводится к установке флажка опции и вводу имени домена

 

Организация файлового сервера с помощью Samba

 

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

 

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

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

[sample]

path = /home/samba/shared-dir

browseable = Yes

read only = No

В данном примере определяется разделяемый объект с именем [sample]. В окне броузера Windows (см. рис. 7.2) он будет отображаться как SAMPLE. Разделяемому объекту соответствует каталог /home/samba/shared-dir. Если пользователь захочет просмотреть содержимое объекта SAMPLE, он увидит файлы из этого каталога. Строка browseable = Yes не является необходимой, поскольку именно это значение параметра browseable принято по умолчанию. Значение Yes параметра browseable указывает на то, что объект должен присутствовать в списке просмотра. (Чтобы удалить разделяемый объект из этого списка, надо указать параметр browseable = No, но это не сделает данный объект недоступным. Пользователи, которые знают о наличии такого объекта, могут обратиться к нему, непосредственно указав имя объекта в строке Address броузера.) По умолчанию Samba создает разделяемые объекты, предназначенные только для чтения; клиенты не могут записывать в них данные. Чтобы объект допускал как чтение, так и запись, необходимо включить в состав описания параметр read only = No либо один из его синонимов: writeable = Yes или write ok = Yes. Информация о владельце и правах доступа к файлам, входящим в состав разделяемого объекта, остается такой же, как и в системе Linux. При необходимости Samba позволяет переопределить владельца и права (действия, необходимые для этого, описаны ниже в данной главе).

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

• Задавать параметр path нет необходимости. Samba использует рабочий каталог пользователя, обратившегося к разделяемому объекту.

• В списке просмотра разделяемый объект отображается под именем, совпадающим с именем пользователя (например, объект rodsmith, представленный на рис. 7.2). Если вы зададите параметр browseable = No, объект [homes] не будет отображаться в списке просмотра, но будет доступен под именем пользователя.

Во многих дистрибутивных пакетах разделяемый объект [homes] изначально присутствует в файле smb.conf. Поэтому, даже если вы не объявите новые разделяемые

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

Настраивая сервер Samba, вы можете описывать как угодно много разделяемых объектов, но очевидно, что определять несколько объектов [homes] не имеет смысла. Кроме того, если вы обнаружите, что некоторый параметр присутствует в описаниях всех разделяемых объектов, целесообразно перенести его в раздел [global]. Если вы сделаете это, значение параметра будет использоваться по умолчанию для всех объектов.

 

Поддержка имен файлов Windows

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

Одно из самых важных отличий файловой системы Linux от системы Windows состоит в том, что имена файлов Linux чувствительны к регистру символов, т.е. имена FILE.TXT, file.txt и File.txt идентифицируют различные файлы; при помещении их в один каталог конфликт не возникает. Это также означает, что при вводе имени файла пользователь должен следить за тем, чтобы были заданы символы требуемого регистра. В отличие от Linux, Windows хранит сведения о регистре, но не учитывает их при сравнении имен файлов, поэтому два файла с именами, отличающимися только регистром символов, не могут существовать в одном и том же каталоге. Файловая система DOS нечувствительна к регистру символов; если даже пользователь задал имя файла буквами нижнего регистра, система преобразует их в прописные буквы.

Параметр case sensitive, помещаемый в конфигурационный файл, определяет, должен ли сервер Samba учитывать регистр символов в именах файлов. По умолчанию принимается значение No данного параметра, что позволяет серверу Samba работать с клиентами Windows и DOS. Если клиент запросит некоторый файл, Samba проверит все файлы, отличающиеся от указанного только регистром символов, т.е. будет имитировать поведение Windows. Недостаток подобного подхода состоит в том, что производительность системы несколько снижается. Если вы хотите добиться максимальной производительности, вам надо задать параметр sensitive = Yes, но при этом некоторые из программ Windows будут работать с ошибками. Эти ошибки, конечно же, связаны с особенностями взаимодействия с сервером Samba. Параметр sensitive = Yes целесообразно использовать при работе с клиентами, которые выполняются в тех операционных системах, в которых, подобно Linux, в именах файлов и каталогов учитывается регистр символов.

Параметры preserve case и short preserve case определяют, должен ли сервер Samba сохранять информацию о регистре символов в именах файлов. Если установлено значение Yes, Samba сохраняет имена файлов именно в том виде, в котором их задают клиенты. При установленном значении No Samba будет преобразовывать буквы в именах файлов к верхнему или нижнему регистру. Конкретный регистр зависит от параметра default case. По умолчанию для этого параметра установлено значение Lower, но при необходимости вы можете задать значение Upper. Параметр preserve case воздействует на все файлы, но для коротких имен более высокий приоритет имеет параметр short preserve case. (Короткими именами называются имена, составленные по соглашениям DOS, т.е. содержащие до 8 символов в имени файла и до 3 символов в расширении; такие имена принято также называть именами 8.3.) Если в вашей сети содержится большое количество DOS-клиентов, следует задать параметр short preserve case = No. В результате в системе Linux имена файлов будут составляться из символов нижнего регистра, но DOS-клиентам эти же имена будут доступны преобразованными к верхнему регистру.

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

 

Владелец файла и права доступа

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

[jekyl]

path = /home/samba/jekyl

read only = No

force user = hyde

Каждый пользователь, обратившийся к данному объекту, будет выполнять любые действия так, как будто их выполняет пользователь, которому в Linux соответствует учетная запись hyde. Если к разделяемому объекту обратится пользователь muriel и создаст в нем файл, владельцем этого файла будет hyde. To же самое произойдет, если файл создаст пользователь henry. Любой пользователь, работающий с данным объектом посредством Samba, может читать файлы, расположенные в соответствующем каталоге, даже если ему запрещено делать это при обычной регистрации в системе Linux. Доступ предоставляется даже тем пользователям, которым в системе Linux запрещено просматривать содержимое каталога /home/samba/jekyl. Пользователи работают с файлами в составе разделяемого объекта так, как будто это делает пользователь hyde. Подобным образом действует параметр force group, но он учитывает не владельца файла, а принадлежность файла группе.

На заметку

Обращаясь к разделяемому объекту, для которого указан параметр force user , пользователь указывает собственный пароль.

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

Несмотря на то что и Linux, и SMB/CIFS поддерживают пользовательские имена, механизмы обеспечения доступа, используемые ими, не совпадают. Если Samba применяется для взаимодействия с клиентами DOS и Windows 9x/Me, клиент вовсе не использует сведения о правах доступа. Поэтому вы можете устанавливать для файлов, созданных этими клиентами, любые права. Сделать это можно с помощью параметров create mask и directory mask, которые позволяют задавать права доступа к файлам и каталогам. В качестве значения каждого из параметров задается трех- или четырехзначное восьмеричное число; оно представляет признаки доступа, которые могут быть установлены для файла, создаваемого средствами Samba. По умолчанию для параметра create mask принимается значение 0744, а для параметра directory mask — значение 0755. Оба значения разрешают владельцу файла чтение и запись, а членам группы и всем остальным пользователям — только чтение. Вы можете задавать значения данных параметров по-своему, но при этом необходимо учитывать, что биты прав доступа используются для представления признаков DOS, определяющих скрытые, системные файлы и файлы архивов.

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

• map archive. Если для данного параметра установлено значение Yes (значение по умолчанию), признак файла архива DOS отображается в бит, определяющий права владельца на выполнение файла. Клиенты DOS и Windows устанавливают этот признак при создании нового файла и сбрасывают его, если с помощью специальных программ создается резервная копия данного файла. По этой причине файлы, созданные по инициативе клиентов Samba, выглядят как исполняемые. Данный эффект наблюдается только в том случае, когда используется значение параметра create mask, принятое по умолчанию.

• map system. Если для данного параметра установлено значение Yes, признак системного файла DOS отображается в бит, определяющий права группы на выполнение файла. По умолчанию используется значение No, т.е. отображение не осуществляется. В DOS и Windows этим признаком помечаются файлы специального назначения. Вероятность того, что такие файлы будут сохранены на сервере Samba, очень мала.

• map hidden. Если для данного параметра установлено значение Yes, признак скрытого файла DOS отображается в бит, определяющий права любого пользователя системы Linux на выполнение файла. По умолчанию принимается значение No. В системах DOS и Windows файлы, для которых установлен данный признак, остаются доступными, но они не отображаются при выводе содержимого каталогов и отсутствуют в диалоговых окнах, предназначенных для выбора файлов.

На заметку

По умолчанию 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. Если вы не хотите поддерживать соответствие между правами в Windows NT/2000/XP и Linux, задайте для данного параметра значение No.

На заметку

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

 

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

Samba использует различные средства контроля доступа к серверу. В качестве примера можно привести уже упоминавшиеся параметры hosts allow и hosts deny и, конечно же, модель аутентификации, согласно которой пользователь должен указывать имя и пароль. Samba также предоставляет средства контроля доступа к отдельным разделяемым объектам. Наиболее важными средствами управления доступом являются параметры 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 имеют право не только читать данные, но и записывать их.

 

Организация сервера печати с помощью Samba

 

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

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

На заметку

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

 

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

Основное различие между разделяемыми объектами файлов и принтеров состоит в том, что в описании последнего присутствует параметр printable = Yes или print ok = Yes (эти параметры являются синонимами). Каталог, указанный в определении объекта, представляет собой временный каталог спулинга (он не должен совпадать с каталогом спулинга системы Linux, в качестве которого обычно используется /var/spool/lpd). По умолчанию принимается каталог /tmp, но в некоторых дистрибутивных пакетах Linux для этой цели создается каталог /var/pool/samba. При определении прав доступа для этого каталога должен быть установлен бит, запрещающий пользователям удалять из каталога файлы, которые были созданы другими пользователями. Как правило, к каталогу спулинга применяется команда chmod 1777 / каталог или chmod o+t / каталог . (Значение 1777 позволяет всем пользователям записывать данные в каталог. Такие права доступа рекомендованы для каталогов, используемых для поддержки спулинга.) Один и тот же каталог может применяться для организации нескольких очередей к принтерам. Ниже приведен пример разделяемого объекта принтера.

[laser]

comment = Laser printer in Room 7

path = /var/spool/samba

printable = Yes

Параметр comment задает комментарии для разделяемого объекта LASER. (Этот параметр также может быть использован в разделяемых объектах файлов.) Данное описание можно применять только в том случае, если в системе имеется локальная очередь печати с именем laser. Если имя очереди отличается от имени разделяемого объекта, то надо указать его с помощью параметра name. Так, например, параметр name = lр сообщает системе о том, что необходимо использовать локальную очередь с именем lр.

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

Выше в этой главе рассматривался вопрос создания разделяемого объекта файлов, обеспечивающего доступ всех пользователей к своим рабочим каталогам. Точно так же при работе с разделяемыми объектами принтеров вы можете создать один объект, обеспечивающий доступ ко всем принтерам, присутствующим в системе. Этот объект имеет имя [printers]. При наличии объекта с таким именем Samba просматривает содержимое файла /etc/printcap и для каждого принтера создает свой разделяемый объект. Подобно объекту [homes], объект [printers] обычно содержит параметр browseable = No, в результате чего разделяемый объект PRINTERS не отображается клиент-программами Windows. Если для этого параметра установлено значение Yes, в списке просмотра будут отображаться конкретные имена принтеров.

 

Совместное использование PostScript-принтеров

В ходе предыдущего обсуждения не затрагивался вопрос об использовании драйверов. Этот вопрос чрезвычайно важен для разделения принтеров в системе 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, предваряет вывод данных символом . Большинство PostScript-принтеров игнорирует этот символ, но он может влиять на поведение очереди в системе Linux. Фильтр печати ожидает встретить в начале файла, содержащего задание на печать, идентификатор формата PostScript. Обнаружив символ , фильтр печати интерпретирует его как признак того, что в файле содержится ASCII-текст. Поскольку ASCII-текст не может быть непосредственно передан на PostScript-принтер, этот файл повторно преобразуется в PostScript-формат. В результате вместо текста документа на принтер выводится его PostScript-код. Разрешить эту проблему можно двумя способами.

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

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

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

 

Совместное использование принтеров, не поддерживающих PostScript

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

Использование Ghostscript

Предположим, что вам необходимо вывести на принтер, не поддерживающий PostScript, сгенерированные Linux-приложением PostScript-данные. В этом случае система должна быть сконфигурирована так, чтобы данные, предназначенные для печати, обрабатывались программой Ghostscript. Ghostscript (http://www.cs.wisc.edu/~ghost/) — это PostScript-интерпретатор, выполняющийся не на принтере, а на компьютере. GNU-версия Ghostscript, ориентированная на работу с различными типами принтеров, поставляется в составе большинства дистрибутивных пакетов Linux. Если какой-то из принтеров не поддерживается данной реализацией Ghostscript, можно применить специальные драйверы либо воспользоваться более современным продуктом Ghostscript производства Aladdin. Информацию о совместимости различных принтеров с интерпретаторами Ghostscript можно найти, обратившись по адресу http://www.linuxprinting.org/printer_list.cgi.

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

Некоторые PostScript-драйверы в системе Windows включают в состав PostScript-файлов дополнительные команды, предназначенные для вывода информации на встроенные дисплеи принтеров. Такие команды часто приводят к появлению дополнительных страниц выходных данных с сообщениями типа %% [ LastPage ] %%. Если вы встретитесь с подобной проблемой, решить ее можно, сменив драйвер в системе Windows. Существует и другое решение. Вам надо найти файл, из которого вызывается интерпретатор Ghostscript, и добавить в строку, содержащую команду gs, последовательность символов >/dev/null. В результате сообщения с используемого в обычных условиях выходного устройства Ghostscript будут перенаправлены в файл /dev/null. В системе Caldera таким файлом является /var/spool/lpd/ имя_очереди /printfilter . В Red Hat, Mandrake и TurboLinux используется файл /usr/lib/rhs/rhs-printfilters/ps-to-printer.fpi.

Создание очереди, не обрабатывающей PostScript-данные

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

Для создания очереди без обработки надо сформировать обычную очередь печати, а затем внести изменения в файл /etc/printcap (при условии, что на вашем компьютере используется система печати BSD или LPRng). В частности, вам надо удалить из описания очереди строку if= либо задать пустое значение if. Эта строка определяет фильтр печати Linux, и ее удаление приведет к тому, что задание будет передаваться из очереди на принтер в неизменном виде. Пример описания очереди приведен ниже.

lр|hp4000|raw:\

 :lp=/dev/lp0:\

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

 :mx#0:\

 :sh:\

 :if=:

В данном примере указаны три имени принтера: lp, hp4000 и raw. Данные из этой очереди выводятся на устройство печати /dev/lp0, а в качестве каталога спулера используется /var/spool/lpd/lp. (Заметьте, что указанный здесь каталог отличается от каталога спулера Samba. Файл сначала располагается в каталоге спулера Samba, а затем перемещается в /var/spool/lpd/lp.) Опция mx#0 снимает ограничения на размер файла печати, a sh запрещает вывод страницы заголовка. Поскольку в строке if= не указан фильтр печати, данные передаются в неизменном виде.

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

Выбор способа поддержки принтера

Если компьютеру, на котором выполняется сервер 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 — возможность выполнения сценариев. Вы можете задавать команды, которые будут выполнены при наступлении определенных событий. Благодаря поддержке сценариев Samba можно использовать для решения задач, непосредственно не относящихся к совместному использованию файлов и принтеров. В начале данного раздела мы обсудим сценарии preexec и postexec и псевдопринтеры, а в заключение рассмотрим примеры использования этих средств.

 

Сценарии

preexec

и

postexec

Samba поддерживает параметры preexec и postexec, которые позволяют выполнять некоторые команды при регистрации пользователя и завершении его работы с разделяемым объектом. В качестве значения параметра preexec задаются команды, которые должны быть выполнены при регистрации пользователя, соответственно команда, указанная как значение postexec, выполняется при завершении работы пользователя с объектом. Например, если вы хотите, чтобы при обращении к разделяемому объекту сервер Samba передавал почтовое сообщение по адресу [email protected], вы должны включить в определение этого объекта следующее выражение:

preexec = mail -s "Share being used" \

 [email protected]

Если пользователь зарегистрируется для работы с объектом, Samba пошлет от его имени сообщение по адресу [email protected]. В поле Subject сообщения будет включена строка "Share being used", а по адресу отправителя получатель сможет выяснить, кто из пользователей работал с объектом.

Аналогично действует параметр postexec, но команда, заданная в качестве его значения, выполняется после окончания работы с объектом. Зная особенности работы Windows-клиентов с разделяемыми объектами SMB/CIFS, можно сделать вывод, что команда не будет выполнена сразу же после того, как пользователь закроет окно, открытое с помощью Network Neighborhood или My Network Places, но через некоторое время это обязательно произойдет.

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

При выполнении сценариев сервер Samba может обрабатывать переменные, перечисленные в табл. 7.1. Эти переменные позволяют настроить сценарии preexec и postexec для работы с конкретными пользователями, клиентами, операционными системами, установленными на клиентских компьютерах, и т.д. (Некоторые из переменных, представленных в табл. 7.1, специально предназначены для использования в разделяемых объектах принтеров.)

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

Переменная Назначение
%a Операционная система на клиентском компьютере. Возможные значения: OS2 (OS/2), Samba, UNKNOWN, WfWg (DOS или Windows for Workgroups), Win2K, Win95 (Windows 95 или 98) и WinNT
%d Идентификатор процесса сервера
%g Основная группа, к которой относится пользователь, указанный в переменной %u
%G Основная группа, к которой относится пользователь, указанный в переменной %U
%h Доменное имя сервера (в домене TCP/IP)
%H Рабочий каталог пользователя, информация о котором содержится в переменной %u
%I IP-адрес клиента
%j Номер задания на печать
%L NetBIOS-имя сервера
%m NetBIOS-имя клиента
%M Доменное имя клиента (в домене TCP/IP)
%N Сервер NIS
%p Путь к каталогу, связанному с разделяемым объектом, используемый при автомонтировании
%P Путь к каталогу, связанному с разделяемым объектом
%R Уровень протокола SMB/CIFS. Возможные значения: CORE, COREPLUS, LANMAN1, LANMAN2 и NT1
%s Имя файла, переданного разделяемому объекту принтера
%S Имя разделяемого объекта
%T Текущая дата и время
%u Эффективное имя пользователя UNIX
%U Имя пользователя, зарегистрированного в системе UNIX (может не совпадать с именем, хранящимся в переменной %u )
%v Номер версии Samba

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

• С помощью сценариев preexec и postexec можно создавать и удалять символьные ссылки между совместно используемыми каталогами и рабочим каталогом пользователя. (По умолчанию Samba следует символьным ссылкам, но поведение системы можно изменить, установив параметр follow symlinks = No.)

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

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

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

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

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

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

На заметку

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

В некоторых случаях возникает необходимость ограничить число пользователей, которые могут одновременно обращаться к разделяемому объекту. Это можно сделать с помощью параметра max connections. Чтобы полностью исключить одновременные действия пользователей, надо задать параметр max connections = 1. Однако такая конфигурация иногда создает нежелательные побочные эффекты, так как при обращении к разделяемым объектам с помощью Network Neighborhood и My Network Places соединения с разделяемыми объектами закрываются с некоторым опозданием.

 

Использование псевдопринтеров

Еще одну возможность использования сценариев предоставляет параметр print command, предназначенный для включения в описание разделяемого объекта печати. Первоначально этот параметр создавался для осуществления операций, связанных с передачей задачи на печать, но в качестве его значения можно задавать любые команды. Параметр print command позволяет выполнить специальную обработку PostScript-файлов и реализовать эффекты, имеющие лишь отдаленное отношение к выводу данных на печать. Этот параметр можно применять для обработки любых данных, содержащихся в файле, сгенерированном в системе Windows. Ниже приведены примеры задач, решаемых с помощью параметра 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 можно использовать переменные, приведенные в табл. 7.1 (некоторые из них, например %s, специально предназначены для такого применения, и их появление в составе сценариев preexec и postexec не оправдано). Переменная %H в особенности полезна при доставке данных пользователю, инициировавшему задачу; в частности, вы можете использовать эту переменную для указания пути к каталогу, в который должны быть помещены файлы после окончания обработки.

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

 

Пример использования средств Linux для записи компакт-дисков

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

Использование сценариев preexec и postexec для записи компакт-дисков

Предположим, что вы решили выделить один из разделяемых объектов 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.

Листинг 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 в вашей версии Samba. Возможно, удобнее будет заменить эту переменную значением /var/spool/samba. Основную часть работы по записи компакт-диска выполняет сценарий, код которого представлен в листинге 7.2.

Листинг 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 надо установить признак SUID, чтобы она выполнялась с правами root. Для записи компакт-диска необходимо передать zip-файл разделяемому объекту, используя для этого команду COPY системы DOS или Windows.

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

В результате выполнения данной команды содержимое файла FILE.ZIP будет записано на компакт диск. Очевидно, что вместо SERVER при вызове команды должно быть указано имя конкретного сервера. Эту команду следует поместить в файл .ВАТ; имя zip-файла будет передаваться ей с помощью переменной.

COPY %1 \\SERVER\CD-PRINT

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

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

 

Пример создания PDF-файлов

В качестве примера использования очереди печати можно привести задачу преобразования входных 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 вызывается исполняемый файл Ghostscript (gs). Опции -dNOPAUSE, -q и -dBATCH обеспечивают непрерывный вывод данных с минимальным набором специальных сообщений, не требующий вмешательства пользователя. Опция -sDEVICE=pdfwrite указывает на то, что в результате выполнения программы должны генерироваться PDF-файлы, а опция -sOutputFile=%H/%s.pdf формирует имена файлов, отличающиеся от имен заданий на печать только суффиксом .pdf. Сформированные PDF-файлы сохраняются в рабочем каталоге пользователя. Определение данного разделяемого объекта можно модифицировать так, чтобы PDF-файлы помещались в другой каталог или передавались пользователю в составе почтовых сообщений.

 

Резюме

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

 

Глава 8

Совместное использование файлов с помощью NFS

 

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

 

Использование серверов NFS

Как правило, серверы 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 — защищенная оболочка).

 

Серверы NFS для системы Linux

 

В 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, в то время как стандартный сервер NFS носит имя nfsd.

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

На заметку

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

 

NFSv2 и NFSv3

Подобно другим протоколам и программам, средства NFS периодически пересматриваются и реализуются их новые версии. В 2002 г. широко использовалась последняя на тот момент версия 3 системы NFS, или NFSv3. (На самом деле в это время уже существовала версия NFSv4, но она находилась в стадии разработки. Дополнительную информацию о состоянии дел с NFSv4 можно найти, обратившись по адресу http://www.ntsv4.org). Несмотря на наличие NFSv3 (и даже NFSv4), большинство существующих клиентов и серверов NFS поддерживают лишь NFSv2. To же самое можно сказать о ядре Linux 2.2.x. Возможность работы с NFSv3 была реализована в ядре лишь начиная с версии 2.2.18. (Для более ранних версий ядра существуют дополнительные модули, обеспечивающие поддержку NFSv3.) В NFSv3 были предусмотрены дополнительные возможности, например, улучшена блокировка файлов, повышена производительность операций записи за счет применения асинхронного режима (асинхронный режим был реализован и в программах поддержки NFSv2 в системе Linux, но соответствующие средства не соответствовали стандарту). Кроме того, NFSv3 позволяет работать с NQNFS (Not Quite NFS) и использовать соединения TCP (в NFSv2 был предусмотрен только UDP-обмен). Следует заметить, что в 2002 г. соединения TCP поддерживались в Linux лишь частично. Средства NFSv2 подходят для небольших сетей, в которых необходимость в обмене данными возникает лишь эпизодически, a NFSv3 (реализованные в полном объеме) можно использовать для обеспечения работы мощных серверов. Экспериментальные версии NFSv3 для Linux были реализованы плохо — они не поддерживали операции в асинхронном режиме. Для серверных программ ситуация несколько улучшилась с появлением ядра 2.4.x. Клиентские программы в ядре 2.4.17 работают по-прежнему медленно.

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

Если вы хотите обмениваться данными по протоколу NFSv3, то, помимо установки опций ядра, вам надо использовать утилиты, поддерживающие эту версию. Для обеспечения работы клиента вам понадобятся nfs-utils 0.1.6 либо более поздняя версия и версия утилиты mount не ниже 2.10m. Эти инструменты содержатся в большинстве дистрибутивных пакетов; для их поиска можно воспользоваться средствами 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, в последних версиях этой программы предусмотрена возможность взаимодействия с TCP Wrappers. Ограничив доступ к программе отображения портов теми компьютерами, которым действительно необходимо взаимодействовать с сервером, вы существенно повысите безопасность системы. Чтобы запретить доступ всем узлам без исключения, надо включить в файл /etc/hosts.deny следующую запись:

portmap : ALL

Затем можно разрешить обращение к portmap отдельных компьютеров или сетей, включая их адреса в файл /etc/hosts.allow.

portmap : 192.168.1.

На заметку

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

Для обеспечения NFS-обмена недостаточно вызвать программу отображения портов. Вам также надо определить разделяемые каталоги (этот вопрос будет рассматриваться в следующем разделе) и запустить сам сервер NFS. Для запуска сервера NFS используется сценарий SysV (обычно он называется nfs). В некоторых версиях Linux приходится также запускать дополнительные сценарии SysV. При инсталляции NFS эти сценарии устанавливаются автоматически. Изменив конфигурацию сервера, необходимо перезапустить его; это можно сделать, используя опцию restart сценария. Соответствующая команда выглядит следующим образом: /etc/rc.d/init.d/nfs restart.

 

Разделение файлов с помощью NFS

 

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

 

Определение экспортируемых каталогов

Для управления сервером NFS используется файл /etc/exports. В этом файле содержится набор записей, каждая из которых определяет экспортируемый каталог. Запись занимает одну строку и имеет следующий формат:

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

Имя экспортируемого каталога может иметь вид /home или /usr/X11R6. Вы можете указать любой каталог, однако некоторые каталоги экспортировать нецелесообразно. Так, например, предоставив доступ к /etc или /proc, вы создадите угрозу безопасности компьютера, так как удаленные пользователи получат доступ к информации, определяющей конфигурацию системы. Некоторым может показаться, что, экспортируя каталог /dev, вы предоставите удаленным пользователям доступ к устройствам сервера, но это не так. Файлы, содержащиеся в этом каталоге, всегда определяют устройства локального компьютера, поэтому, смонтировав /dev, вы получите лишь копии файлов, с помощью которых можно в лучшем случае взаимодействовать с устройствами на клиентской машине. Если конфигурация компьютера, на котором расположен сервер NFS, отличается от конфигурации клиентской машины, то после монтирования /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. Данные опции задают соответственно синхронный и асинхронный режимы выполнения операций. При записи в асинхронном режиме сервер может сообщить клиенту о том, что операция завершена, в то время как запись на диск еще продолжается. Это ускоряет процесс обмена данными, но создает угрозу их целостности; в случае выхода сервера из строя информация будет утеряна. Официально считается, что NFSv2 не поддерживает асинхронные операции, но, несмотря на это, сервер NFS в системе Linux позволял выполнять действия в асинхронном режиме. NFSv3 поддерживает асинхронный режим, а для снижения риска к клиенту предъявляются требования буферизации данных. По умолчанию в серверах NFSv3 предполагается опция async, но в бета-версиях программ NFS для Linux данная опция игнорируется.

• wdelay и no_wdelay. Если сервер NFS, работающий в системе Linux, предполагает, что последующие запросы могут изменить данные, предназначенные для записи на диск, он может отложить на некоторое время процедуру записи. Во многих случаях такой подход позволяет увеличить производительность сервера. Изменить принцип записи можно, указывая опции wdelay и no_wdelay. Опция wdelay предполагается по умолчанию.

 

Средства контроля доступа

Многие из опций, которые указываются для каждого клиента в файле /etc/exports, предназначены для управления доступом. Как было сказано ранее, NFS использует механизм доверия, поэтому сервер не может проверить имя пользователя и пароль, как это происходит в системе Samba. Если клиент объявлен как заслуживающий доверия, то решение о предоставлении доступа принимается на основании сведений о принадлежности файла владельцу и правах. Некоторые из опций управления доступом, встречающиеся в файле /etc/exports, перечислены ниже.

• secure и insecure. По умолчанию сервер NFS считает, что запросы должны поступать с защищенных портов, номера которых не превышают 1023. В системах UNIX и Linux доступ к таким портам имеет только пользователь root (право работы через порты с номерами 1024 и выше предоставлено всем пользователям). Разрешая обращения клиентов, которые используют номера портов, превышающие 1023 (т.е. задавая опцию insecure), вы предоставляете пользователям, не обладающим привилегиями, дополнительный шанс осуществить несанкционированный доступ к серверу. В некоторых случаях, например при тестировании клиентских программ, использование опции insecure может быть оправдано.

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

• hide и nohide. Предположим, что на сервере NFS каталог /usr размещен в одном разделе, а каталог /usr/local — в другом. Если вы экспортируете каталог /usr, должен ли экспортироваться также и каталог /usr/local? Ответ на данный вопрос зависит от используемого сервера. В ядре 2.2.x для этого была предусмотрена специальная опция. В последних версиях сервера NFS вы можете управлять его поведением, задавая опции hide и nohide. Опция hide скрывает смонтированные разделы, а опция nohide выполняет противоположное действие. Некоторые клиенты допускают ошибки в работе со смонтированными разделами, поэтому в ряде случаев приходится задавать опцию hide. При этом клиент должен самостоятельно монтировать оба каталога.

• noaccess. Данная опция запрещает доступ к каталогу, даже если он является подкаталогом экспортируемого каталога. Предположим, например, что вы хотите экспортировать поддерево /home, за исключением каталога /home/abrown. Для этого надо создать в файле /etc/exports обычную запись для каталога /home и отдельную запись для каталога /home/abrown, указав в ней опцию noaccess. В результате пользователи не смогут обращаться к каталогу /home/abrown.

• subtree_check и no_subtree_check. В некоторых случаях приходится экспортировать не весь раздел, а лишь его часть. При этом сервер NFS должен выполнять дополнительную проверку обращений клиентов, чтобы убедиться в том, что они предпринимают попытку доступа лишь к файлам, находящимся в соответствующих подкаталогах. Такой контроль поддерева (subtree checks) несколько замедляет взаимодействие с клиентами, но если отказаться от него, могут возникнуть проблемы с безопасностью системы. Отменить контроль поддерева можно с помощью опции no_subtree_check. Опция subtree_check, включающая такой контроль, предполагается по умолчанию. Контроль поддерева можно не выполнять в том случае, если экспортируемый каталог совпадает с разделом диска.

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

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

• anonuid и anongid. Анонимным пользователем, обращения которого отвергаются, обычно считается пользователь nobody. Вы можете переопределить такую установку, указав идентификатор пользователя (UID) и идентификатор группы (GID). Сделать это позволяют соответственно опции anonuid и anongid. В этом случае пользователю root, работающему на удаленном клиенте, будет предоставлен доступ с привилегиями указанного пользователя. Эти опции также приходится указывать при работе с клиентами PC/NFS, которые поддерживают лишь одного локального пользователя. Такая опция должна сопровождаться знаком равенства и идентификатором пользователя или группы, например

Пример файла /etc/exports показан в листинге 8.1. В этом файле описаны два экспортируемых каталога: /usr/X11R6 и /home. Кроме того, в нем содержится третья запись, запрещающая с помощью опции noaccess обращения к каталогу /home/abrown. (Поскольку последняя запись лишь ограничивает доступ, в ней не указан конкретный узел; обращаться в данному каталогу не может ни один клиент.) Каталоги /usr/X11R6 и /home доступны для компьютера gingko и всех узлов сети 192.168.4.0/24, однако при экспортировании этих каталогов заданы различные опции. Каталог /usr/X11R6 доступен только для чтения, а в каталог /home клиенты имеют также право записывать данные. На компьютере gingko для доступа к /usr/X11R6 задан идентификатор анонимного пользователя, равный 514, а при обмене с каталогом /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, но при ее вызове указываются сервер NFS и монтируемый каталог. Эти данные задаются в формате сервер : путь_к_монтируемому_каталогу . Так, например, следующая команда монтирует экспортируемый каталог /home в точке файловой системы /mnt/userfiles:

# mount larch:/home /mnt/userfiles

Если вы хотите, чтобы экспортируемый каталог был постоянно доступен, вам надо создать запись в файле /etc/fstab. Как и при использовании команды mount, вместо имени устройства вы указываете имя сервера и путь к экспортируемому каталогу. Тип файловой системы задается как nfs (при желании вы можете задать соответствующую опцию и при вызове mount, но это не обязательно, поскольку Linux автоматически распознает тип файловой системы). Приведенная ниже запись в файле /etc/fstab выполняет те же действия, что и рассмотренный ранее вызов утилиты mount.

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

В результате пользователь, обращаясь к каталогу /mnt/userfiles, на самом деле увидит содержимое каталога /home на узле larch. С содержимым смонтированного каталога NFS можно выполнять большинство операций, допустимых для локального раздела Linux. Например, вы можете читать, редактировать и удалять файлы, а также выполнять прочие действия. Существуют также операции, которые недопустимы для экспортируемых каталогов, например, вы не можете объявлять раздел NFS как файл подкачки. В большинстве случаев эффективность работы с экспортируемыми каталогами NFS ниже, чем с разделами локального диска, так как обмен по сети осуществляется значительно медленнее, чем обмен с современными жесткими дисками. Однако в отдельных случаях, например при использовании гигабитовой Ethernet-сети, производительность NFS-обмена может даже превышать производительность работы с локальными устройствами, особенно если на клиентской машине используются устаревшие диски. На производительность системы NFS существенное влияние оказывают также быстродействие диска сервера и число клиентов.

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

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

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

• soft. Если сервер NFS часто выходит из строя и становится недоступным, целесообразно использовать данную опцию. Она позволяет ядру возвращать программе сообщение об ошибке в том случае, если сервер не отвечает в течение установленного времени (это время задается с помощью опции timeo= время ).

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

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

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

Перечисленные опции можно задавать при вызове команды mount, указывая их после -о, например:

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

Если вы создаете запись в файле /etc/fstab, данные опции указываются в специально предназначенном поле (в этом поле в приведенном выше примере находилось ключевое слово defaults.

 

Повышение производительности системы

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

• Оптимизация размера передаваемых блоков. Опции rsize и wsize программы mount определяют размер блоков данных, передаваемых между клиентом и сервером. Размер блока по умолчанию зависит от используемых программ, но чаще всего принимается значение 4096. Команда, в которой явно задается размер блока, выглядит приблизительно так: larch: /home /mnt/userfiles -о rsize=8192. При создании записи в файле /etc/fstab эти опции помещаются в специальное поле (в приведенном ранее примере в этом поле указано значение defaults).

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

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

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

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

 

Отображение пользовательских имен

 

На компьютере под управлением Linux, работающем независимо от других машин, за отображение пользовательских имен в числовые идентификаторы (UID) отвечает файл /etc/passwd. Аналогично, информация о соответствии имен групп и их идентификаторов (GID) хранится в файле /etc/group. В системе NFS существуют как минимум два независимых файла /etc/passwd: один — на сервере и по одному — на каждом клиенте. При этом может возникнуть проблема, связанная с тем, что одному и тому же пользователю на сервере и на клиентской машине будут соответствовать различные UID. Эта проблема может быть решена различными способами.

На заметку

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

 

Согласование идентификаторов пользователей на клиентском компьютере и на сервере

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

# usermod -u 504 abrown

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

Команда groupmod аналогичным образом изменяет информацию о группе. В отличие от команды usermod, новый идентификатор группы задается с помощью опции -g. Например, чтобы задать GID группы project3 равным 127, надо выполнить следующую команду:

# groupmod -g 127 project3

Внимание

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

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

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

 

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

Предположим, что вы занимаетесь администрированием сети, состоящей из двух компьютеров. На каждом узле этой сети существуют учетные записи для пользователей, перечисленных в табл. 8.1. В данном примере компьютер gingko выполняет функции сервера, а компьютер larch выступает в роли клиента. Только у одного из пользователей (james) идентификаторы на обоих компьютерах совпадают. Чтобы пользователь james мог обращаться к своим собственным файлам, никакие специальные меры не требуются. Работая на компьютере larch, alyson обнаружит, что его файлы, хранящиеся на gingko, принадлежат пользователю, идентифицировать которого невозможно (UID, равный 500, на компьютере larch отсутствует). Что касается остальных двух пользователей, Jennie и samuel, система сообщит, что каждый из них является владельцем файлов, принадлежащих на самом деле другому.

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

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

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

Пользователь UID на gingko UID на larch
alyson 500 504
james 501 501
Jennie 502 503
samuel 503 502

Эта запись сообщает системе о том, что, предоставляя каталог /home пользователю larch, надо использовать файл соответствия идентификаторов с именем /etc/nfs/larch-map. Поскольку опция map_static входит в состав списка опций для конкретного клиента, вы можете назначать разным клиентам различные файлы соответствия. Пример содержимого файла larch-map показан в листинге 8.2. Строки, в начале которых находится символ #, содержат комментарии. Строки, начинающиеся с uid, представляют информацию о соответствии пользовательских идентификаторов, а строки, в начале которых расположено ключевое слово gid, содержат сведения о соответствии идентификаторов групп. Первое из числовых значений (или диапазон значений) в строке представляет идентификатор на клиентской машине. Второе числовое значение соответствует идентификатору, в который должен отображаться UID или GID, полученный на удаленном компьютере. Например, из листинга 8.2 видно, что UID 504 на клиентском компьютере отображается в UID 500 на сервере. Если вместо идентификатора на сервере указан символ -, обращение данного пользователя или члена группы к серверу NFS запрещен. Такое обращение интерпретируется как попытка доступа анонимного пользователя.

Листинг 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 поставляется не со всеми системами. Из дистрибутивных пакетов, которые обсуждались в данной книге, она входит только в состав Debian. Во-вторых, демон ugidd приходится устанавливать на всех клиентах, а это занимает много времени. В-третьих, чтобы программа не могла быть использована для несанкционированного доступа, необходимо запретить обращения к ней (это можно сделать, задав требуемую конфигурацию в файле /etc/hosts.allow). И, наконец, что особенно важно, данная программа слишком сложна и в некоторых случаях она вовсе не работает либо отображает всех пользователей в пользователя nobody.

 

Резюме

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

 

Глава 9

Совместное использование принтеров

 

Система печати, используемая в 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.

 

Использование сервера LPD

Сетевая система печати работает подобно средствам разделения файлов. Клиент-программа передает на сервер печати файл, предназначенный для вывода на принтер (это можно сравнить с передачей файла на файловый сервер). Основное отличие между данными процессами заключается в том, что на файловом сервере файл сохраняется на диске для дальнейшего использования, а на сервере печати файл передается на принтер и после обработки удаляется. Сходство между этими двумя задачами приводит к тому, что в некоторых случаях они решаются посредством одного протокола. В качестве примера можно привести протоколы 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-портов, к нему можно подключить несколько принтеров. Мощный компьютер может не только выступать в роли сервера печати, но и выполнять при этом задачи, непосредственно не связанные с выводом на принтер.

 

Серверы печати для Linux

Различные варианты 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, создана для замены BSD LPD. Она отличается от BSD LPD форматом некоторых конфигурационных файлов. Базовая модель печати, согласно которой приложения должны иметь сведения об используемом принтере, осталась неизменной. В системе Linux большинство приложений предполагает, что вывод производится на принтер PostScript.

• Common UNIX Printing System (CUPS). Информация о CUPS находится на сервере http://www.cups.org. Данная система отличается от BSD LPD гораздо больше, чем LPRng, в частности, в ней используется другой набор конфигурационных файлов. Для приложений, специально написанных для взаимодействия с CUPS, эта система предоставляет информацию об используемых принтерах. (Для того чтобы эта информация стала доступной, средства CUPS должны выполняться и на клиентской машине, и на сервере.) Помимо протокола LPD, CUPS также поддерживает протокол печати IPP.

На заметку

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

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

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

Дистрибутивный пакет Стандартная система печати Альтернативная система печати
Caldera OpenLinux Server 3.1 CUPS Отсутствует
Debian GNU/Linux 2.2 BSD LPD LPRng, CUPS
Linux Mandrake 8.1 LPRng CUPS
Red Hat Linux 7.2 LPRng Отсутствует
Slackware Linux 8.0 BSD LPD Отсутствует
SuSE Linux 7.3 LPRng CUPS
TurboLinux 7.0 LPRng Отсутствует

На заметку

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

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

 

Настройка сервера BSD LPD

 

Среди средств настройки сервера BSD LPD наиболее важны два файла: /etc/hosts.lpd и /etc/printcap. В первом из них указываются клиенты, которые могут обращаться к серверу для выполнения сетевых операций. Во втором определяются принтеры, доступные как для локальных, так и для удаленных пользователей. Поскольку в файле /etc/printcap определяются и локальные, и удаленные принтеры, удаленный пользователь может передать задание на печать очереди, которая соответствует удаленной системе. Если это произойдет, задание будет принято по сети, а затем снова передано. В обычных условиях это означает напрасную затрату сетевых ресурсов, но иногда такое поведение может быть оправдано. В качестве примера можно привести ситуацию, при которой сервер печати использует Ghostscript для преобразования PostScript-файла в формат, совместимый с форматом целевого принтера.

 

Редактирование файла /etc/hosts.lpd

По умолчанию система BSD LPD не принимает задания на печать с удаленных компьютеров, т.е. реализующие ее программы не могут выполнять роль сетевого сервера печати. Для того, чтобы изменить конфигурацию системы, необходимо отредактировать файл /etc/hosts.lpd. В этом файле указан список компьютеров, которым разрешен доступ к локальной очереди печати. Для идентификации компьютеров могут использоваться доменное имя, IP-адрес или имя группы NIS. В последнем случае перед именем группы указывается символ @, который, в свою очередь, может предваряться символом +. Символ + означает, что сервер должен принимать любое задание на печать, что небезопасно для системы. Если перед идентификатором узла указан символ -, это означает, что доступ для этого узла запрещен. Пример файла /etc/hosts.lpd приведен в листинге 9.1. При указании компьютера gingko предполагается, что он принадлежит тому же домену, что и сервер. Выражение +@group1 предоставляет доступ всем компьютерам в NIS-группе 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 и другие протоколы. Из соображений безопасности этот файл не рекомендуется; лучше настроить каждый сервер индивидуально. Если этот файл присутствует в системе, желательно удалить его и установить требуемую конфигурацию с помощью других файлов.

 

Указание сервера на клиенте BSD LPD

В файле /etc/printcap содержатся определения принтеров для системы BSD LPD (printcap сокращенно означает printer capabilities — возможности принтеров). В этом файле содержатся записи для каждой очереди печати в системе, независимо от того, является ли очередь локальной (обслуживающей принтеры, подключенные через параллельный, последовательный или USB-порт) или сетевой (обслуживающей другие LPD-принтеры и даже принтеры, доступ к которым осуществляется посредством SMB/CIFS, AppleTalk или других протоколов). Определение каждого принтера располагается в одной строке, а опции разделяются символом :. На практике определение принтера занимает несколько строк; все строки, кроме последней, заканчиваются символом \, который означает, что следующая строка является продолжением предыдущей. Размещенные таким образом данные более удобны для чтения.

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

• lр. Указывает на файл устройства, к которому подключен принтер. Например, выражение lp=/dev/lp0 сообщает системе о том, что для вывода на принтер должно быть использовано устройство /dev/lp0 (первый параллельный порт). Если вы настраиваете сетевой принтер, вам следует удалить эту опцию или не указывать после знака равенства никакого значения (например, lр=).

• rm. Определяет имя сервера печати LPD. Например, если для данной очереди сервером печати является oak, вам надо включить в определение очереди опцию rm=oak. Заметьте, что для организации печати с помощью удаленной очереди этого недостаточно; данная опция лишь идентифицирует компьютер, на котором расположена очередь. Для определения удаленного компьютера можно использовать имя узла (с указанием или без указания доменного имени) или IP-адрес.

• rp. Действие опции rp начинается там, где заканчивается действие опции rm. Опция rp задает имя удаленной очереди печати. Например, если очередь на сервере печати называется inkjet, в файл /etc/printcap на клиентском компьютере надо включить выражение rp=inkjet. Заметьте, что имя удаленной очереди не обязательно должно совпадать с именем локальной очереди. Допустима, например, ситуация, когда принтер inkjet сервера будет называться на стороне клиента lр1 или canon. Рекомендуется во избежание недоразумений синхронизировать имена; в особенности это важно в больших сетях.

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

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

 

Настройка сервера LPRng

 

С точки зрения пользователя система печати LPRng работает так же, как и BSD LPD. Это вполне закономерно, так как средства LPRng были разработаны для замены BSD LPD. LPRng использует файл /etc/printcap, в котором содержится такая же информация, как и в одноименном файле BSD LPD. Однако средства контроля доступа к серверу печати в LPRng реализованы совершенно по-другому. Вместо списка клиентов, которым разрешен доступ, в LPRng используется гораздо более сложная система печати, для управления которой служит файл /etc/lpd.perms.

 

Редактирование файла

/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. Для сравнения, пакеты BSD LPD по умолчанию разрешают доступ только для узла localhost, или 127.0.0.1 (т. е. для компьютера, на котором выполняется данное программное обеспечение). Таким образом, при настройке системы печати LPRng желательно уточнить политику доступа, используя для этого опции ACCEPT и REJECT.

Опции ACCEPT и REJECT задают типы обращений, которые сервер должен соответственно принимать или отвергать. За именем опции следует один из ключей, указанных в столбце Key табл. 9.2, и значения, заданные в остальных столбцах этой таблицы. Столбец Connect определяет способность устанавливать соединения. Столбцы Job Spool и Job Print указывают на возможность передавать задание спулеру и выводить их на печать. В столбцах lpq, lprm и lрс указано, могут ли выполняться задачи, которыми в обычных условиях управляют утилиты с этими именами. В большинстве случаев наличие одной из этих возможностей означает наличие их всех (по крайней мере, тех, которые имеют смысл в конкретном контексте). Некоторые значения несовместимы с определенными ключами (они отмечены в табл. 9.2 символом —). Для того чтобы изменить значение на обратное, надо указать перед ним NOT. IP-адрес может определять всю сеть, после него надо указать символ / и задать маску подсети.

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

Key Connect Job Spool Job Print lpq lprm lpc
SERVICE X R P Q M С или S
USER Имя пользователя Имя пользователя Имя пользователя Имя пользователя Имя пользователя
HOST Удаленный узел Имя узла Имя узла Имя узла Имя узла Имя узла
GROUP Имя пользователя Имя пользователя Имя пользователя Имя пользователя Имя пользователя
IP IP-адрес удаленного узла IP-адрес узла IP-адрес узла IP-адрес удаленного узла IP-адрес узла IP-адрес узла
PORT Номер порта Номер порта Номер порта Номер порта Номер порта
REMOTEUSER Имя пользователя Имя пользователя Имя пользователя Имя пользователя Имя пользователя
REMOTEHOST Удаленный узел Удаленный узел Узел Удаленный узел Удаленный узел Удаленный узел
REMOTEGROUP Имя пользователя Имя пользователя Имя пользователя Имя пользователя Имя пользователя
REMOTEIP IP-адрес удаленного узла IP-адрес удаленного узла IP-адрес узла IP-адрес удаленного узла IP-адрес удаленного узла IP-адрес удаленного узла
CONTROLLINE Шаблон Шаблон Шаблон Шаблон Шаблон
PRINTER Имя принтера Имя принтера Имя принтера Имя принтера Имя принтера
FORWARD
SAMEHOST
SAMEUSER
SERVER

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

ACCEPT SERVICE=M SAMEHOST SAMEUSER

ACCEPT SERVICE=M SERVER REMOTEUSER=root

REJECT SERVICE=M

В этих трех строках указано, кто может использовать утилиту lprm для удаления заданий. В каждой строке содержится опция SERVICE=M, которая означает, что строка соответствует функциям lprm. Это соответствие можно проследить по строке SERVICE табл. 9.2. В первой из указанных трех строк содержатся также опции SAMEHOST и SAMEUSER, которые указывают на то, что команда принимается только в том случае, если она передана с того же компьютера, что и задание на печать, и от того же пользователя, который является владельцем этого задания. В состав второй строки включены опции SERVER и REMOTEUSER=root. Они означают, что пользователь, зарегистрированный на сервере как root, имеет право удалять задания. Последняя строка запрещает обработку прочих запросов, поступающих от lprm. (LPRng просматривает файл 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 привело бы к аналогичному результату). При отсутствии этой строки следующая запись блокировала бы обращения с локального компьютера, что в данном случае нежелательно. Вторая строка отвергает все попытки установить соединения, кроме тех, которые предпринимаются компьютерами, принадлежащими сети 172.22.0.0/16. Если бы у вас возникла необходимость принимать обращения из нескольких сетей, вам бы пришлось включить перед опцией REJECT еще одну опцию ACCEPT и указать для нее адрес дополнительной сети, компьютеры которой имели бы право устанавливать соединения с сервером.

 

Указание LPRng-сервера на стороне клиента

Файл /etc/printcap в системе LPRng используется аналогично одноименному файлу в системе BSD LPD. В частности, опции lp, rm и rp, которые обсуждались выше в данной главе, применимы как в BSD LPD, так и в LPRng. Большинство других опций также может присутствовать в обеих системах, но некоторые из них интерпретируются по-разному. Обсуждение этих различий выходит за рамки данной книги.

Системы BSD LPD и LPRng используют протокол LPD, поэтому вы можете сконфигурировать клиент LPRng для печати на сервере BSD LPD и наоборот. Подобное взаимодействие можно также организовать с системой CUPS. Кроме того, 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/) и ESP Print Pro (http://www.easysw.com/printpro/). CUPS также можно настраивать, пользуясь Web-броузером, для этого надо запустить броузер на локальном компьютере и обратиться по адресу http://localhost:631.

На заметку

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

 

Редактирование файла

/etc/cups/cupsd.conf

Работой сервера CUPS управляет файл /etc/cups/cupsd.conf. Поскольку система CUPS позаимствовала многие средства сервера HTTP, структура ее конфигурационного файла напоминает соответствующий файл Apache (он будет рассмотрен в главе 20). При работе CUPS также применяются другие конфигурационные файлы, в частности /etc/cups/printers.conf и /etc/cups/classes.conf, которые описывают соответственно принтеры и группы принтеров. Для редактирования обоих файлов используется инструмент lpadmin, а данные в файле cupsd.conf рекомендуется подготавливать вручную.

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

• Allow. За этой директивой следуют ключевое слово from, идентификатор All или None, имя узла (в котором может содержаться звездочка, задающая групповую операцию), частичный или полный IP-адрес или IP-адрес с указанием маски сети. Независимо от формы записи, значение данной директивы определяют компьютеры, которые имеют право доступа к серверу. Чтобы разрешить доступ для нескольких компьютеров или групп компьютеров, вы можете использовать несколько директив Allow. Данная директива должна находиться в составе директивы Location.

• AuthClass. Директива AuthClass может принимать значения Anonymous (значение по умолчанию), User, System и Group. Anonymous означает, что аутентификация клиентов не должна выполняться; в этом случае система печати работает подобно системе BSD LPD. Остальные три значения требуют от клиента указания пользовательского имени и пароля. Значение System требует, чтобы пользователь был членом группы sys, заданной с помощью директивы SystemGroup. Если указано значение Group, пользователь должен принадлежать группе, имя которой определено посредством директивы AuthGroupName.

• BrowseAddress. Средства просмотра принтеров CUPS лучше всего работают в том случае, если информация о принтерах, доступных в сети, собрана на центральном сервере. Этот сервер можно задать с помощью директивы BrowseAddress. В качестве ее значения задается доменное имя или IP-адрес, а также номер порта, например 192.168.23.34:631. (Номер порта 631 чаще всего используется для выполнения различных операций с системой CUPS.) По умолчанию принимается значение 255.255.255.255:631, т.е. широковещательный адрес локальной сети и порт 631.

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

• BrowseDeny. Данная директива выполняет действие, противоположное директиве BrowseAllow. С ее помощью формируется "черный список" клиентов или сетей.

• BrowseOrder. Если вы используете и BrowseAllow, и BrowseDeny, директива BrowseOrder позволяет определить порядок применения указанных директив. Она может быть задана в виде BrowseOrder Allow, Deny или BrowseOrder Deny, Allow.

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

• BrowsePoll. Данная директива позволяет задавать имя или IP-адрес сервера печати для опроса принтеров. Чтобы опрашивать несколько серверов, вы можете указать данную директиву несколько раз.

• BrowsePort. По умолчанию для просмотра принтеров используется порт 631, но с помощью данной директивы вы можете переопределить это значение.

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

• Browsing. Задавая значение этой директивы, равное On или Off, вы можете соответственно разрешать или запрещать просмотр сети. По умолчанию предполагается значение On.

• Deny. Данная директива выполняет действия, противоположные действиям директивы Allow. С ее помощью задаются компьютеры, которым запрещен доступ к серверу. Директива Deny должна присутствовать в составе директивы Location.

• HostNameLookups. Данная директива может принимать значения Off, On и Double. Значение Off запрещает проверку имен клиентов, On включает проверку имени каждого клиента, если же задано значение Double, проверяется имя клиента, а по полученному имени определяется его IP-адрес. Значение Double обеспечивает защиту от некоторых типов атак, поскольку при этом отвергаются обращения клиентов, для которых некорректно сформированы записи на сервере DNS. По умолчанию предполагается значение при этом обеспечивается максимальная производительность и надежность (остальные значения могут приводить к возникновению проблем в случае выхода из строя сервера DNS).

• Listen. Задавая одну или несколько директив Listen, вы можете сообщить CUPS о том, что процессе взаимодействия должны использоваться лишь некоторые из сетевых интерфейсов. В качестве значения данной директивы задается IP-адрес сетевого интерфейса и номер порта (обычно 631). Например, выражение Listen 192.168.23.8:631 означает, что компьютер должен использовать интерфейс с адресом 192.168.23.8. С помощью директивы Listen можно учесть все необходимые интерфейсы; в большинстве случаев необходимо указывать также интерфейс с адресом 127.0.0.1.

• Location. Данная директива отличается от остальных; она объединяет ряд других директив и указывает область их применения. Например, в состав Location вы можете включить директивы Allow и Deny, разрешая или запрещая для клиентов обращение к конкретным типам документов (и, следовательно, выполнение определенных типов операций). Началом данной директивы является ключевое слово Location, помещенное в угловые скобки, а окончанием — выражение . В составе могут присутствовать опции /admin (действия по администрированию), /classes (определение классов принтеров), /jobs (определение заданий на печать) и /printers (принтеры).

• MaxClients. Директива MaxClients позволяет ограничить число клиентов, которые могут устанавливать соединение с сервером. По умолчанию принимается значение, равное 100.

• Order. Данная директива выполняет действия, аналогичные действиям директивы BrowseOrder, но применяется к директивам Allow и Deny. Выражение Order Allow, Deny означает, что директива Allow должна применяться перед директивой Deny, а выражение Order Deny, Allow задает обратную последовательность применения этих директив.

• Port. В обычных условиях CUPS ожидает обращение через порт 631, но при необходимости вы можете с помощью данной директивы изменить порт, используемый по умолчанию. Указывая данную директиву многократно, можно задать несколько портов. Заметьте, что директива Port не влияет на номер порта, используемый CUPS для взаимодействия с клиентами и серверами BSD LPD и другими подобными программами.

Файл /etc/cups/cupsd.conf, поставляемый с большинством пакетов CUPS, оставляет сервер совершенно открытым для обращений с внешних узлов. Подготавливая средства CUPS к реальной работе, необходимо ограничить доступ к серверу. Например, приведенная ниже директива блокирует доступ со всех узлов, за исключением компьютера, на котором расположен сервер, а также компьютеров, принадлежащих сети 172.22.0.0/16.

 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 указана опция /printers, она не блокирует полностью доступ к серверу. Например, выполнение административных задач (опция /admin) и доступ к информации о заданиях на печать (опция /jobs) разрешены и для других систем. Настраивая CUPS, необходимо ограничить все виды доступа и даже продублировать ограничения, сконфигурировав соответствующим образом средства фильтрации пакетов (они будут рассматриваться в главе 25).

 

Получение заданий от клиентов BSD LPD и LPRng

Рассмотренные выше директивы, предназначенные для включения в файл /etc/cups/cupsd.conf, в основном имеют отношение к клиентам, поддерживающим IPP. Этот протокол не использует ни BSD LPD, ни LPRng; данные системы применяют в работе протокол LPD. (В настоящее время ведутся работы по включению средств поддержки IPP в состав LPRng, но они еще не завершены.) Как было сказано выше в данной главе, серверы печати CUPS могут получать задания на печать от клиентов, использующих протокол LPD. Для этого в состав CUPS включена вспомогательная программа cups-lpd.

Программа cups-lpd не может выполнять функции независимого сервера, ее необходимо сконфигурировать для работы с суперсервером inetd или xinetd (суперсерверы и взаимодействие с ними рассматривались в главе 4). Программа cups-lpd обычно располагается в каталоге /usr/lib/cups/daemon, а соответствующая ей запись в конфигурационном файле /etc/inetd.conf выглядит следующим образом:

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

 cups-lpd

Учитывая различия между inetd и xinetd, описанные в главе 4, вы можете легко сконфигурировать cups-lpd для работы с xinetd. В некоторых случаях пакет CUPS поставляется уже сконфигурированным для взаимодействия с клиентами BSD LPD, в этом случае нет необходимости предпринимать специальные меры по его настройке.

Внимание

В CUPS не предусмотрены никакие средства для контроля доступа клиентов, использующих протокол LPD. При передаче заданий от таких клиентов используется адрес сервера, и директивы в файле /etc/cups/cupsd.conf не оказывают никакого влияния на ход взаимодействия. Для того чтобы ограничить доступ к серверу CUPS с внешних узлов, надо настроить соответствующим образом брандмауэр или использовать другие механизмы ограничения доступа.

 

Определение сервера CUPS на стороне клиента

Для добавления принтеров к системе CUPS используется утилита lpadmin, вызываемая из командной строки или доступная посредством специального графического интерфейса. Кроме того, эта задача может решаться с помощью Web-броузера; для этого надо запустить Web-броузер на компьютере, на котором расположен сервер, и обратиться с его помощью по URL http://localhost:631. (Вы можете также запустить броузер и на другом узле, для которого разрешено выполнение задач администрирования, в этом случае вместо localhost необходимо указать имя компьютера, на котором выполняется сервер CUPS.) Используя любой из описанных здесь способов, вы можете добавлять или удалять принтеры или выполнять другие действия по администрированию сервера. Ниже приведен пример вызова утилиты lpadmin.

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

 -m ppdfile.ppd

В данном примере Имя_Принтера — это имя очереди печати, используемой локально, имя_сервера — это имя узла, на котором установлен сервер печати, а имя_очереди — имя очереди на этом сервере. Поскольку в качестве протокола указано имя доступ к очереди печати осуществляется посредством протокола LPD. Для использования другого протокола надо вместо lpd задать имя ipp. (Аналогичным способом вы можете задать локальную очередь, но в качестве значения опции -v необходимо указать parallel:/dev/lp0 или задать идентификатор другого локального устройства.) Опция -m определяет PPD-файл для принтера, при этом CUPS может передавать приложению информацию о возможностях принтера. В состав большинства пакетов включается набор файлов PPD; они располагаются в каталоге /usr/share/cups/model. Файлами PPD снабжаются также многие принтеры PostScript. Для получения файла PPD вы можете воспользоваться списком драйверов по адресу http://www.linuxprinting.org/driver_list.cgi. Щелкните на имени драйвера Ghostscript, затем выберите модель вашего принтера в области CUPS-O-Matic и щелкните на Generate CUPS PPD. Через некоторое время вы получите файл PPD, описывающий возможности вашего принтера. Как сказано в комментариях, этот автоматически сгенерированный файл не свободен от недостатков, более того, не исключено, что он вовсе не будет работать. Поэтому, если это возможно, лучше использовать файлы PPD, поставляемые производителями принтеров.

Совет

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

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

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

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

 

Резюме

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

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

 

Глава 10

Служба времени

 

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

 

Использование временного сервера

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

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

 

Настройка сервера NTP

 

Из протоколов, обеспечивающих работу временных серверов, наиболее популярен NTP (Network Time Protocol — сетевой протокол времени), который описан в документе RFC 1305 (http://www.ietf.org/rfc/rfc1305.txt). Рассмотрению более старых версий этого протокола посвящены документы RFC 958, RFC 1059 и RFC 1119. На момент написания данной книги, т.е. в 2002 году, последней версией NTP была версия 4, но версия 3 продолжала широко использоваться. Основной Web-узел NTP располагается по адресу http://www.eecis.udel.edu/~ntp/. NTP поддерживает иерархическую структуру временных серверов, в которой сервер, непосредственно получающий данные об эталонном времени, предоставляет их серверам, взаимодействующим с ним; те, в свою очередь, обслуживают другие серверы и т.д. до тех пор, пока информация о времени не доставляется клиентам. Серверы и клиенты NTP разработаны для различных операционных систем, в частности для Linux. Чтобы настроить сервер NTP для работы в системе Linux, необходимо отредактировать лишь один конфигурационный файл. Контроль за действиями сервера осуществляется с помощью специальных инструментов. На компьютерах, находящихся на самом нижнем уровне иерархии 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 или другой файл с подобным именем), в котором он хранит данные об ошибке или о "дрейфе" системного таймера. Информация в этом файле помогает серверу компенсировать ошибку системных часов в том случае, если компьютер на длительное время остается выключенным или если вышестоящий сервер NTP не доступен.

Совет

Если ошибка превышает 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; в этом случае на аппаратном таймере устанавливается локальное время. Если на вашем компьютере показания времени хранятся в формате UTC, то при вызове данной команды надо заменить --localtime на --utc.

 

Временные серверы для Linux

Сервер NTP для работы в Linux реализуется с помощью программы ntp или ее разновидностей: xntp, xntp3 и xntpd. Символ x в начале имени означает "экспериментальный" (experimental), что не совсем верно, так как эти программы успешно используются в течение нескольких лет. В именах программ, содержащихся в пакете NTP 4, символ x отсутствует. В составе большинства версий Linux поставляется версия 4 пакета NTP, но нередко встречается также версия 3.

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

• ntpd. Основная программа, реализующая сервер NTP. (В некоторых поставках она называется xntpd.) Как было сказано ранее, несмотря на то, что эта программа считается сервером, она объединяет в себе функции клиента и сервера. Для вышестоящих серверов она является клиентом, а для нижележащих программ — сервером. (Вышестоящим считается сервер с меньшим значением уровня.)

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

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

• ntpq. Данная программа осуществляет NTP-мониторинг. Она будет рассмотрена далее в этой главе.

• xntpdc. Эта программа также предназначена для мониторинга и управления системой NTP. Она позволяет выполнять более сложные операции, чем ntpq.

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

 

Структура конфигурационного файла

ntp.conf

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

• server адрес [key ключ ] [version номер ] [prefer] . Данная опция задает имя сервера, который используется для синхронизации показаний времени с помощью протокола NTP. В качестве адреса может быть задан IP-адрес или имя узла. При необходимости в файл ntp.conf можно включить несколько опций server, в результате ваш сервер NTP установит соединение с каждым из указанных серверов и выберет для синхронизации наилучший из них. В составе данной опции может задаваться дополнительная информация. Значение, следующее после key, определяет ключ аутентификации, оно указывается, если доступ к серверу ограничен. Номер версии сообщает о том, какая версия протокола должна быть использована при взаимодействии. Ключевое слово prefer указывает, что данный сервер предпочтительнее других.

• fudge адрес stratum номер . Данная опция в основном используется для того, чтобы указать, что сервер 127.127.1.0 (локальные системные часы) должен интерпретироваться как сервер уровня 7 — сервер NTP с самым низким приоритетом. Это позволяет серверу продолжать работу даже в том случае, если другие серверы недоступны.

• driftfile имя_файла . Указанный в качестве значения данной опции файл включает информацию, которая используется при возобновлении работы после длительного отключения компьютера. Содержимое данного файла позволяет серверу NTP компенсировать погрешность внутреннего таймера и увеличить точность при работе в автономном режиме.

• broadcast адрес [key ключ ] [version номер ] [ttl номер ] . Если вы укажете данную опцию, сервер будет периодически передавать в широковещательном режиме данные о текущем времени. Информация будет передаваться по сети, адрес которой является значением данной опции (это может быть также адрес группового вещания 224.0.1.1). Использование широковещательного адреса позволяет уменьшить трафик в больших сетях, в которых многие серверы NTP работают в качестве клиентов.

• broadcastclient [yes|no]. Данная опция указывает серверу NTP на то, что он должен принимать широковещательные сообщения от других локальных серверов NTP.

В файле ntp.conf могут быть указаны и другие опции, с помощью которых задаются специальные функции. Информацию о них можно получить в документации, представленной в формате HTML, которая поставляется в составе пакета и обычно находится в каталоге /usr/share/doc/xntp- версия .

Файл ntp.conf, поставляемый в составе дистрибутивного пакета, практически обеспечивает работу сервера. Вам надо лишь добавить одну или несколько опций server, указывающих на серверы NTP. К выбору сервера надо подходить очень внимательно. Если сервер, используемый для синхронизации, расположен далеко или работает ненадежно или синхронизирован с помощью некорректного источника, показания системных часов на компьютеров вашей сети будут неточными. Как было сказано ранее, для небольшой сети в качестве источника синхронизирующих данных целесообразно выбирать сервер уровня 2. Этот вопрос интенсивно обсуждается в сети; материалы дискуссий вы можете найти по адресу http://www.eecis.udel.edu/~mills/ntp/servers.htm. В конце этого документа даны ссылки на Web-страницы, содержащие списки временных серверов уровней 1 и 2. Постарайтесь использовать для синхронизации сервер, расположенный ближе других. Заметьте, что топология сетей отличается от географического размещения компьютеров. Так, например, компьютер, расположенный на другом континенте, может быть "ближе" к локальной машине, чем компьютер, находящийся в часе езды от нее.

Совет

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

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

Если вы приобретете GPS либо другое устройство, позволяющее принимать эталонные данные времени, вы можете установить в своей сети сервер уровня 1. Для работы с таким оборудованием вам понадобятся специальные драйверы. Эти драйверы устанавливают принадлежность устройства сети 127.127.0.0/16, в результате для работы с ним можно использовать обычную опцию server. Дополнительную информацию об использовании указанных устройств вы можете найти в документации на драйверы Linux. Сведения о производителях устройств, позволяющих получать сигналы эталонного времени, приведены в документе http://www.eecis.udel.edu/~ntp/hardware.html.

После редактирования ntp.conf надо перезапустить сервер NTP. Сделать это можно с помощью сценария запуска SysV (подробно вопрос использования сценариев SysV обсуждался в главе 4). Если в сценарии запуска не предусмотрен вызов ntpdate, перезапуск ntpd не приведет к резкому изменению показаний системных часов, даже если компьютер был выключен в течение нескольких минут. Вначале ntpd несколько раз сравнит показания системных часов с данными, предоставленными удаленным сервером, а лишь затем предпримет меры для коррекции системного времени. Вопросы контроля операций, выполняемых ntpd, будут обсуждаться в следующем разделе.

 

Контроль операций NTP

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

• host имя_узла . По умолчанию ntpq опрашивает сервер, находящийся на локальном компьютере. Задавая команду host, можно использовать данную программу для проверки любого сервера NTP в сети. Аналогичный результат можно получить, задавая имя целевого узла при вызове ntpq, например ntpq remote.threeroomco.com.

• hostnames [yes | no]. Если вы укажете опцию yes, программа ntpq, сообщая о действиях удаленных компьютеров, будет отображать имена узлов (подобная конфигурация предусмотрена по умолчанию). Опция no указывает на то, что вместо имен должны отображаться IP-адреса. Такой же эффект вызовет опция -n, заданная при вызове программы ntpq.

• ntpversion номер_версии . Данная команда позволяет указать версию протокола NTP, которая будет использоваться при передаче запросов серверу NTP.

• quit. Данная команда задается после окончания работы с программой ntpq и завершает ее выполнение.

• peers. Данная команда предоставляет одно из самых мощных средств диагностики. Она отображает список серверов, с которыми взаимодействует ваш сервер. Если вы предварительно не задали команду host, в этом списке будут содержаться сервер на локальном компьютере и все серверы, указанные в файле ntp.conf. Кроме того, при вызове этой команды будет отображена дополнительная информация, в частности, серверы, используемые для синхронизации; уровень каждого сервера; время последнего обращения к каждому серверу и интервал между обращениями; числовой код, отражающий надежность соединения между компьютерами; задержка, смещение и погрешность синхронизации. В начале каждой записи отображается символ, указывающий на то, каким образом ваш сервер использует данные, предоставляемые другими серверами. Символ + означает, что сервер рассматривался как претендент на роль источника синхронизации, но вместо него был выбран другой сервер; символ * указывает на то, что сервер является вышестоящим по отношению к вашему серверу; символ × определяет "испорченные часы" — сервер, показания которого признаны неверными. Кроме того, ntpq может отображать другие символы, определяющие различные характеристики серверов. Разновидностями команды peers являются lpeers (она может отображать информацию о большем количестве серверов) и opeers (не выводит имена серверов, с которым взаимодействует ваш сервер).

• associations. Данная команда выводит статистику соответствия для каждого сервера. Серверы указываются не с помощью имен или IP-адресов, а посредством идентификаторов соответствия, используемых в других командах. Разновидностями этой команды являются lassociations,passociations и lpassociations.

• readvar идентификатор_соответствия имя_переменной . Эта команда позволяет читать содержимое переменной. Она чаще всего применяется при отладке. Синонимом readvar является rv, a mreadvar представляет собой разновидность этой команды.

• readlist идентификатор_соответствия . Данная команда действует подобно readvar, но выводит список всех стандартных переменных. Синонимом readlist является rl, a mreadlist представляет собой разновидность этой команды.

• pstatus идентификатор_соответствия . Команда pstatus запрашивает информацию о состоянии системы. Результат выполнения данной команды практически совпадает с результатом команды readlist.

• writevar идентификатор_соответствия имя_переменной . Данная команда позволяет изменить значение переменной. Как правило, в ее использовании не возникает необходимости.

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

Рис. 10.1. Программа ntpq отображает информацию о состоянии NTP-сервера

Если вы заметите, что показания системных часов изменяются странным образом, имеет смысл вызвать программу ntpq и проверить текущее состояние сервера. Возможно, он не получает синхронизирующих данных из-за изменения IP-адреса сервера или вследствие нарушения работы сети. (Эпизодические сбои при обмене данными по сети не могут серьезно повлиять на работу временного сервера. Он лишь переключится на использование внутреннего таймера, а затем при возобновлении работы сети снова станет действовать в обычном режиме.) Если в течение нескольких минут после запуска ntpd сервер не сможет синхронизировать свои данные с одним из внешних временных серверов, вам следует проверить работу сети. Доступен ли удаленный сервер для пакетов, передаваемых с помощью программы ping? He блокирует ли брандмауэр запросы NTP? (Возможно, вам придется перенастроить брандмауэр для прохождения пакетов UDP, адресованных на порт 123.) Имеете ли вы право обращаться к удаленному серверу? (Не исключено, что на этом сервере используется брандмауэр или установлен ключ аутентификации.)

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

В большинстве компьютеров работа внутреннего таймера основана на использовании генератора — электронного устройства, вырабатывающего периодический сигнал. Например, сигнал с частотой 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, расположенному в локальной сети. В результате во всей сети будет поддерживаться точное время, а трафик, связанный с NTP-обменом будет относительно невелик. На каждом из компьютеров такой сети будет выполняться программа ntpd, но на всех машинах, кроме одной, она выступит в роли клиента. В сложной сети вы можете организовать несколько уровней серверов NTP. Например, для обслуживания клиентов в каждой подсети можно установить отдельный сервер NTP, а один из них настроить так, чтобы он обращался за сведениями о текущем времени в Internet. Такой подход минимизирует трафик NTP в локальной сети.

На подавляющем большинстве компьютеров используется лишь незначительная часть возможностей, предоставляемых ntpd. Эта программа синхронизирует показания системных часов на узлах локальной сети с точностью до миллисекунд и обеспечивает отклонение от UTC меньше секунды. Кроме того, программа ntpd работает постоянно и корректирует "дрейф" часов в течение дня. Но, как правило, потребности пользователей, работающих в сети, гораздо скромнее, для них вполне допустима погрешность в несколько секунд. Заметьте также, что ntpd представляет собой сервер и при работе этой программы на компьютере возникает определенная угроза безопасности системы. Если в программе будет обнаружена ошибка, создающая "лазейку" для злоумышленников (а подобные ошибки были выявлены в ранних реализациях сервера), ваш компьютер окажется открытым для всех пользователей локальной сети, а возможно, и для всей Internet. По этой причине ntpd в некоторых случаях целесообразно заменить программой ntpdate. В качестве клиента службы времени также может применяться программа rdate, но она использует отдельный протокол и уступает ntpdate в точности.

На заметку

В настоящий момент разработчики NTP занимаются модернизацией программы ntpd . Они реализуют в ней возможность однократной коррекции времени так, как это происходит при использовании ntpdate . В последующих версиях NTP программа ntpdate не будет поставляться. Уже сейчас некоторые пакеты NTP 4 распространяются без ntpdate .

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

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

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

• -о версия . С помощью этой опции вы можете указать программе версию NTP для использования.

• -р число_показаний_времени . В обычных условиях ntpdate устанавливает системные часы на основании четырех показаний времени, полученных с сервера.

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

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

• -s. Данная опция применяется при запуске программы с помощью инструмента cron.

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

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

Для периодического запуска программы ntpdate часто используется инструмент cron. В большинстве случаев достаточно запускать ntpdate один раз в сутки, но если необходима более высокая точность, ее можно вызывать чаще, например, один раз в день. Периодическое выполнение ntpdate уменьшит NTP-трафик по сравнению с использованием ntpd.

Внимание

Если вы используете для синхронизации времени общедоступный сервер, не планируйте вызов ntpdate на полуночь. Почему-то многие администраторы считают, что полночь — наилучшее время для коррекции системных часов, в результате в это время на сервер обрушивается лавина запросов. Указывайте для вызова ntpdate любое другое подходящее время, например 1:23 или 3:48. Это обеспечит более равномерную нагрузку на сервер, а ваша служба времени будет работать более точно и надежно, так как при обращении к серверу не возникнут непредвиденные задержки.

 

Использование Samba для предоставления данных о времени

 

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

 

Опция временного сервера в конфигурационном файле Samba

Как вы уже знаете, конфигурационный файл smb.conf используемый для настройки сервера Samba, состоит из нескольких разделов, большинство из которых описывает разделяемые каталоги. Однако первый раздел с именем [global] содержит установки по умолчанию, а также опции, которые не могут быть включены в описания разделяемых объектов. Одна из этих опций, time server, позволяет активизировать временной сервер. Для этого надо включить в файл smb.conf следующее выражение:

time server = Yes

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

На заметку

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

 

Настройка Windows-клиента для автоматической коррекции системного времени

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

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

В данном случае SERVER — это NetBIOS-имя сервера Samba. Как и при использовании программы ntpdate в системе Linux, вы можете ввести данную команду вручную. Возможно, вы предпочтете, чтобы эта команда выполнялась при загрузке системы или при регистрации пользователя в ней. Для этого надо включить ее в файл .ВАТ (он может называться, например, SETTIME.ВАТ) и скопировать этот файл в папку Startup. Если ваша сеть состоит из доменов, вы можете включить данную команду в состав сценария регистрации, используемого по умолчанию. (Из AUTOEXEC.BAT ее вызывать нельзя, поскольку при выполнении этого файла сетевые средства еще не запущены.)

На заметку

Windows 2000 и XP обеспечивают непосредственную поддержку NTP. Команда NET TIME /SETSNTP: NTP_сервер позволяет выполнять синхронизацию времени с использованием сервера NTP_сервер . В состав этих систем входит даже полнофункциональный сервер NTP, но обсуждение его конфигурации выходит за рамки данной книги.

 

Резюме

Временной сервер дает возможность синхронизировать показания системных часов компьютеров вашей сети друг с другом, а также с внешним сервером, который, в свою очередь, получает сведения от эталонного источника времени. Использование временного сервера позволяет устранить проблемы, возникающие из-за неодинаковой настройки системных часов разных узлов сети. Одним из самых популярных протоколов, предназначенных для обеспечения работы временных серверов, является NTP. Сервер, поддерживающий NTP (обычно он реализуется с помощью программы ntpd или xntpd), работает постоянно и периодически сверяет свои данные о времени со сведениями, полученными от других серверов NTP. В небольших сетях достаточно установить один сервер NTP уровня 3, синхронизировав его с сервером уровня 2 (выше такого сервера в иерархии NTP находятся сервер уровня 1 и источник эталонных данных о времени). Для синхронизации клиентских компьютеров с сервером уровня 3 используется ntpd либо клиентская программа ntpdate. В больших сетях целесообразно установить несколько серверов NTP и даже источник эталонных данных, например устройство GPS.

Для получения данных о времени и коррекции системных часов предназначены также клиент-программа rdate и временной сервер SMB/CIFS, реализованный в пакете Samba. Для этой же цели служит команда NET системы Windows. Команду NET можно использовать для коррекции системных часов клиентского компьютера под управлением Windows, не инсталлируя на нем программное обеспечение NTP.

 

Глава 11

Получение почты: протоколы POP и IMAP

 

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

На заметку

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

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

 

Использование серверов доставки почты

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

• Вы можете предоставить пользователям возможность просматривать корреспонденцию непосредственно на почтовом сервере. Для этого могут быть использованы такие Linux-программы, как pine, mutt или KMail. Эти утилиты имеют непосредственный доступ к поступающей на сервер почте, и для их работы не требуется дополнительное программное обеспечение. Пользователи должны регистрироваться либо непосредственно на почтовом сервере, либо осуществлять удаленную регистрацию с помощью протоколов Telnet, SSH (Secure Shell — защищенная оболочка) или специальных средств X Window. (Вопросы удаленной регистрации будут подробно рассмотрены в главах 13 и 14.)

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

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

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

 

Принцип действия протоколов POP и IMAP

 

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

 

Функции протоколов получения почты

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

В отличие от многих других протоколов, при доставке электронных писем некоторые серверы используются в качестве ретрансляторов (relay). Вместо того чтобы доставить письмо непосредственно на компьютер адресата, почтовая система пытается передать его на компьютер, расположенный как можно ближе к адресату. Строго говоря, почтовая система в принципе не может доставить письмо на компьютер пользователя, так как в почтовом адресе отсутствует информация об этом компьютере. Предположим, например, что вы передаете сообщение по адресу [email protected]. Анализируя записи сервера DNS, можно выяснить, что это письмо должно быть передано на компьютер mail.threeroomco.com. Не исключено, что соответствующие средства на этой машине сконфигурированы так, что письмо будет перенаправлено на другой компьютер, например gingko.threeroomco.com. Если пользователь применяет протокол получения почты, он может обращаться за своими письмами с удаленной машины, например larch.threeroomco.com. При подготовке письма вы пользуетесь специальным почтовым клиентом (предположим, что он выполняется на компьютере trilobite.pangaea.edu). Этот клиент сконфигурирован для работы с определенным сервером передачи почты (например, franklin.pangaea.edu). Сервер, в свою очередь, может быть сконфигурирован для передачи писем через ретранслятор (пусть ретранслятор имеет адрес osgood.pangaea.edu). В результате в процессе доставки сообщения от отправителя к получателю участвует достаточно длинная цепочка почтовых серверов. Условно путь, который проходит письмо, представлен на рис. 11.1. Большинство серверов передачи использует протокол SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты). При условии, что сетевые средства и программы-серверы функционируют нормально, почтовое сообщение быстро преодолеет путь от trilobite.pangaea.edu к gingko.threeroomco.com. На компьютере gingko.threeroomco.com, который является предпоследним в цепочке, письмо может задержаться на неопределенно долгое время, так как сервер получения не сможет передать его до тех пор, пока клиент (в данном случае это программа на компьютере larch.threeroomco.com) не обратится к серверу. По этой причине компьютеры, на которых устанавливаются серверы получения, должны быть оснащены жесткими дисками большого объема, которые необходимы для хранения писем. Эти требования предъявляются как к серверам POP, так и к серверам IMAP.

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

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

Следует помнить, что сервер получения не используется для передачи почты. Передачей сообщений занимаются другие серверы, реализующие SMTP или другой протокол аналогичного назначения. Но на компьютере может присутствовать как сервер передачи, так и сервер получения. Поэтому пользователь может передавать и получать письма посредством одного и того же узла сети, но использовать при этом различные протоколы. В некоторых случаях сервер передачи и сервер получения располагаются на разных компьютерах. Например, на узле franklin.pangaea.edu может быть установлен сервер SMTP, используемый для передачи писем, а на компьютере ponyexpress.pangaea.edu — сервер получения (POP или IMAP). На узле ponyexpress.pangaea.edu также может присутствовать сервер SMTP, но использоваться лишь для получения почты от других серверов передачи.

 

Хранение писем на стороне клиента и на стороне сервера

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

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

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

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

 

Пример сеанса взаимодействия по протоколу POP

На самом деле POP — это несколько взаимодействующих между собой протоколов. На сегодняшний день наиболее популярна версия POP-3, которая использует TCP-порт 110. (Более ранняя версия POP-2 использовала порт 109.) Подобно многим другим протоколам, применяемым в Internet, POP-взаимодействие основано на обмене текстовыми сообщениями между клиентом и сервером. В POP-3 предусмотрено более десяти команд. Среди них можно отметить команды USER (указание имени пользователя), PASS (указание пароля), RETR (получение сообщения), DELE (удаление сообщения) и QUIT (завершение сеанса). Пример простого сеанса POP-взаимодействия, в ходе которого клиент получает с сервера одно письмо, представлен в листинге 11.1. В данном примере для обращения к серверу POP-3 и ввода необходимых команд вручную использовалась клиентская программа 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:

Delivered-To: [email protected]

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

[192.168.1.1])

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

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

Message-Id: <[email protected]>

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

From: [email protected]

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). Протоколом POP не предусмотрена передача части сообщения: оно должно передаваться целиком либо не передаваться вовсе. Средства определения длины сообщения, адреса отправителя и получения другой информации в данном протоколе отсутствуют. Интересующие вас характеристики письма можно узнать лишь после того, как оно будет скопировано на клиентскую машину. В данном примере объем заголовка (в котором указывается адрес отправителя, дата и другие сведения) превышает объем тела сообщения. При передаче реальных писем тело сообщения, как правило, значительно больше его заголовка.

На заметку

Анализируя заголовок письма в листинге 11.1, нетрудно заметить одну особенность, которая обеспечивает гибкость в работе почтовой системы, но в то же время затрудняет определение реального отправителя письма. В полях From: и Return-Path: указано, что отправителем письма является пользователь [email protected] . Тем не менее эти поля заголовка нетрудно подделать. Кроме того, в заголовке каждого письма присутствует поле Received: , в котором указан сервер, использованный при получении письма, и адрес, с которого письмо попало на этот сервер. Я отправил это сообщение с одного компьютера, подключенного к моей сети, на другой компьютер; этот факт отражен в поле Received: . Как видно из листинга, письмо отправлено с speaker.rodsbooks.com и доставлено на nessus.rodsbooks.com . Компьютер pangaea.edu в передаче письма не участвовал.

 

Пример сеанса взаимодействия по протоколу IMAP

Как и 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: [email protected]

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

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

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

Message-Id: <[email protected]>

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

From: [email protected]

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. Эта особенность скрыта от пользователя, так как обработка команд полностью производится клиентской программой. IMAP позволяет копировать заголовки отдельно от текста сообщений (команды A3 и A4 в приведенном листинге). Использование папок предполагает выбор нужной папки в ходе сеанса взаимодействия (команда A2), но пользователь получает возможность копировать письма из одной папки в другую (команда A5). В листинге 11.2 представлена лишь часть возможностей IMAP. Существует много разновидностей приведенных команд, в частности, различные способы обработки писем обеспечиваются с помощью команды FETCH. Дополнительные сведения о протоколе IMAP можно получить в специальных документах, один из которых находится по адресу http://www.ietf.org/rfc/rfc2060.txt.

Несмотря на то что рассмотрение низкоуровневых команд позволяет получить представление о работе IMAP, вам, как системному администратору, вряд ли необходимо знать детали функционирования этого протокола. Однако наличие некоторых команд оказывает влияние на конфигурацию сервера. Поскольку IMAP позволяет работать с папками, эти папки надо где-то хранить. Расположение папок зависит от используемого сервера. В настоящее время наиболее популярен сервер IMAP, разработанный в Вашингтонском университете (UW IMAP; http://www.washington.edu/imap/). Этот сервер хранит все папки в рабочем каталоге пользователя. Исключение составляет папка INBOX, которая находится в одном из стандартных каталогов, используемых почтовой системой, а именно, в /var/spool/mail/ имя_пользователя . Когда пользователь впервые обращается к серверу IMAP, для него существует только папка INBOX. В процессе работы пользователь может создавать новые папки, применяя для этого соответствующие команды программы просмотра почты. Получив подобную команду, сервер UW IMAP создает каталог в рабочем каталоге пользователя. Прочие серверы используют для организации папок другие каталоги. Необходимые сведения по этому вопросу вы можете получить из документации на конкретный сервер. Выполняя администрирование системы, необходимо знать, где размещаются папки, чтобы выделить необходимое для них дисковое пространство. Это особенно важно на крупных серверах, обслуживающих большое количество пользователей, либо в тех случаях, когда пользователи хранят на сервере почтовые сообщения большого объема.

 

Выбор протокола

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

Внимание

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

 

Обеспечение работы по протоколу

POP

 

Как правило, для обеспечения работы сервера POP не приходится затрачивать больших усилий. Чаще всего, настройка не требуется, и вам достаточно лишь запустить сервер. Тем не менее следует убедиться, что выбранная вами программа сервера совместима с сервером SMTP. He менее важно обеспечить совместимость с форматом хранения писем. В настоящее время используются два таких формата: mbox (почтовый ящик) и maildir (почтовый каталог). Большинство серверов, например sendmail, Postfix, and Exim, по умолчанию используют формат mbox, но в некоторых серверах, например в qmail, изначально включен режим работы с maildir. Серверы Postfix, Exim и qmail можно настроить на использование как mbox, так и maildir. Выбранный вами сервер POP должен предоставлять возможность чтения писем в том формате, в котором их записывает сервер SMTP.

 

Серверы POP для Linux

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

• UW IMAP. Сервер IMAP, созданный в Вашингтонском университете (http://www.washington.edu/imap/), может также работать в режиме сервера POP. Этот сервер поставляется со многими версиями Linux и поддерживает формат mbox, используемый по умолчанию многими серверами SMTP.

• Cyrus IMAP. Подобно UW IMAP, Cyrus IMAP (http://asg.web.cmu.edu/cyrus/imapd/) наряду с IMAP поддерживает протокол POP. Данный сервер использует для хранения поступающей корреспонденции формат mbox.

• nupop. Сервер nupop (http://nupop.sourceforge.net) предназначен для работы на крупных узлах, его имеет смысл устанавливать в том случае, если ваша почтовая система должна обслуживать большое количество пользователей. Данный продукт ориентирован на использование формата maildir, поэтому лучше всего он взаимодействует с сервером qmail.

• Courier. Продукт Courier (http://ww.courier-mta.org) реализует функции серверов POP, IMAP и SMTP. Серверы Courier POP и IMAP доступны в виде отдельного пакета Courier-IMAP (http://www.inter7.com/courierimap/). Эти серверы используют формат maildir.

• QPopper. Несмотря на свое название, данный пакет (httр://www.eudora.com/qpopper/) не имеет никакого отношения к SMTP-серверу qmail. QPopper 3.0 распространялся на коммерческой основе. Версия 4.0 данного продукта доступна бесплатно в исходных кодах. QPopper использует формат mbox. QPopper 4.0 поддерживает работу через SSL-соединение.

• qmail-pop3d. Данная программа поставляется с сервером qmail (http://www.qmail.org) и использует формат maildir. Если вы решили использовать в качестве SMTP-сервера qmail, имеет смысл установить qmail-pop3d для поддержки протокола POP.

Здесь приведена информация лишь о незначительной части продуктов, реализующих обмен по протоколу POP. На сервере http://www.sourceforge.net можно найти большое количество серверов POP, многие из которых входят в состав пакетов, поддерживающих IMAP, SMTP и другие протоколы. В комплекте со многими версиями поставляется UW IMAP, а некоторые дистрибутивные пакеты включают также Cyrus, QPopper и другие продукты.

 

Инсталляция и настройка сервера POP

Как правило, серверы POP запускаются с помощью суперсервера (вопросы использования суперсерверов рассматривались в главе 4). При инсталляции некоторых серверов автоматически устанавливается конфигурация xinetd. He исключено, что для запуска сервера вам придется вручную отредактировать файл /etc/inetd.conf. Для того чтобы сервер POP начал обрабатывать поступающие запросы, необходимо перезапустить inetd или xinetd. Если используемый вами сервер POP не входит в состав дистрибутивного пакета, вам следует прочитать документацию на данный продукт. Это позволит избежать возникновения проблем.

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

 

Обеспечение работы по протоколу IMAP

 

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

 

Серверы IMAP для Linux

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

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

 

Инсталляция и настройка сервера IMAP

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

 

Использование Fetchmail

 

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

На заметку

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

 

Участие 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. Данную программу также можно запускать вручную.

 

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

fetchmailconf

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

В состав большинства версий Linux программа fetchmailconf входит как отдельный пакет. Поэтому, если вы хотите обеспечить в такой системе выполнение программы Fetchmail и ее настройку с помощью специального инструмента, вам придется установить два пакета. Как программа X Window, построенная на базе Tcl/Tk, fetchmailconf требует наличия дополнительных библиотек. После инсталляции Fetchmail и сопутствующих программ необходимо установить требуемую конфигурацию. Для этого выполните следующие действия.

1. Зарегистрировавшись как обычный пользователь, введите в окне xterm команду fetchmailconf. В результате вы увидите окно Fetchmail Launcher, в котором содержатся кнопки, предназначенные для настройки, тестирования, запуска Fetchmail и завершения работы.

На заметку

Конфигурировать и запускать 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 — панель, расположенная в нижней его части. С помощью этой панели вы можете задать имя почтового сервера, с которого собираетесь получать почту. Введите имя узла, и после нажатия клавиши отобразится новое диалоговое окно 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 были приведены в листингах 11.1 и 11.2.

7. Средства, доступные посредством раздела Security, особенно важны в тех случаях, когда взаимодействие с сервером получения производится по коммутируемой линии, причем эта линия не всегда активна. В поле Interface to Monitor введите имя интерфейса, например ppp0. Это заставит Fetchmail опрашивать сервер только в том случае, если с момента прошлого опроса интерфейс был использован другой программой. Информация, задаваемая в поле IP Range to Check Before Poll, используется для того, чтобы программа могла проверить, связан ли IP-адрес с указанным интерфейсом. Введите в данном поле IP-адрес и маску подсети, разделив их символом /; в результате Fetchmail будет опрашивать сервер лишь тогда, когда с устройством связан адрес, принадлежащий заданному диапазону. Например, если для интерфейса ppp0 указан адрес 172.20.0.0/255.255.0.0, то Fetchmail будет опрашивать сервер, только если интерфейсу ppp0 будет соответствовать один из адресов сети 172.20.0.0/16.

8. В разделе User Entries for Имя_узла есть поле New User. Введите в нем имя, под которым вы зарегистрированы на почтовом сервере. После нажатия клавиши отобразится окно 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, надо щелкнуть на кнопке Save в окне Fetchmail Expert Configurator.

11. Для того чтобы проверить конфигурацию программы, щелкните на кнопке Test Fetchmail в окне Fetchmail Launcher. В результате программа Fetchmail будет запущена в режиме отладки, т.е. вы увидите команды, которые данная программа передает серверу получения и серверу передачи почты, а также ответы этих серверов. Эта информация позволяет выявить и устранить проблемы, возникающие при работе Fetchmail. Убедившись в работоспособности программы, завершите ее работу щелчком на кнопке Quit.

Внимание

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

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

 

Редактирование

.fetchmailrc

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

Листинг 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

Как и в других конфигурационных файлах, символ # является признаком комментариев, поэтому Fetchmail не обрабатывает первые две строки. Остальную часть листинга 11.3 можно условно разделить на две категории. Выражения set устанавливают глобальные опции, большинство из которых соответствуют опциям, содержащимся в разделе Fetchmail Run Controls диалогового окна Fetchmail Expert Configurator программы fetchmailconf (рис. 11.2). Многие из этих опций можно установить с помощью параметров командной строки. Кроме них, в листинге 11.3 содержатся два выражения poll, каждое из которых определяет учетную запись на удаленном компьютере, используемую для получения почты. При работе с программой fetchmailconf эта информация задается в диалоговых окнах Fetchmail Host Имя_узла и Fetchmail User Имя_пользователя Querying Имя_узла (рис. 11.3 и 11.4). Выражение poll может занимать несколько строк, причем специальный символ, указывающий на то, что выражение продолжается в другой строке, не требуется. Переход на новую строку может осуществляться в произвольных точках выражения.

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

• set postmaster имя_пользователя . Данная опция позволяет задать имя пользователя, который будет получать письма в случае, если определить адресата не удается. На это же имя будут приходить и некоторые сообщения об ошибках в работе программы. Как правило, в данной опции задается обычное пользовательское имя, но при желании вы можете указать postmaster или root. (При настройке сервера SMTP также задается пользователь postmaster, который получает сообщения, касающиеся работы почтовой системы. В роли postmaster для Fetchmail и сервера SMTP может выступать либо один и тот же, либо разные пользователи.) Значение данной опции можно изменить с помощью параметра командной строки --postmaster имя_пользователя .

• set bouncemail. Данная опция указывает на то, что сообщения об ошибках должны передаваться отправителям писем. Альтернативой set bouncemail является выражение set no bouncemail, в этом случае сообщения об ошибках будет получать пользователь postmaster, указанный при настройке Fetchmail.

• set daemon интервал . Эта опция сообщает о том, что программа Fetchmail должна выполняться в режиме демона и опрашивать почтовый сервер через заданные интервалы времени (значение интервала указывается в секундах). Если вы хотите, чтобы программа Fetchmail выполнялась в пакетном режиме, данная должна отсутствовать в конфигурационном файле. Переопределить значение опции set daemon можно, задавая в командной строке параметр --daemon интервал . Если при вызове Fetchmail указан параметр --daemon 0, это означает, что программа должна выполнить одну операцию, связанную с опросом сервера, даже если в .fetchmailrc задан режим демона.

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

• set syslog. Если вы хотите регистрировать действия Fetchmail в системном файле протокола, вы можете сделать это посредством данной опции.

В файле .fetchmailrc могут присутствовать выражения poll различной сложности. Формат данного выражения приведен ниже.

poll имя_сервера опции-сервера описание_пользователя

Ключевое слово server является синонимом poll. Вы также можете заменить его на skip, в результате чего Fetchmail пропустит данную запись. Таким способом вы можете временно исключить запись из рассмотрения, не удаляя ее из файла .fetchmailrc. Опции сервера определяют особенности взаимодействия Fetchmail с сервером, а в описании пользователя приводится информация об учетных записях на сервере и на локальном компьютере. В пределах каждой из категорий порядок следования записей не имеет значения, но чередовать записи, принадлежащие разным категориям, нельзя. (Именно этим вызвано большинство проблем, возникающих при редактировании файла .fetchmailrc вручную.) Слова and, with, has, wants и options игнорируются; не принимаются также во внимание символы ":", ";" и ",". Вы можете свободно использовать их в составе опций сервера или описания пользователя для того, чтобы сделать выражение poll более удобным для восприятия.

Некоторые из наиболее важных опций сервера приведены ниже.

• proto имя или protocol имя . Эти опции, являющиеся синонимами, определяют используемый протокол получения почты. В большинстве случаев в качестве имени указывается POP3 или IMAP, но Fetchmail также поддерживает и другие значения данной опции. Переопределить значение, заданное в файле .fetchmailrc, можно указав в командной строке параметр -p.

• interface интерфейс / IP-адрес / маска_подсети . Данная опция позволяет задать интерфейс, который должен быть активен в тот момент, когда Fetchmail опрашивает сервер. Для указания интерфейса используются имя устройства, например eth1 или ppp0, а также IP-адрес и маска подсети, которые определяют диапазон допустимых IP-адресов. Например, выражение eth1/192.168.1.0/255.255.255.0 означает, что перед тем, как Fetchmail предпримет попытку опроса сервера, с устройством eth1 компьютера должен быть связан адрес в диапазоне от 192.168.1.1 до 192.168.1.254. Аналогичные сведения можно предоставить программе с помощью опции -I, задаваемой в командной строке.

• monitor интерфейс . Данная опция указывает программе Fetchmail, выполняющейся в режиме демона, на то, что она должна проверять активность сетевого интерфейса. Если Fetchmail обнаружит, что после предыдущего опроса интерфейс стал неактивен, она пропустит очередной планируемый опрос. Значение опции может быть переопределено путем указания в командной строке опции -М.

Ниже перечислены опции, наиболее часто применяющиеся в описании пользователя.

• user имя или username имя . Эта опция задает пользовательское имя и обычно помечает начало описания пользователя в выражении poll. Как правило, данная опция определяет имя на удаленном узле, но если она сопровождается ключевым словом here, предполагается локальное имя. Ключевое слово there подтверждает тот факт, что имя зарегистрировано на удаленном компьютере. Опция -u в командной строке переопределяет значение данной опции.

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

• is имя или to имя . Эти опции связывают учетную запись на сервере с локальным пользователем. Одна из этих опций указывается после описания учетной записи на сервере получения (т.е. после выражения user имя with pass пароль ). Если удаленная учетная запись указывается перед локальной, ключевое слово here, заданное после данной опции, идентифицирует учетную запись как локальную. Ключевое слово there задает удаленную учетную запись.

• smtphost имя_узла . В обычных условиях программа Fetchmail пытается использовать для передачи почты компьютер, на котором она выполняется, т.е. узел с адресом localhost. Данная опция указывает на то, что почтовый сервер, посредством которого должны передаваться сообщения, находится на компьютере с заданным именем. Вы можете указать в качестве значения данной опции имя вашего компьютера. В этом случае в заголовках писем, переданных с помощью Fetchmail, вместо localhost будет содержаться обычное имя узла. Значение данной опции переопределяется с помощью опции -S, задаваемой в командной строке.

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

• fetchall. В обычных условиях Fetchmail не копирует сообщения, которые были получены ранее. Опция fetchall указывает на то, что должны быть получены все письма с сервера. Аналогичные действия выполняет опция -а, заданная в командной строке.

• forcecr. Строки почтовых сообщений должны оканчиваться парой символов CR/LF (возвратом каретки и переводом строки). Многие почтовые программы допускают отсутствие символа возврата каретки, поэтому подобные сообщения иногда встречаются в сети. Сервер передачи qmail отвергает такие сообщения; исправить положение позволяет опция forcecr.

Если вы зададите больше одного локального имени, Fetchmail будет анализировать заголовки писем и пытаться определить, кто является получателем конкретного сообщения. Например, если вы укажете локальные учетные записи jack и jill и если письмо поступает на имя jill, Fetchmail доставит его пользователю jill. Режим, в котором письма, поступающие на одну учетную запись, обрабатываются по-разному в зависимости от содержимого их заголовков, называют многоточечным (multidrop mode).

Совет

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

 

Резюме

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

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

 

Глава 12

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

 

В главе 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), Supernews (http://www.supernews.com) и NewsGuy (http://www.newsguy.com). Информацию о серверах, предоставляющих свои услуги бесплатно, можно получить, обратившись по адресу http://www.newsservers.net. На узле http://groups.google.com хранятся архивы многих популярных групп новостей. Для доступа к ним предоставляется Web-интерфейс. Несмотря на то что в данной главе при обсуждении серверов новостей основное внимание будет уделяться использованию этих серверов для внутреннего обмена новостями, вопросы настройки сервера для обмена данными с серверами Usenet также будут рассмотрены.

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

 

Принцип работы протокола NNTP

Современные серверы новостей используют для обмена между собой и для взаимодействия с клиентами протокол 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, содержащее идентификационный код. Этот код состоит из последовательного номера, генерируемого сервером, и имени сервера. Поскольку идентификатор содержит имя сервера, он является уникальным во всей системе Usenet. Посредством идентификаторов сервер новостей определяет, какие сообщения были просмотрены и какие должны быть переданы клиенту.

Для взаимодействия серверов новостей используются два типа протокола NNTP: протокол передачи (push protocol) и протокол получения (pull protocol). Во время передачи данных один из серверов выступает в роли клиента, а другой — в роли сервера. При использовании протокола передачи клиент сообщает серверу о каждом имеющемся у него сообщении, передавая его идентификатор. Сервер ищет это сообщение в своей базе данных и определяет, нужно ли оно ему. Процесс повторяется для каждого сообщения, которые присутствуют на сервере, выполняющем в процессе взаимодействия роль клиента. При этом производятся многочисленные обращения к базе данных. Альтернативой протоколу передачи является протокол получения, при использовании которого принимающий сервер выступает в роли клиента. Сначала принимающая система получает полный список сообщений, поступивших на сервер с указанного момента, а затем запрашивает конкретные сообщения. Такой протокол работает более эффективно, но при этом необходимо принимать меры предосторожности, чтобы сервер не передал сообщение, предназначенное для внутреннего использования.

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

Независимо от используемого протокола и времени хранения сообщений, в передаче материалов групп может участвовать несколько компьютеров. Серверы новостей взаимодействуют друг с другом, образуя сложную структуру. Передача материалов групп от одного сервера другому называется поставкой новостей. Как правило, небольшие серверы, подключенные через линии с относительно невысокой пропускной способностью, получают материалы групп у крупных серверов. Например, сервер, находящийся в небольшом колледже (назовем его условно Tiny College), может получать содержимое групп новостей у сервера большого университета (Pangaea University). Это означает, что основная часть сообщений, находящихся на сервере news.tiny.edu, получена с сервеpa news.pangaea.edu. Однако часть данных может передаваться и в противоположном направлении, так как пользователи news.tiny.edu посылают свои сообщения в группы и эти сообщения должны быть доставлены на сервер news.pangaea.edu. Кроме того, в Tiny College могут поддерживаться свои группы новостей; при передаче этих групп news.tiny.edu станет поставщиком для news.pangaea.edu. Pangaea University, в свою очередь, получает и т.д.

В службе новостей не соблюдается строгая иерархия. Например, не исключено, что на сервере news.pangaea.edu не поддерживаются некоторые группы, в которых испытывают необходимость пользователи news.tiny.edu. В этом случае администратор Tiny College должен принять меры для получения материалов этих групп с другого сервера. То же самое делает администратор Pangaea University для получения групп, необходимых его пользователям. Не все группы, находящиеся у поставщика новостей, должны быть переданы. С целью экономии дискового пространства получатель может отказаться от некоторых групп и даже от целых категорий групп, не требующихся пользователям.

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

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

 

Сервер INN

 

Среди серверов новостей, предназначенных для выполнения в системе Linux, наиболее популярным является InterNetNews, или INN (http://www.isc.org/products/INN). Пакет INN состоит из нескольких программ, работающих совместно. Основная программа, innd, предназначена для обработки новых статей и поддержки соединений. Программа nnrpd обслуживает соединения с программами просмотра новостей. Для инициализации соединений с другими серверами применяется программа innxmit, которая, в свою очередь, использует для решения многих задач nntpsend. Для каждой из указанных программ предусмотрен отдельный конфигурационный файл, некоторые из них используют несколько файлов. Основные конфигурационные файлы находятся в каталоге /etc/news, но некоторые файлы располагаются также в /var/lib/news и других каталогах.

Сервер INN в составе операционной системы Linux обычно поставляется в пакете под названием inn. В этой главе описана версия 2.2.2 INN, но конфигурация остальных реализаций INN 2.x практически не отличается от INN 2.2.2. В некоторых системах INN настраивается для совместной работы с Cleanfeed. Cleanfeed — это дополнительный пакет, автоматически удаляющий с сервера новостей некоторые типы спама. (Спам в составе групп новостей создает большие проблемы для администраторов. Работая с материалами групп, вы не замечаете сообщений, содержащих навязчивую рекламу, лишь потому, что существуют средства, эффективно удаляющие их.)

 

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

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

Поиск сервера на роль поставщика новостей лучше всего начать с провайдера. Если быстродействие вашего соединения достаточно для того, чтобы вы могли получать материалы требуемых групп, провайдер предоставит их вам или, по крайней мере, укажет сервер новостей, услугами которого вы могли бы воспользоваться. Многие провайдеры, в особенности те, которые предоставляют услуги Internet небольшим компаниям, не содержат своего сервера новостей, так как пропускная способность их линий не позволяет им этого. В этом случае поставщиком новостей может быть независимый сервер, например NewsGuy (http://www.newsguy.com).

Поддержка групп новостей при наличии ограниченных ресурсов

Если вы хотите поддерживать сервер новостей, имея в своем распоряжении ограниченные аппаратные ресурсы и недостаточно высокую пропускную способность линии, вам следует отказаться от так называемых двоичных групп . Посредством таких групп распространяются двоичные файлы, содержащие звуковые, клипы, оцифрованные фотоснимки коды программ и т.д. Материалы подобных групп создают трафик большого объема, поскольку размеры двоичных файлов существенно превышают средние размеры текстовых сообщений, передаваемых в обычные группы. В именах большинства двоичных групп присутствует имя binary или binaries . Как правило, такие группы находятся в категории alt , но они также встречаются в comp и других категориях.

Если же собираетесь предоставлять пользователям материалы групп в полном объеме, но имеющиеся ресурсы не позволяют сделать это, вы можете организовать получение материалов из внешнего источника (outsourcing). Для этого надо заключить соответствующий договор с поставщиком новостей и создать на своем сервере NDS запись, указав в ней IP-адрес сервера поставщика. У пользователей создастся впечатление, что они работают с вашим сервером новостей, но на самом деле основную работу по их обслуживанию будет выполнять внешний сервер. Так часто поступают провайдеры, предоставляющие услуги небольшим компаниям. Недостаток подобного подхода состоит в том, что администратор внешнего сервера может не согласиться поддерживать группы новостей для локального использования абонентами вашей сети.

Чтобы организовать полнофункциональный сервер новостей, необходимо затратить значительные средства как на приобретение оборудования и организацию быстродействующего соединения, так и на оплату услуг поставщика новостей. Например, на момент написания данной книги стоимость получения материалов групп на сервере NewsGuy составляла 1200 долларов в месяц, а для взаимодействия с этим сервером требовался компьютер не ниже, чем Pentium 400, с объемом оперативной памяти не менее 500 Мбайт, оснащенный жестким диском объемом не меньше 64 Гбайт. Для получения данных требовалась пропускная способность соединения не ниже 3 Мбод. Планируя пропускную способность соединения, необходимо также учитывать, что на сервер будут обращаться клиенты. В зависимости от набора поддерживаемых вами групп новостей, времени хранения сообщений и других характеристик сервера, требования к ресурсам могут увеличиваться или уменьшаться. Поскольку количество групп и объем сообщений в них ежегодно возрастает, не исключено, что приведенные выше требования вскоре придется пересмотреть.

 

Настройка INN

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

Общие установки

Основным конфигурационным файлом является /etc/news/inn.conf. В этом файле содержатся выражения следующего вида:

имя_опции : значение

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

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

• server. Имя компьютера, на котором выполняется сервер INN. Эта опция очень важна, поскольку имя, указанное в ней, используется при установлении соединения, которое необходимо для доставки сообщений. Настраивая сервер, можно оставить значение по умолчанию localhost, но лучше заменить его реальным именем вашего компьютера.

• pathhost. Получая сообщение, сервер INN включает значение данной опции в поле заголовка Path. Это поле позволяет выяснить путь сообщения и устранить ситуации, при которых сообщение вторично попадает на тот же сервер. Задавая значение данной опции, желательно указать полное доменное имя сервера, например news.threeroomco.com.

• moderatormailer. Некоторые группы новостей модерируются, т.е. перед тем, как отправленные сообщения становятся доступными всем пользователям, их проверяет один из участников административной группы — модератор. Если вам надо связаться с модератором, вы можете либо послать письмо непосредственно ему, либо отправить сообщение на централизованный адрес модерируемой группы; в результате оно будет доставлено модератору. Примером централизованного адреса может служить %[email protected].

• domain. С помощью данной опции задается имя домена, например threeroomco.com. Оно предназначено для внутреннего использования компонентами INN.

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

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

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

Объявление групп новостей

В файле inn.conf отсутствуют объявления и описания групп новостей. Эта информация указывается в двух других конфигурационных файлах: active и newsgroups. Данные файлы хранятся в каталоге, указанном с помощью опции pathdb, которая находится в файле inn.conf (обычно это каталог /var/lib/news).

Файл active содержит список групп новостей, поддерживаемых системой. Каждой группе новостей посвящена строка этого файла. Порядок следования строк не важен. Строка, содержащая объявление группы, состоит из четырех полей:

имя_группы максимальный_номер минимальный_номер флаги

В первом поле указывается полное имя группы, например comp.os.linux.misc. Два следующих поля содержат соответственно максимальный и минимальный номера сообщений, присутствующих в группе. Для новой группы значения этих полей равны соответственно 0000000000 и 0000000001. (Сервер INN хранит сообщения, переданные в группу, как отдельные файлы, имена которых создаются на базе номеров сообщений в локальной группе. Эти номера не связаны с идентификаторами сообщений и могут по-разному присваиваться на различных серверах.) Последнее поле содержит флаги, определяющие характеристики группы. Значения флагов описаны ниже.

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

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

• m. Этот флаг определяет модерируемую группу новостей. Локальные сообщения, переданные в группу, пересылаются модератору для проверки.

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

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

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

Сервер новостей, который допускает только локальные операции, может поддерживать лишь несколько групп. Имена этих групп задаются произвольно, но они должны соответствовать схеме, принятой в Usenet. При желании вы можете назначать локальным группам имена, начинающиеся с имени вашей организации, например, на сервере новостей, расположенном в домене threeroomco.com, могут поддерживаться группы threeroomco.support, threeroomco.support.bigproduct и threeroomco.accounting. Если вы получаете материалы новостей из внешнего источника, соответствующий сервер должен предоставлять вам список групп новостей или даже полностью сформированный файл active.

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

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

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

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

Предоставление материалов групп другим серверам

Если вы хотите, чтобы сообщения, переданные вашими пользователями, достигали других узлов, тем более, если вы собираетесь предоставлять другим серверам материалы групп в полном объеме, вам надо соответствующим образом сконфигурировать ваш сервер новостей. Для этого необходимо отредактировать содержимое файла /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 полностью запретит передачу данного сообщения. Сервер INN интерпретирует записи в файле newsfeeds последовательно одну за другой, поэтому если вы укажете comp.os.*, !comp.os.linux, INN разрешит передачу всех сообщений категории comp.os, за исключением группы !comp.os.linux. Изменив порядок следования записей на обратный, вы разрешите передачу всех групп, так как более общее выражение comp.os.* переопределит более конкретное выражение !comp.os.linux.

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

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

Файл newsfeeds управляет созданием файла, который должен быть передан другому серверу. Информация, заданная в файле /etc/news/nntpsend.ctl, определяет порядок взаимодействия INN с этим сервером. Подобно newsfeeds, файл nntpsend.ctl содержит записи, состоящие из нескольких полей, разделенных двоеточиями. Формат записи приведен ниже.

идентификатор_узла : имя_узла : максимальный_размер : [ параметры ]

Значение в поле идентификатор_узла должно совпадать со значением, заданным в одноименном поле файла newsfeeds, а имя_узла — это реальное имя узла. Поле максимальный_размер позволяет ограничить объем данных, передаваемых в течение одного сеанса обмена; например, значение 2m ограничивает объем данных двумя мегабайтами. Последнее поле содержит необязательные параметры, которые могут передаваться программе innxmit, выполняющей реальную передачу данных. Сведения об этих параметрах можно найти в справочной системе.

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

Установка опций, управляющих доступом к серверу

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

Атрибуты и их значения, задаваемые в файле incoming.conf, представлены в виде ключ : значение . Атрибуты могут быть объединены в записи (создаваемые с помощью ключевого слова peer); каждая запись описывает отдельный компьютер. (Глобальные атрибуты и их значения не включаются в записи.) Записи, в свою очередь, могут объединяться в группы. Для определения границ как записи, так и группы используются фигурные скобки. Пример файла incoming.conf для сервера, который получает материалы групп с одного сервера новостей, приведен в листинге 12.1.

Листинг 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. Каждая строка этого файла состоит из пяти полей, разделенных двоеточиями:

имя_узла : полномочия : имя_пользователя : пароль : группы_новостей

Назначение каждого поля описано ниже.

• имя_узла . В этом поле указывается имя или IP-адрес узла. В составе имени может использоваться символ *, определяющий групповую операцию. Так, например, выражение *.threeroomco. com описывает всех клиентов в пределах домена threeroomco. com. При указании IP-адреса можно задавать также маску подсети в виде IP-адрес/маска подсети, например 172.20.0.0/16.

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

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

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

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

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

Опции, управляющие удалением сообщений

Содержимое файла /etc/news/expire.ctl управляет автоматическим удалением сообщений. Записи в этом файле имеют тот же формат, что и записи других конфигурационных файлов INN. Каждая запись состоит из пяти полей: шаблон : флаг : хранение : время_по_умолчанию : удаление

• шаблон . В данном поле помещается описание группы новостей. Подобно другим конфигурационным файлам, символ * определяет групповую операцию, т.е. выражение comp.os.* описывает всю категорию comp.os.

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

• хранение . В составе сообщения может присутствовать поле заголовка Expires, в котором указывается срок действия этого сообщения. Значение, указанное в поле хранение , задает минимальный срок (число дней), в течение которого статья должна оставаться на сервере. Предположим, например, что в поле хранение содержится значение 6, а в поле заголовка Expires указано, что сообщение должно быть удалено через пять дней. В результате сообщение будет храниться в течение шести дней. Если бы при том же значении в поле хранение, в поле заголовка Expires был бы определен срок 7 дней, статья хранилась бы на сервере в течение семи дней. В рассматриваемом поле можно задавать не только целые числа, но и числа с плавающей точкой. Специальное значение never указывает на то, что срок действия статьи не ограничен. (Применяя значение never, будьте внимательны. Если оно будет указано для слишком большого количества статей, жесткий диск сервера быстро переполнится.)

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

• удаление . Если значение в поле хранения позволяет увеличить срок действия, указанный в поле заголовка Expires, то значение в поле удаление позволяет лишь уменьшить его. Например, если вы зададите в данном поле значение 10 и ваш сервер получит сообщение, поле Expires которого содержит значение 100, это сообщение будет удалено через десять дней. Подобно полям хранение и время_по_умолчанию , в поле удаление может быть задано число с плавающей точкой или специальное значение never.

 

Обеспечение выполнения сервера новостей

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

Некоторые описанные выше задачи демон innd не решает. К таким задачам относится передача сообщений другим серверам или удаление статей по истечении срока их действия. Для выполнения требуемых действий используются утилиты и сценарии, вызываемые с помощью инструмента cron. Если сервер поставлялся в составе операционной системы, не исключено, что crontab-файлы, необходимые для автоматического вызова требуемых утилит уже сформированы и помещены в /etc/cron.d, /etc/cron.interval или другой каталог, используемый в подобных целях. Если вы хотите, чтобы соответствующие задачи выполнялись чаще или реже, вам надо найти crontab-файлы и изменить их.

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

 

Использование Leafnode

 

Сервер 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/ ).

 

Возможности Leafnode

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

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

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

• texpire. Подобно другим серверам новостей, Leafnode хранит сообщения групп в подкаталогах каталога /var/spool/news. Чтобы диск не переполнялся, приходится периодически удалять старые сообщения. Эту задачу решает программа texpire. Обычно она периодически запускается с помощью cron.

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

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

Одна из особенностей программы Leafnode состоит в том, что при ее использовании не требуется настройка для работы с источником новостей. Leafnode (если быть точным, программа fetchnews) взаимодействует с внешним сервером как обычная программа просмотра новостей. Благодаря этому можно организовать работу Leafnode с любым сервером новостей, например, сервером, расположенным на компьютере провайдера.

На заметку

С одной стороны, 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 сводится к настройке трех программ: leafnode, fetchnews и texpire. Опции, управляющие работой всех трех программ, содержатся в одном конфигурационном файле, но это не мешает настраивать каждую программу независимо от других. Если пакет Leafnode поставлялся в составе системы Linux, вам придется внести в конфигурационный файл лишь незначительные изменения.

Общие установки

Основной конфигурационный файл Leafnode называется config; обычно он хранится в файле /etc/leafnode. Строки данного файла, содержащие комментарии, начинаются с символа #. Помимо комментариев в конфигурационном файле находятся записи, представленные в следующем виде:

опция = значение

Минимальная конфигурация Leafnode предполагает наличие лишь двух опций: server и expire. Остальные опции необязательны; настраивая Leafnode, вы можете принять для них значения, заданные по умолчанию. Наиболее важные опции, присутствующие в файле config, описаны ниже.

• server. Данная опция задает имя внешнего сервера, предоставляющего материалы групп, например server = news.abigisp.net. Задавая несколько опций server, вы можете организовать получение материалов групп с нескольких серверов.

• expire. Эта опция указывает время (количество дней), по истечении которого сообщения будут удалены.

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

• password. Если внешний сервер требует ввода пароля, эта опция позволяет задать его.

Внимание

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

• port. Большинство серверов новостей использует по умолчанию порт 119. Данная опция позволяет вам указать другой порт.

• nodesc. Как правило, серверы новостей предоставляют описания групп, однако некоторые серверы не обеспечивают такой возможности. Наилучшим образом Leafnode работает в том случае, если в конфигурационном файле указана опция nodesc = 1.

• timeout. При соединении с сервером новостей программа fetchnews обычно выжидает десять секунд, а затем прекращает попытки. Данная опция позволяет изменить значение тайм-аута.

• groupexpire имя_группы . Если вы хотите задать для разных групп различное время хранения сообщений, вы можете воспользоваться этой опцией. При указании имени группы можно использовать символ групповой операции. Например, все группы категории comp.os.linux задаются с помощью значения comp.os.linux.*.

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

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

• delaybody. По умолчанию Leafnode копирует с внешнего сервера как заголовки, так и тело сообщений. Число сообщений может быть ограничено с помощью maxfetch и других опций. Leafnode может также работать и в другом режиме — копировать только заголовки сообщений. В этом случае тело сообщения будет скопировано лишь в том случае, если пользователь активизирует соответствующий заголовок в программе просмотра. После щелчка на заголовке сообщения оно помечается для копирования, и тело сообщения доставляется при следующем сеансе получения данных. Если вы зададите значение 1 опции delaybody, пользователь будет получать тело выбранного сообщения с задержкой, но при этом уменьшится внешний трафик.

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

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

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

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

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

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

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

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

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

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

Перечисленные выше опции имеют отношение ко всем трем основным программам Leafnode: leafnode, fetchnews и texpire. Несмотря на то что все три программы используют один и тот же конфигурационный файл, они запускаются по-разному.

Запуск программы leafnode

Как было сказано ранее, сервер 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 будет отвечать на запросы клиентов так же, как INN или другой полнофункциональный сервер новостей.

Внимание

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

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

При каждом запуске программы fetchnews материалы групп копируются с внешнего сервера; эта же программа отвечает за передачу на сервер сообщений, составленных вашими пользователями. (Для получения информации о сообщениях, ожидающих обработки, надо запустить программу newsq). Чтобы это происходило, необходимо указать имя внешнего сервера в файле /etc/leafnode/config. Вероятнее всего, что при первом запуске fetchnews ее выполнение займет достаточно длительное время, так как программа должна скопировать с внешнего сервера список предоставляемых групп новостей.

При вызове программы fetchnews можно задавать описанные ниже опции.

• -v. Данная опция позволяет управлять выводом информации в процессе выполнения программы. Чем больше символов v вы укажете при вызове программы, тем подробнее она будет комментировать выполняемые ею действия. Максимальный объем информации выводится в том случае, когда указаны четыре символа v (-vvvv). Эта опция может использоваться в качестве инструмента диагностики в тех случаях, когда программа fetchnews выполняется не так, как вы того ожидаете.

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

• -1. Как было сказано ранее, Leafnode позволяет получать материалы групп с различных серверов. Данная опция указывает на то, что данные должны быть скопированы только с первого сервера.

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

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

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

Совет

В обычных условиях, для того, чтобы пользователь увидел в составе группы переданное им сообщение, необходимо дважды вызвать программу fetchnews . Чтобы новые сообщения стали доступны после очередного выполнения fetchnews , надо предварительно вызвать fetchnews с опцией -P . В Leafnode 2.0 задержка при получении собственных сообщений не возникает, поэтому предварительный вызов fеtchnews не требуется.

Принимая меры для организации работы Leafnode, необходимо решить, каким способом следует вызывать программу fetchnews. Вы можете задать периодическое выполнение данной программы посредством инструмента либо включить вызов в состав сценария, посредством которого устанавливается PPP-соединение (примером такого сценария является ppp-on-dialer, рассмотренный в главе 2). Вызов fetchnews посредством cron имеет смысл, если у вас есть постоянное соединение с Internet либо если вы хотите автоматически устанавливать соединение с Internet и получать данные с внешнего сервера новостей в то время, когда этот сервер наименее загружен, например рано утром. Ответить на вопрос о том, насколько часто следует вызывать программу fetchnews, можно лишь, зная потребности ваших пользователей и возможности внешнего сервера по предоставлению данных. Вызывая fetchnews посредством сценария установки PPP-соединения вы предоставите вашим пользователям наиболее новые сообщения (насколько это позволяет график установления соединений с Internet).

Удаление старых сообщений

Программа texpire анализирует сообщения, хранящиеся на компьютере, и удаляет те из них, которые в соответствии с установками в файле /etc/leafnode/config считаются устаревшими. Удаление старых сообщений должно проводиться регулярно, иначе жесткий диск компьютера переполнится. Как правило, программа texpire вызывается с помощью инструмента cron. В некоторых пакетах Leafnode предусмотрен специальный сценарий, который помещается в /etc/cron.daily или другой подобный каталог. Если такого сценария нет, вам надо создать его самостоятельно или спланировать вызовы texpire с помощью утилиты crontab.

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

Подобно fetchnews, при вызове texpire может быть указано от одной до четырех опций -v. Среди других опций следует особо отметить опцию -f. В обычных условиях, чтобы убедиться в том, что данные потока не просматривались, texpire анализирует время последнего обращения к файлам. Опция -f сообщает texpire о том, что эту информацию следует игнорировать. Дело в том, что многие программы-архиваторы, в частности tar, изменяют дату последнего доступа к архивируемым файлам. Если вы часто архивируете материалы групп новостей, создается неверное впечатление о том, что сообщения недавно просматривались. Избежать этого позволяет опция -f.

 

Фильтрация сообщений

Leafnode позволяет удалять сообщения, соответствующие определенным критериям. Решение об удалении принимается исходя из информации, содержащейся в заголовке сообщения. Предположим, например, что в статьях, получаемых от пользователя [email protected] постоянно встречаются высказывания, оскорбляющие ваших пользователей. Указанное имя присутствует в заголовке в качестве значения поля From. На основе этой информации Leafnode может "отфильтровать" сообщения данного пользователя. Для этого вам надо включить соответствующее выражение в файл /etc/leafnode/filters, содержащий правила фильтрации. Правила в файле /etc/leafnode/filters имеют вид регулярных выражений. Например, если вы хотите удалять сообщения, поступающие от пользователя [email protected], необходимое для этого выражение будет иметь следующий вид:

^From:.*obnoxious@annoying\.edu

Данное выражение начинается с символа ^, за которым следует имя заголовка (в данном случае From:). Символы .*, используемые совместно, означают любое число произвольных символов. Строка [email protected] указывается непосредственно, но так как точка имеет в языке регулярных выражений специальное значение, перед ней указывается обратная косая черта (\).

На заметку

Более подробно регулярные выражения будут рассмотрены в главе 19.

Для фильтрации сообщений вам надо указать Leafnode расположение файлов фильтров. Для этого можно использовать опцию filterfile в файле /etc/leafnode/config, о которой шла речь ранее в данной главе. Несмотря на то что фильтры обычно располагаются в каталоге /etc/leafnode/filters, вы можете указать любое имя файла и любой путь к нему.

 

Резюме

Серверы новостей потребляют значительные ресурсы. Для поддержки групп новостей Usenet необходимо ежедневно передавать большой объем данных, кроме того, эти данные приходится хранить в течение нескольких дней. Чтобы инсталлировать полнофункциональный сервер новостей, необходим отдельный компьютер с дисковым пространством в десятки и даже сотни гигабайт. Если ваши потребности более скромны, вы можете установить сервер новостей, не реализуя взаимодействие его с Usenet. С помощью такого сервера можно обеспечить работу нескольких локальных групп новостей и даже групп, доступных для всего мира. Как для поддержки Usenet в полном объеме, так и для организации локальных групп используется сервер INN, который может выполняться в среде Linux. Функционирование этого сервера обеспечивает несколько взаимодействующих друг с другом программ; для их настройки используется несколько конфигурационных файлов. С помощью этих файлов вы можете описывать группы новостей, которые должны поддерживаться на сервере, задавать политику взаимодействия с другими серверами и клиентами, а также определять прочие характеристики сервера.

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

 

Глава 13

Удаленная регистрация на сервере

 

Многие серверы предоставляют доступ лишь к отдельным ресурсам компьютера, на котором они выполняются. Например, временной сервер, рассмотренный в главе 10, сообщает о показаниях системных часов, а сервер шрифтов, который будет обсуждаться в главе 15, передает клиентам битовые карты символов того или иного шрифта. Существуют, однако, серверы, которые предоставляют более или менее полный доступ к ресурсам компьютера и называются серверами удаленной регистрации (remote login server). Такие серверы позволяют пользователям регистрироваться в системе и запускать в ней различные программы так же, как это происходит при работе за консольным терминалом. Сервер удаленной регистрации организует работу нескольких пользователей на одном компьютере.

Существует несколько типов серверов удаленной регистрации. Выбор типа сервера зависит от конкретной ситуации. В данной главе обсуждаются серверы, которые обеспечивают работу с системой в текстовом режиме. При этом пользователь может запускать программы с алфавитно-цифровым интерфейсом, например, почтовые клиенты pine и mutt, компилятор gcc, текстовые редакторы Vi и Emacs и т.д. Рассматриваемые здесь серверы не позволяют выполнять программы, предназначенные для работы в среде X Window, например KMail или Nedit; для этой цели используются средства доступа, поддерживающие графический интерфейс, которые будут рассматриваться в главе 14.

Данная глава посвящена рассмотрению трех инструментов, предназначенных для поддержки удаленной регистрации: rlogind, Telnet и SSH. Каждый из них обладает своими уникальными характеристиками и используется для решения конкретных типов задач. Различия между серверами удаленной регистрации в основном связаны с вопросами защиты и наличием специальных возможностей. Например, среди рассматриваемых в данной главе инструментов rlogind реализует минимальный уровень защиты, a SSH обеспечивает наибольшую степень безопасности. Следует заметить, что керберизованные версии rlogind и Telnet сравнимы по степени защиты с SSH. (Система Kerberos рассматривалась в главе 6.)

 

Использование сервера удаленной регистрации

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

Внимание

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

 

Настройка

rlogind

 

Сервер rlogind — одна из нескольких программ, поддерживающих так называемые r-команды. Эти команды были реализованы для обеспечения различных типов удаленного доступа к системе UNIX. При запуске клиента rlogin он старается установить соединение с сервером rlogind или in.rlogind. Одно из преимуществ rlogind состоит в том, что настройка данного сервера осуществляется очень просто. Однако используемый протокол чрезвычайно примитивен, поэтому контролировать обращения к системе посредством rlogind очень трудно.

 

Запуск

rlogind

Сервер rlogind обычно запускается посредством суперсервера. Во многих дистрибутивных пакетах в конфигурационном файле /etc/inetd.conf уже присутствует запись для rlogind, но чаще всего она закомментирована. Для того, чтобы сервер выполнялся на компьютере, вам надо убрать символ комментариев из соответствующей строки и перезапустить суперсервер. Если в системе используется xinetd, в ней обычно создается файл для запуска rlogind, который помещается в каталог /etc/xinetd.d. Файл запуска, как правило, настраивается так, чтобы по умолчанию выполнение сервера было запрещено. Поэтому, чтобы обеспечить работу rlogind, надо специально разрешить его запуск. Необходимые для этого действия описаны в главе 4.

На выполнение rlogind влияют перечисленные ниже опции.

• -n. В обычных условиях rlogind периодически проверяет наличие клиента, даже если он длительное время не передает данные. Опция -n отменяет такое поведение сервера.

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

• -h. В обычных условиях rlogind не использует файл .rhosts суперпользователя. Опция -h указывает на то, что данный файл должен использоваться.

• -l. Данная опция запрещает использование файла .rhosts для аутентификации пользователей. Исключение составляет суперпользователь, взаимодействие с которым определяет опция -h.

• -L. Эта опция запрещает аутентификацию на основе данных, содержащихся в файлах .rhosts и hosts.equiv.

Внимание

Несмотря на то что опции -h , -l и -L входят в официальный набор опций rlogind , в новых версиях Linux они обычно не оказывают влияния на работу сервера. Причина в том, что в новых версиях системы используются модули РАМ; в результате действие указанных опций отменяется.

 

Средства защиты

rlogind

Средства защиты всех утилит, реализующих r-команды, в лучшем случае могут считаться устаревшими. А если подходить к этому вопросу с позиции современных требований, следует признать, что защита в них вовсе отсутствует. В частности, работа сервера rlogind основана на принципе доверия, а это значит, что rlogind полагается на результаты процедуры аутентификации, выполненной на клиентской машине. Существуют способы несколько улучшить защиту rlogind, а использование системы Kerberos позволяет реально обезопасить ресурсы сети.

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

1. Сервер проверяет порт клиента, выступающего инициатором установления соединения. Обычно клиент-программы rlogin используют номер порта в диапазоне 512-1023. Если номер порта клиента лежит за пределами этого диапазона, rlogind отвергает попытки установить соединение. Такая мера предотвращает использование для взаимодействия подложного клиента rlogin, написанного обычным пользователем, поскольку номера портов ниже 1024 может использовать только root. Однако это не мешает злоумышленнику подключить к сети свой компьютер под управлением Linux и зарегистрироваться на нем как root. Кроме того, в некоторых операционных системах порты с номерами ниже 1024 доступны всем пользователям, поэтому описанная здесь мера защиты не очень эффективна.

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

3. Если имя, полученное в результате DNS-преобразования, принадлежит тому же домену, что и сервер, или если при запуске rlogind была указана опция -а, сервер ищет IP-адрес по доменному имени. Если полученный в результате адрес не отличается от исходного IP-адреса и если опции -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 можно обойти несколькими способами. Это можно сделать, воспользовавшись недостатками в защите клиента, включив в запрос фальшивый IP-адрес компьютера, пользующегося доверием, удалив клиентскую машину из сети и подключив к ней свой компьютер, либо включив в файл .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, Telnet практически во всех случаях требует указывать пароль, а средства SSH обеспечивают гораздо более высокую степень защиты.

 

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

rlogind

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

• Создать запись в файле /etc/hosts.equiv . Данный конфигурационный файл содержит установки для всей системы. Если компьютер указан в данном файле, любой пользователь, работающий на нем, может обращаться к службам, поддерживающим r-команды. Для того чтобы такие обращения поддерживались, необходимо, чтобы на сервере существовала учетная запись для текущего пользователя либо выполнялось отображение пользовательских имен. Если же соответствие имен установить не удалось (например, если пользователь julia хочет зарегистрироваться на удаленном сервере с помощью учетной записи fred), придется вводить пароль.

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

Внимание

Тот факт, что файл ~/.rhosts доступен для пользователя, означает, что вы как системный администратор делегируете вашим пользователям право настраивать средства защиты системы. Это одна из причин, по которым применять сервер rlogind не рекомендуется. Если же по каким-либо причинам вам приходится запускать на компьютере rlogind , используйте TCP Wrappers либо другие средства ограничения доступа.

Оба описанных выше файла управляют использованием всех r-команд на сервере, в частности rlogin, rcp и rsh. Если на компьютере поддерживается система печати BSD LPD (системы печати были рассмотрены в главе 9), эти файлы также осуществляют контроль доступа к принтерам.

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

[+|-][ имя_узла ] [ имя_пользователя ]

Символ + или -, указанный перед именем узла, разрешает или запрещает доступ для конкретного клиента. По умолчанию предполагается, что доступ разрешен, поэтому в большинстве случаев символ + указывать не обязательно. Символ - запрещает доступ клиента. Запрещающую запись имеет смысл использовать в том случае, если ей предшествует запись, которая разрешает доступ к серверу для группы клиентов.

Внимание

Используя символ + , будьте внимательны. Если в строке указан только этот символ (а имя узла отсутствует), доступ разрешается для всех клиентов. Подобная политика защиты является одним из недостатков r-команд. Если вы по ошибке введете пробел между символом + и именем узла, система будет интерпретировать имя узла как имя пользователя и предоставит возможность обращаться к серверу со всех компьютеров.

Для идентификации узла может использоваться IP-адрес (например, 192.168.34.56) или имя (например, gingko.threeroomco.com). В качестве имени может быть указано полное доменное имя, а если и сервер, и клиентская машина принадлежат одному домену, достаточно указать лишь имя самого компьютера, например gingko. Если перед именем задан символ @, это имя определяет домен NIS (для работы с NIS ваша система должна быть специальным образом сконфигурирована).

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

172.21.13.14 jbrown

В этом случае пользователь jbrown, который работает на узле с адресом 172.21.13.14, может регистрироваться на сервере под именем julia и получить при этом все полномочия данного пользователя. (Другими словами, работая на клиентском компьютере, jbrown может вызывать команду rlogin, указывая опцию -l julia.)

Записи в файле /etc/hosts.equiv распространяются на всю систему. Если в этом файле указано имя пользователя, это означает, что он имеет право регистрироваться на сервере с помощью любой учетной записи, за исключением root. Если бы запись, рассмотренная ранее в качестве примера, присутствовала в файле /etc/hosts.equiv, это означало бы, что пользователь jbrown, работающий на компьютере с адресом 172.21.13.14, имеет право регистрироваться не только под именем julia, но и под именем любого другого пользователя, кроме root. Таким образом, указывая имя пользователя в файле /etc/hosts.equiv, вы создаете угрозу безопасности системы. Исключением являются случаи, когда пользовательское имя указывается в запрещающих записях, которые начинаются с символа -.

Доступ к rlogind может ограничиваться не только с помощью записей в файлах ~/.rhosts и /etc/hosts.equiv и проверки имени пользователя и пароля. Существуют также другие механизмы, предназначенные для ограничения доступа. Поскольку сервер rlogind запускается с помощью inetd или xinetd, вы можете применять для этой цели TCPWrappers. Блокировать доступ можно также с помощью брандмауэра, указав при его настройке TCP-порт 513 (порт, используемый программой rlogind).

 

Настройка Telnet

 

Протокол Telnet часто используется для удаленной регистрации в сети Internet. Клиент-программа Telnet (как правило, она называется telnet) поставляется с большинством версий Linux. Программы, реализующие Telnet-серверы, также широко распространены, однако они в основном включаются в состав тех операционных систем, которые обеспечивают одновременную работу нескольких пользователей, например в Linux, UNIX и VMS. Несмотря на то что протокол Telnet сложнее протокола, используемого rlogind, он, как и все протоколы семейства TCP/IP, достаточно прост. Выполняя настройку сервера Telnet для работы в системе Linux, необходимо обеспечить запуск соответствующей программы посредством суперсервера. В отдельных случаях приходится предусматривать запуск сервера Telnet с помощью сценария SysV. Настройка Telnet также предполагает дополнительные операции, например, создание сообщения, выводимого в качестве приглашения к регистрации.

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

 

Опции, используемые при запуске сервера Telnet

В некоторых случаях сервер Telnet инсталлируется по умолчанию при установке операционной системы, но иногда приходится инсталлировать этот сервер самостоятельно. Пакет, содержащий сервер Telnet, в различных системах называется по-разному. Например, в Caldera он называется netkit-telnet, в Debian — telnetd, в Mandrake и Red Hat — telnet-server, в Slackware — tcpipl, в SuSE — nkitserv а в TurboLinux — telnet. Некоторые из этих пакетов, например telnetd, поставляемый в составе системы Debian, содержат только сервер Telnet, а в других, например в telnet системы TurboLinux, находится как серверная, так и клиентская программа. В большинстве случаев сервер Telnet устанавливается по умолчанию, но это не означает, что в системе разрешено выполнение данного сервера. Вопросы запуска серверов с помощью суперсервера были рассмотрены в главе 4 (программа, реализующая сервер Telnet, обычно носит имя telnetd или in.telnetd).

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

• -D режим_отладки . Данная опция используется при отладке сервера. Она задается в тех случаях, когда запуск программы telnetd осуществляется вручную с консольного терминала. В зависимости от указанного режима отладки, сервер отображает информацию о соединении либо о данных, которыми он обменивается с клиентом. Режим отладки может быть задан с помощью значений options, report (оба эти значения отображают информацию об установлении соединения), netdata и ptydata (эти значения выводят соответственно сведения о входном и выходном потоках данных).

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

• -L программа_регистрации . По умолчанию telnetd использует для регистрации пользователей /bin/login. При желании вы можете указать посредством данной опции другую программу.

• -n. Подобно rlogind, telnetd проверяет наличие клиента, используя для этого специальные сообщения. Опция -n подавляет передачу данных сообщений.

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

 

Редактирование начального сообщения Telnet

При получении запроса на установление соединения сервер telnetd читает содержимое файла /etc/issue.net и передает его клиенту. Данные, содержащиеся в этом файле, отображаются перед тем, как пользователь получает возможность зарегистрироваться на сервере. Опция -h, указанная при запуске telnetd, подавляет вывод данного сообщения. Как правило, в начальном сообщении приводятся некоторые сведения о компьютере, на котором выполняется Telnet-сервер. Ознакомившись с ними, пользователь может убедиться, что он обратился к нужному ему узлу сети. По умолчанию в начальном сообщении содержатся данные о версиях системы и ядра. Большинству пользователей эти сведения не нужны, но они наверняка заинтересуют злоумышленника, который собирается взломать систему. Прочитав начальное сообщение, он сможет определить, какое программное обеспечение выполняется на компьютере, и догадаться, какими недостатками в защите можно воспользоваться.

На заметку

Аналогичные сведения отображаются при регистрации пользователя с консольного терминала (непосредственно подключенного к компьютеру). Они содержатся в файле /etc/issue . (При установлении соединения с помощью X Window данный файл не используется. Вопросы удаленной регистрации средствами X Window будут рассматриваться в главе 14.)

Многие системы позволяют непосредственно редактировать файл /etc/issue.net. Вы можете изменять текст в этом файле по своему усмотрению. В составе начального сообщения могут содержаться специальные переменные, которые telnetd заменяет данными о системе. Назначение этих переменных описано в табл. 13.1.

Таблица 13.1. Переменные, используемые в файле /etc/issue.net

Переменная Описание
%t Используемый терминал (число, описывающее устройство ввода-вывода текста)
%h Полное доменное имя компьютера
%D Имя домена NIS (если сервер NIS используется в сети)
%d Текущая дата и время
%s Имя операционной системы (Linux)
%m Тип аппаратного обеспечения (процессора)
%r Номер версии ядра
%v Версия операционной системы (обычно не используется)
%% Символ %

Предположим, что текст в файле /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. Код сценария, используемого в системе Mandrake 8.1, приведен ниже.

# Этот сценарий создает файл /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, либо модифицировать код самого сценария.

 

Средства защиты Telnet

После отображения начального сообщения, содержащегося в файле /etc/issue.net, telnetd передает управление /bin/login либо программе, указанной с помощью опции -L. Программа /bin/login предоставляет возможность локальной и удаленной регистрации в текстовом режиме. Она отображает приглашения на ввод пользовательского имени и пароля (login: и password:). Если регистрационные данные введены корректно, /bin/login отмечает время последней регистрации и вызывает оболочку, используемую по умолчанию.

Поскольку большинство серверов Telnet не шифрует данные, пересылаемые по сети, пользовательское имя и пароль передаются в незакодированном виде. Несмотря на то что при вводе пароля символы не отображаются на экране, пароль может быть перехвачен по пути следования от клиента к серверу. Если вы не указываете при вызове telnetd опцию -L, передача незашифрованного имени пользователя и пароля является единственным средством аутентификации, поддерживаемым telnetd. В отличие от rlogind, сервер Telnet не использует принцип доверия, т.е. не полагается на процедуру аутентификации, выполняемую на стороне клиента. (Следует заметить, что имя пользователя и пароль все же поступают на сервер с клиентского компьютера. Некоторые клиенты Telnet могут быть сконфигурированы для автоматической передачи регистрационных данных.)

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

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

Что же можно предпринять для уменьшения риска потери данных? Очевидно, что радикальной мерой является переход к использованию протокола, обеспечивающего кодирование передаваемой информации. Если же это по каким-либо причинам невозможно или нежелательно, то, чтобы уменьшить вероятность утечки важных сведений, рекомендуется придерживаться ряда правил. Не просматривайте файлы, содержащие секретные данные, или важные письма при работе посредством Telnet. He регистрируйтесь из сеанса Telnet на другом компьютере. Даже если второе соединение устанавливается по защищенному каналу, информация будет поступать на ваш компьютер в незакодированном виде и может стать доступна злоумышленнику. Не используете команду su для получения привилегий root и пароль, с помощью которого вы регистрируетесь на сервере Telnet, для других целей. Лучше всего Telnet подходит для взаимодействия в пределах небольшой локальной сети, не подключенной к Internet. Используя Telnet, желательно периодически изменять пароль, чтобы у взломщика, получившего пароль, было меньше возможностей нанести реальный вред вашей системе.

 

Настройка SSH

 

Из протоколов, обеспечивающих защиту передаваемых данных, среди пользователей Linux наиболее популярен SSH (Secure Shell — защищенная оболочка). Данные, предназначенные для передачи по сети посредством данного протокола, шифруются. Очевидно, что шифрованные данные могут быть перехвачены на маршрутизаторе или в локальной сети, но технология, позволяющая декодировать их, в настоящее время отсутствует. (Теоретически достаточно мощный компьютер способен справиться с задачей расшифровки информации, но для этого ему потребуется очень много времени. Кроме того, компьютеры необходимой мощности встречаются достаточно редко, и получить доступ к ним очень трудно.)

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

На заметку

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

 

Программное обеспечение для поддержки SSH

Существуют два основных пакета SSH, предназначенных для работы в системе Linux: коммерческий продукт SSH (http://www.ssh.com/products/ssh/), разработанный компанией SSH, и пакет OpenSSH, распространяемый в исходных кодах (http://www.openssh.org). Пакет OpenSSH входит в состав многих версий Linux, в частности, Caldera 3.1, Debian 2.2, Mandrake 8.1, Red Hat 7.2, Slackware 7.0 и SuSE 7.3. Если версия пакета, поставляемая в составе операционной системы, вас не устраивает, вы можете обратиться на Web-узел OpenSSH. (Перед использованием коммерческой версии SSH необходимо ознакомиться с лицензионным соглашением.) Далее в этой главе я буду использовать термин SSH для обозначения любой реализации данного протокола.

На заметку

Проект 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, поддерживающий базовые средства SSH, а также openssh-client и openssh-server, которые реализуют соответственно клиентскую программу и сервер.

Протокол SSH распространен не так широко как Telnet, поэтому вам необходимо специально установить клиентские программы SSH на компьютеры ваших пользователей. Такие программы существуют для различных операционных систем. Информация о бесплатно распространяемых клиентах SSH находится на сервере http://www.freessh.org. Поддержку SSH обеспечивают также многие коммерческие терминальные программы, ориентированные на работу в системах Windows и MacOS. Инсталлировать клиент SSH нетрудно; сложнее доставить эти программы на все компьютеры и научить пользователей работать с ними.

 

Возможности SSH

Основное отличие 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, реализующей r-команду, с помощью которой осуществляется копирование файлов. Программа scp создана для замены rcp. В отличие от rcp и многих других инструментов передачи файлов (например, FTP), копирует данные в зашифрованном виде, кроме того, она шифрует имя пользователя и пароль. Такую программу удобно использовать для передачи важных данных по сетям, в которых не гарантируется защита информации.

Дополнительные интерактивные возможности при передаче файлов обеспечивает программа sftp, которая работает подобно традиционной программе ftp, но защищает содержимое файлов и регистрационные данные посредством кодирования. Некоторые FTP-клиенты с графическим интерфейсом, например gFTP (http://gftp.seul.org), также поддерживают передачу данных на базе SSH. Таким образом, средства SSH, по сути, дублируют функции Telnet и FTP.

Стандартный сервер SSH (программа sshd) поддерживает как работу SSH-клиента (в системе Linux это программа ssh), так и обмен данными с программами scp и sftp. Этот сервер также обеспечивает туннелирование портов. Весь трафик проходит через стандартный SSH-порт 22.

 

Опции, используемые при запуске сервера SSH

Независимо от того, какую реализацию протокола 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 порт . Эта опция задает порт для сервера. По умолчанию используется порт 22.

• -q. Данная опция подавляет протоколирование. (Обычно в файл протокола записывается информация об установлении соединения, выполнении аутентификации и разрыве соединения.)

• -4. По умолчанию sshd поддерживает соединения с компьютерами, адреса которых соответствуют либо протоколу IPv4, либо протоколу IPv6. Данная опция указывает на то, что sshd должен устанавливать соединения только с клиентами, имеющими адреса IPv4.

• -6. Данная опция разрешает установление соединений только с клиентами, имеющими адреса IPv6.

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

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

# 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_config

Работой сервера sshd управляет файл sshd_config, который обычно находится в каталоге /etc/ssh. (He следует путать файл sshd_config с конфигурационным файлом клиента ssh_config, который размещается в том же каталоге.) В файле sshd_config указываются опции и их значения. Каждая опция задается в отдельной строке в следующем формате:

Опция значение

Подобно другим конфигурационным файлам, строка, начинающаяся с символа #, содержит комментарии. Многие опции в файле sshd_config дублируют опции командной строки, которые указываются при вызове sshd, но некоторые из опций могут присутствовать только в конфигурационном файле. Конфигурация, установленная по умолчанию, чаще всего обеспечивает нормальную работу сервера, но иногда приходится изменять значения некоторых опций, например PermitRootLogin. Наиболее важные из опций, содержащихся в файле sshd_config, приведены ниже.

• Port. Данная опция позволяет задать порт для сервера. По умолчанию используется порт 22.

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

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

• PermitRootLogin. В большинстве случаев при инсталляции пакета устанавливается значение yes данной опции. По умолчанию sshd позволяет пользователю root регистрироваться на сервере. Безопаснее, однако, задать для этой опции значение no, так как в этом случае злоумышленник, пытающийся незаконно проникнуть в систему, должен знать два пароля (пароль обычного пользователя и пароль root). Значение по опции PermitRootLogin не исключает возможность удаленного администрирования системы, но для этого вам придется сначала зарегистрироваться как обычный пользователь, а затем получить привилегии root с помощью команды su.

• IgnoreRhosts. По умолчанию устанавливается значение yes данной опции, в результате чего сервер sshd игнорирует файл ~/.rhosts. Если опция IgnoreRhosts имеет значение по и если значение опции RhostsAuthentication равно yes, sshd, подобно rlogind, будет поддерживать аутентификацию по принципу доверия. Установка значения по опции IgnoreRhosts создает реальную опасность для системы.

• RhostsAuthentication. Для поддержки аутентификации по принципу доверия сервер SSH использует две опции: IgnoreRhosts и RhostsAuthentication. Опция RhostsAuthentication разрешает работу с узлами, пользующимися доверием. Желательно установить для данной опции значение no.

• RSAAuthentication. В версии 1 протокола SSH был предусмотрен метод аутентификации с применением открытого ключа, при котором пароль не передавался по сети. Вместо этого использовались открытый ключ и фраза пароля. Для того чтобы разрешить данный способ аутентификации, надо установить значение yes опции RSAAuthentication (это значение принимается по умолчанию).

• PubkeyAuthentication. Данная опция выполняет те же действия, что и опция RSAAuthentication, но применяется при работе с версией 2 протокола SSH.

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

• X11Forwarding. Как было сказано ранее, протокол SSH может быть использован для туннелирования X-соединений. Чтобы это стало возможным, соответствующая конфигурация должна быть установлена как для сервера, так и для клиентской программы. Значение yes опции X11Forwarding указывает на то, что сервер SSH должен перенаправлять соединения X Window. Опция аналогичного назначения предусмотрена и для клиента SSH. Имя этой опции — ForwardX11; она указывается в файле /etc/ssh/ssh_config.

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

 

Аутентификация при SSH-взаимодействии

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

Действия, выполняемые при SSH-аутентификации

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

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

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

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

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

Сервер хранит файлы, содержащие ключи, в каталоге /etc/ssh и применяет их при работе со всеми пользователями. SSH-клиенты получают открытые ключи от серверов и могут использовать их для аутентификации этих серверов. Открытые ключи хранятся в каталоге ~/.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. Как известно, по умолчанию при аутентификации на сервере 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 протокола SSH.

$ ssh -2 server

Внимание

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

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

• В п. 2 вместо -t rsa -f ~/.ssh/id_rsa следует указать -t rsa1 -f ~/.ssh/identity. При этом будет сгенерирована пара ключей RSA по соглашениям версии 1. Аналогичным образом надо изменить имена файлов на других стадиях процедуры.

• В п. 6 открытый ключ из identity.pub копируется не в authorized_keys2, а в файл authorized_keys.

• При установлении соединения, вызывая ssh, не надо указывать опцию -2.

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

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

Применение ssh-agent

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

• Создайте закрытый и открытый ключи, выполнив описанную выше процедуру, и скопируйте открытый ключ в свой рабочий каталог на сервере SSH. При вызове ssh-keygen не следует задавать опцию -N '', чтобы закрытый ключ был защищен фразой пароля.

• На компьютере, на котором выполняется клиентская программа SSH, задайте команду ssh-agent /bin/bash, и она запустит на выполнение программу ssh-agent и новую оболочку Bash. В результате ssh-agent будет контролировать все процессы, порожденные новой оболочкой. (При необходимости вы можете использовать вместо Bash другую оболочку.)

• Чтобы добавить RSA-ключ SSH к кэшу ключей ssh-agent, вызовите команду ssh-add ~/.ssh/id_rsa. (При использовании версии 1 SSH задавать ~/.ssh/id_rsa не следует.) Если ключ защищен фразой пароля, ssh-add запросит ее.

С этого момента вы можете обращаться к серверу SSH с помощью SSH-клиента; причем вам не придется вводить ни пароль, ни фразу пароля. Программа ssh-agent хранит ключи в памяти и устанавливает переменные окружения так, что клиент SSH взаимодействует с 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 для регистрации на удаленном компьютере. Данный подход применим только в том случае, когда регистрация в системе осуществляется в текстовом режиме. Если вы используете графическую среду, то для каждого нового окна xterm будет создаваться новое окружение ssh-agent, что приведет к непроизводительному расходу ресурсов.

• Если вы регистрируетесь в текстовом режиме и запускаете X Window с помощью startx, вы можете вместо этой команды задать ssh-agent startx. При этом ssh-agent становится родительской программой по отношению ко всем процессам X Window и может предоставлять им информацию о ключах.

• Если вы используете инструменты регистрации с графическим интерфейсом, вам надо сохранить файл .xsession (или другой файл аналогичного назначения) под именем .xsession-nosshagent, а затем создать новый файл .xsession, включив в него единственную команду ssh-agent ~/.xsession-nosshagent. В результате ssh-agent станет родительской программой для всех процессов X Window, и вам не придется повторно вводить ключи, добавленные в кэш программой ssh-add, даже если вы будете запускать клиент SSH из различных окон.

После запуска ssh-agent и указания ключей вы можете просмотреть введенные ключи, задав команду ssh-add -1. Для удаления ключей надо использовать команду ssh-add -d. Если после вызова ssh-add -d вы захотите установить SSH-соединение, вам придется повторно ввести ключ (или указать пароль).

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

 

Резюме

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

Наиболее часто в системе Linux используются серверы удаленной регистрации rlogind, Telnet и SSH. Из них наилучшую защиту обеспечивают средства SSH, поэтому именно их желательно использовать для установления соединения с Internet. (Существуют также разновидности Telnet, реализующие повышенный уровень защиты, но они применяются чрезвычайно редко.) Использование rlogind и Telnet оправдано в небольших локальных сетях, полностью контролируемых системными администраторами. В средах, в которых могут предприниматься попытки взлома систем, особенно в Internet, применять эти серверы не рекомендуется, так как их средства защиты не отвечают современным требованиям. Все три сервера достаточно просты в настройке. Если конфигурация, предложенная по умолчанию, не устраивает вас, вы можете без труда установить нужные параметры, изменяя значения опций. В особенности это относится к серверу SSH, в котором реализовано несколько механизмов аутентификации.

 

Глава 14

Организация удаленного доступа с помощью X Window и VNC

 

В главе 13 рассматривались серверы удаленной регистрации rlogind, Telnet и SSH. Совместно с клиентскими программами, выполняющимися на других компьютерах, эти серверы позволяют пользователям регистрироваться в системе Linux и выполнять приложения и утилиты, работающие в текстовом режиме. Поскольку в Linux (а также в UNIX) существует большое количество разнообразных программ, предоставляющих пользователю алфавитно-цифровой интерфейс, серверы удаленной регистрации дают возможность выполнять самые различные задачи. Однако многие пользователи предпочитают работать с инструментами, поддерживающими графический интерфейс. Подобные инструменты не могут выполняться в текстовом режиме, поэтому, зарегистрировавшись на удаленном компьютере с помощью rlogind, Telnet или SSH, нельзя запускать такие приложения, как The GIMP, Netscape Navigator или StarOffice. (Существуют программы, например Emacs, которые поддерживают как графический, так и текстовый интерфейс, но наличие такой поддержки является скорее исключением, чем правилом.) Чтобы предоставить доступ к программам с графическим интерфейсом, выполняющимся на удаленном компьютере, нужен специальный графический сервер. Наиболее часто для обеспечения графического пользовательского интерфейса в Linux используется система X Window. Являясь частью современных версий Linux, изначально она была создана для работы в сети, поэтому, для того, чтобы приложения с графическим интерфейсом могли выполняться, вам надо лишь установить на пользовательском компьютере соответствующие программы. Помимо X Window, для обеспечения работы приложений с графическим интерфейсом применяется также система VNC (Virtual Network Computing — вычисления в виртуальной сети), которая работает подобно X Window, но использует другие протоколы. Обе системы будут рассмотрены в данной главе.

 

Использование серверов удаленного доступа, поддерживающих графический интерфейс

Серверы удаленного доступа, поддерживающие графический интерфейс, в основном нужны тогда, когда компьютер должен выполнять роль рабочей станции для нескольких пользователей, работающих на удаленных компьютерах. Например, для рабочей группы, насчитывающей около десяти сотрудников, может быть приобретен один мощный компьютер и несколько компьютеров малой мощности, которые будут выполнять функции терминалов центральной машины. На центральном компьютере можно запускать приложения, интенсивно потребляющие ресурсы, например StarOffice, The GIMP, KMail и др. Пользователи, работающие на маломощных машинах, могут регистрироваться в центральной системе и запускать приложения на удаленном компьютере. Такая структура имеет ряд преимуществ по сравнению с конфигурацией, при которой каждый пользователь запускает необходимые ему программы на своей рабочей станции. Эти преимущества описаны ниже.

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

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

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

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

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

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

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

Средства удаленной регистрации, поддерживающие графический интерфейс, чаще всего применяются в локальных сетях. Поскольку для отображения графических элементов приходится передавать большой объем данных, использование соответствующих протоколов при работе в Internet существенно снизит скорость отображения информации. Даже в сети с пропускной способностью 100 Мбод применение протоколов удаленной регистрации заметно уменьшает быстродействие программ по сравнению с выполнением их на локальной машине, однако скорость работы остается в допустимых пределах. Подобно инструментам, которые осуществляют регистрацию в текстовом режиме, серверы, поддерживающие графический интерфейс, предоставляет пользователю все привилегии, необходимые для работы на удаленном компьютере. Однако при регистрации производится передача пароля в незакодированном виде, что создает опасность для системы. (Инструмент VNC предусматривает шифрование паролей; это несколько снижает риск, но остальные данные передаются в незашифрованном виде. Использование SSH в дополнение к средствам удаленной регистрации обеспечивает кодирование как паролей, так и всей информации, передаваемой в течение сеанса.)

 

Обеспечение удаленного доступа средствами X Window

 

Графическая среда, реализуемая средствами X Window, очень часто используется в системе Linux. Как было сказано ранее, система X Window поддерживает взаимодействие по сети. Даже если все компоненты X-программы выполняются на одном и том же компьютере, для отображения окон, меню, диалоговых окон и других элементов графического интерфейса используются сетевые протоколы. Чтобы правильно сконфигурировать клиент и сервер для обеспечения удаленного доступа с поддержкой графического интерфейса, необходимо ясно представлять себе работу этих протоколов.

 

Взаимодействие клиента и сервера в системе X Window

Пользователи, не искушенные в вопросах применения вычислительной техники и сетевых протоколов, представляют себе сервер как большой мощный компьютер, находящийся в отдельной комнате. Пользователи работают за клиентскими машинами и время от времени обращаются к серверу. Такое представление, хотя и не идеально с технической точки зрения, не слишком далеко от истины. Действительно, в качестве сервера обычно используется мощный компьютер, а мощность клиентских компьютеров, взаимодействующих с сервером, часто бывает ограничена. Однако по отношению к системе 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-сервера для взаимодействия с X-клиентом

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

Использование программы xhost

Программа xhost позволяет указанному при ее вызове удаленному компьютеру обращаться к X-серверу. Для того чтобы воспользоваться данной программой, надо в окне xterm или другом окне, поддерживающем командную строку, ввести следующую команду:

$ xhost +biggie.threeroomco.com

В результате ее выполнения X-сервер получает указания о том, что он должен принимать обращения от компьютера biggie.threeroomco.com. Любой пользователь, работающий на этом компьютере, сможет использовать X-сервер для отображения окон, получать данные, введенные с клавиатуры, принимать информацию о перемещениях мыши и выполнять другие действия с удаленными системами отображения. Если вы не укажете имя узла (а ограничитесь лишь вводом команды xhost +), X-сервер будет принимать обращения от любого источника.

На заметку

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

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

Использование программы xauth

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

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

1. На компьютере, на котором выполняется сервер X Window, введите команду xauth. При этом утилита xauth будет запущена от имени пользователя, который применит систему для взаимодействия с удаленным узлом. Несмотря на то что xauth формально является X-утилитой, она выполняется в текстовом режиме.

2. Введите команду list. При ее выполнении будет выведена информация о ключах, содержащихся в файле .Xauthority. Каждый ключ начинается с имени дисплея, которое представляет собой имя узла, а за ним следует номер дисплея, например term.threeroomco.com:0. Имена некоторых компьютеров сопровождаются символами /unix, кроме того, по команде list будут также выведены записи для localhost. Оба типа записей можно не принимать во внимание. В некоторых записях номера дисплеев будут отличаться от 0. Эти записи соответствуют второму, третьему и последующим сеансам работы с X-сервером, которые поддерживаются одновременно с первым сеансом. Вас интересует имя основного дисплея? Вероятнее всего, оно будет состоять из имени вашего компьютера, за которым следует номер 0. После имени дисплея в строке будут отображаться также тип кодировки (например, MIT-MAGIC-COOKIE-1) и 32-байтовое шестнадцатеричное число. Несмотря на то что эти данные предназначены для передачи, их можно не учитывать.

3. Введите команду extract имя_файла имя_дисплея . Здесь имя файла может быть любым, а имя дисплея — это имя, которое вы выяснили на предыдущем шаге процедуры. Например, вы можете задать команду extract xfer-auth term.threeroomco.com:0. В результате запись файла .Xauthority для дисплея будет скопирована в указанный файл. Файл используется для передачи ключа на клиентский компьютер.

4. Введите команду exit, чтобы завершить работу с программой xauth.

5. Скопируйте файл, созданный при выполнении команды extract, да клиентский компьютер (удаленный компьютер, на котором расположена программа, предназначенная для выполнения). Сделать это можно различными способами: использовать средства FTP или NFS, перенести файл на дискете и т.д.

6. Зарегистрируйтесь на компьютере, выполняющем функции X-клиента.

7. Задайте команду xauth, чтобы запустить утилиту xauth на клиентской машине.

8. Введите команду merge имя_файла . В этой команде должно быть указано имя файла, которое вы сгенерировали посредством команды extract и скопировали на клиентский компьютер. (Возможно, вам придется указать путь к файлу.)

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

10. Введите команду exit, чтобы завершить работу xauth и сохранить внесенные изменения. (Заметьте, что в xauth также предусмотрена команда quit, которая не сохраняет изменения. Команду quit надо использовать в том случае, если при выполнении данной процедуры были допущены ошибки.)

Если на обоих компьютерах инсталлированы средства SSH, вы можете вместо описанной выше процедуры выполнить единственную команду.

# xauth list x_сервер :0 | sed -e 's/^ /add /' | ssh \

 x_клиент -х xauth

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

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

• Между add и последующей косой чертой (/) должен быть пробел. Эта команда передается утилите xauth на клиентском компьютере, и пробел должен отделять add от имени дисплея.

• Если конфигурация SSH предполагает ввод пароля либо фразы пароля, вам придется ввести соответствующие данные.

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

Поскольку работа xauth основана на применении ключа, который известен только серверу и авторизованному клиенту, она обеспечивает более высокий уровень защиты, чем xhost. Кроме того, при использовании xauth доступ к серверу предоставляется только отдельным пользователям. X-сервер становится более устойчивым к атакам, осуществляемым путем подмены IP-адреса. Недостатком данного способа является передача ключей в незакодированном виде. Если локальная сеть не обеспечивает безопасность передаваемых данных либо если клиент с сервером взаимодействуют по Internet, ключ может быть похищен и злоумышленник получит доступ к X-серверу. Если при обмене данными в системе X Window необходимо обеспечить высокий уровень защиты, надо использовать SSH-соединение. Вопросы поддержки X-взаимодействия посредством SSH будут подробно рассмотрены в следующем разделе.

На заметку

Не все X-серверы сконфигурированы для работы с xauth . Соответствующая опция обычно устанавливается в том случае, когда X-сервер запускается посредством XDM, GDM или KDM. Если вы запускаете X-сервер с помощью startx , поддержка xauth в ряде систем будет отсутствовать. В некоторых случаях вам придется отредактировать сценарий startx (он обычно располагается в каталоге /usr/X11R6/bin ) так, чтобы в нем присутствовала опция -auth файл_авторизации ; в качестве файла авторизации обычно указывается файл .Xauthority , находящийся в рабочем каталоге. Часто в редактировании startx нет необходимости.

 

Настройка X-клиента для работы с Х-сервером

Независимо от того, используете ли вы xhost или xauth, вы должны сконфигурировать клиентскую систему для работы с нужным X-сервером. Если, например, вы работаете за компьютером term.threeroomco.com, зарегистрировались на узле biggie.threeroomco.com и хотите, чтобы программа использовала компьютер wrongone.threeroomco.com в качестве X-терминала, вам не удастся сделать это. По умолчанию многие версии Linux сконфигурированы так, что даже если пользователь зарегистрировался с внешнего узла, они будут работать с локальным X-сервером.

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

$ echo $DISPLAY

biggie.threeroomco.com:0.0

Если отображаемая с помощью этой команды строка (в данном случае biggie.threeroomco.com:0.0) соответствует вашему серверу, вам не надо предпринимать никаких действий. (Первый дисплей обычно имеет номер 0 или 0.0; эти два значения эквивалентны.) Если же значение переменной DISPLAY указывает на X-клиент или другую систему либо если оно вовсе не определено, вам надо задать новое значение данной переменной. Необходимая для этого команда выглядит следующим образом:

$ export DISPLAY=term.threeroomco.com:0

Очевидно, что имя узла должно определять ваш X-сервер. При последующих запусках X-программа будет пытаться взаимодействовать с указанным сервером. Чтобы эти попытки были успешными, вам надо настроить X-сервер для работы с X-клиентом, т.е. запустить программу xhost, или создать запись xauth для клиента.

 

Туннелирование X-соединений через SSH

Из материала, рассмотренного ранее в данной главе, следует, что для инициализации Х-соединения используются два отдельных, независимых друг от друга протокола. Во-первых, работая на компьютере, выполняющем роль X-сервера, вы используете клиент-программу удаленной регистрации, работающую в текстовом режиме, например программу telnet. Во-вторых, после установления соединения вы инициируете взаимодействие X-клиента с X-сервером. Выполнив основные действия по установке соединений, вы можете вызвать на своем компьютере любую команду, например xclock, и соответствующая программа (в данном случае xclock) будет выполняться на удаленном компьютере. Данная конфигурация подходит для решения многих задач, но при ее использовании могут возникать проблемы. Одна из этих проблем связана с тем, что в сеансе X-взаимодействия данные передаются в незакодированном виде и могут быть перехвачены. Тот факт, что на каждом из взаимодействующих компьютеров должен выполняться сервер, также можно считать недостатком. Если эти компьютеры разделены брандмауэром или маршрутизатором, осуществляющим маскировку пакетов, эти программы должны быть сконфигурированы специальным образом, иначе обмен по протоколу X Window станет невозможным. Одно из возможных решений обеих проблем состоит в использовании протокола SSH. Этот протокол может применяться как для установления начального соединения между X-клиентом и X-сервером, так и для туннелирования данных, передаваемых в рамках этого соединения.

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

• В конфигурационном файле/etc/ssh/ssh_config клиентской программы SSH (эта программа выполняется на том компьютере, на котором расположен X-сервер) следует задать значение yes опции ForwardX11. Аналогичный результат можно получить, указав при запуске ssh опцию -X. (Обратите внимание на регистр символа; если в опции -х вы зададите символ нижнего регистра, туннелирование будет запрещено.)

• В файле/etc/ssh/sshd_config на компьютере, на котором выполняется SSH-сервер (эта машина играет роль клиента в X-взаимодействии), опция X11Forwarding должна иметь значение yes. Эта опция сообщает серверу SSH о том, что локальные вызовы X-сервера должны перехватываться и направляться SSH-клиенту.

При туннелировании X-соединения сервер SSH "подменяет" локальный X-сервер. Если конфигурация установлена правильно, средства поддержки SSH устанавливают переменную окружения DISPLAY таким образом, что X программы передают данные через порт локального X-сервера (по умолчанию это X-сервер 10, или TCP-порт 6010). С этим портом связывается сервер SSH. Вместо того чтобы отображать информацию на локальной машине, сервер SSH кодирует ее и передает клиенту SSH. Клиент, в свою очередь, запрашивает локальный X-сервер (он определяется значением переменной окружения DISPLAY на этом компьютере), а данные, полученные в результате этого обращения, передает серверу SSH, который доставляет информацию X-клиенту. Таким образом, сервер SSH "выдает себя" за X-сервер, а клиент SSH "подменяет" клиентскую программу X Window.

Такой подход имеет ряд преимуществ по сравнению с обычным 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-взаимодействия

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

1. Запуск X-сервера. Если вы используете систему Linux, средства X-регистрации могут быть предусмотрены при загрузке. Некоторые конфигурации системы предполагают запуск X-сервера по команде startx. В Windows, MacOS и других средах X-сервер надо запускать вручную либо настраивать операционную систему для автоматического запуска соответствующей программы.

2. Настройка X-сервера для установления соединения. Для того чтобы X-взаимодействие могло осуществляться, необходимо сообщить серверу X Window о том, что он должен обрабатывать запросы от удаленных компьютеров на установление соединений. Это можно сделать, запуская программу xhost на компьютере, на котором установлен X-сервер, либо передавая ключ xauth клиентской системе. Если вы используете SSH для туннелирования соединения, действия, выполняемые на этом шаге, не обязательны, но при этом вам необходимо сконфигурировать клиент SSH и сервер SSH.

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. Если при настройке подобного сервера были указаны пользовательское имя и пароль, то после щелчка на соответствующей кнопке будет запускаться X-сервер и отображаться окно xterm. Подробные сведения о каждом типе X-сервера можно найти в документации на него.

В результате выполнения описанной выше процедуры программа на удаленном компьютере выводит свои данные на экране 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 представляли окно регистрации, генерируемое на удаленном компьютере.

 

Принцип действия XDMCP

В предыдущих разделах был рассмотрен принцип использования X-соединений, предполагающий применение протокола удаленной регистрации, например Telnet. Сервер Telnet располагался на том же компьютере, что и X-клиент; с его помощью пользователь регистрировался на удаленном компьютере, после чего устанавливалось X-соединение между клиентом и сервером. Сервер XDMCP успешно заменяет Telnet, SSH и другие протоколы удаленной регистрации, обеспечивающие взаимодействие в текстовом режиме. Когда пользователь обращается к удаленной системе с помощью Telnet, сервер Telnet регистрирует его и предоставляет текстовую оболочку. Средства XDMCP действуют подобным образом, но вместо текстовой оболочки сервер XDMCP инициирует процедуру регистрации X Window; при этом отображается окно для ввода пользовательского имени и пароля и загружается диспетчер окон, среда рабочего стола и другие компоненты графического интерфейса. Эти программы запускаются посредством X-соединения; XDMCP автоматически конфигурирует клиентскую и серверную программы, используя xauth. Другими словами, XDMCP автоматизирует описанную ранее процедуру регистрации.

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

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

 

Настройка сервера регистрации для установления соединения

Для настройки сервера XDMCP используются конфигурационные файлы, которые обычно находятся в каталогах /etc и /etc/X11. Исходя из сообщений защиты, большинство дистрибутивных пакетов сконфигурировано так, что обращения к серверу возможны только с локального узла. Чтобы разрешить удаленную XDCMP-регистрацию, необходимо снять данные ограничения. Кроме того, надо обеспечить выполнение сервера XDMCP. В настоящее время в системе Linux используются три сервера XDMCP: X Display Manager (XDM) и более новые продукты — KDM (KDE Display Manager) и GDM (GNOME Display Manager).

Настройка XDM

XDM — наиболее простой среди серверов XDMCP; он был разработан раньше других продуктов подобного назначения. В отличие от GDM и KDM, XDM не связан с окружением рабочего стола Linux. Он дает возможность пользователям вводить имена и пароли, но не позволяет указывать дополнительные сведения, например задавать диспетчер окон. Для управления регистрационными параметрами пользователя служит файл .xsession, расположенный в его рабочем каталоге. (Данный сценарий запускается из сценария Xsession, который располагается в каталоге /etc/X11 или /etc/X11/xdm.) Файл .xsession, соответствующий конкретному пользователю, обычно заканчивается строкой, которая запускает диспетчер окон или среду рабочего стола. По завершении сценария (это происходит, когда пользователь выходит из системы, прекращая тем самым работу диспетчера окон) завершается X-сеанс и XDM прекращает удаленное взаимодействие, либо при использовании локального дисплея XDM повторно отображает приглашение для регистрации.

Обеспечение доступа к XDM

Доступом удаленных компьютеров XDM управляет основной конфигурационный файл /etc/X11/xdm/xdm-config. В большинстве дистрибутивных пакетов в составе этого файла содержится следующая строка:

DisplayManager.requestPort: 0

Данная запись указывает XDM на то, что он не должен принимать обращения через UDP-порт 177. Если вы хотите, чтобы пользователи с других компьютеров могли регистрироваться посредством XDMCP, вам надо закомментировать данную строку (включить в ее начало символ #).

Помимо редактирования файла xdm-config, вам, возможно придется внести изменения в файл /etc/X11/xdm/Xaccess. В этом файле указаны компьютеры, которым разрешен доступ к серверу XDM. Данный файл состоит из набора записей, каждая из которых занимает одну строку. В составе записи указываются имя узла и тип доступа, разрешенный для него. (Символ # в начале строки является признаком комментариев.) Если тип доступа не указан, клиенту разрешены непосредственные обращения к серверу. Значение CHOOSER определяет действия сервера при получении косвенного запроса от клиента, а значение BROADCAST, которое чаще всего используется в сочетании с CHOOSER, указывает на то, что при получении косвенного запроса он должен передаваться остальным серверам XDMCP в широковещательном режиме. Если вместо имени узла указан символ *, это означает, что любой клиент имеет право устанавливать соединение с сервером XDM. Например, приведенные ниже записи позволяют любому клиенту обращаться к серверу непосредственно или использовать его для передачи косвенного запроса.

*

* 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 указывается список устройств, которыми может управлять сервер XDM. При запуске XDM пытается непосредственно обратиться к этим дисплеям и вывести окно регистрации. По умолчанию в данный файл помещается следующая строка (в зависимости от особенностей системы конкретная запись может несколько отличаться от приведенной ниже):

:0 local /usr/X11R6/bin/X

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

term.threeroomco.com:0 foreign

В этом примере foreign указывает на то, что заданная система является удаленной. Система может быть сконфигурирована так, что соединение с сервером XDMCP и отображение окна регистрации будет разрешено. Редактируя файл Xservers, вы можете также удалить включенную по умолчанию запись local. Если вы сделаете это, компьютер не будет загружать локальный X-сервер при запуске XDM. Такая конфигурация может потребоваться, если вы организуете работу с мощным центральным компьютером через X-терминалы. В таком случае на компьютере будет выполняться много X-программ, но ни одна из них не будет взаимодействовать с локальным X-сервером.

На заметку

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

Настройка KDM

Сервер был разработан для замены существующего 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, который автоматически учитывает диспетчер окон или среду рабочего стола в конфигурации KDM или GDM. Чтобы это стало возможным, диспетчер окон или среда рабочего стола должны поставляться с соответствующими конфигурационными файлами. В большинстве случаев пользователю проще настроить окружение, отредактировав файл .xsession, находящийся в его рабочем каталоге. Для того чтобы система использовала этот файл, пользователь должен выбрать при работе с KDM специальный пункт под названием Default.

Настройка GDM

Подобно KDM, сервер GDM предоставляет пользователям возможность выбрать окружение рабочего стола, а также завершить работу локального компьютера или сеанс удаленного взаимодействия. Однако, в отличие от KDM, GDM использует собственные конфигурационные файлы, которые обычно хранятся в каталоге /etc/X11/gdm. Наиболее важным из них является файл gdm.conf.

Как и большинство систем, использующих серверы XDMCP, системы, включающие GDM, конфигурируются так, чтобы пользователи не могли регистрироваться с удаленных узлов. Чтобы отказаться от этого ограничения, надо изменить одну или две записи в разделе [xdmcp] файла gdm.conf. Строку Enable=0 следует заменить на Enable=1. Если вы хотите, чтобы GDM предоставлял X-терминалу список других компьютеров, работающих с XDMCP, вам надо заменить HonorIndirect=0 на HonorIndirect=1.

Если вы хотите, чтобы GDM был доступен для удаленных узлов, а локальный X-сервер не запускался, вам надо закомментировать строку, соответствующую локальным серверам в разделе [servers]. Как правило, в этом разделе находится следующая запись:

0=/usr/bin/X11/X

Эта запись указывает GDM на то, что X-сервер (программа /usr/bin/X11/X) должен быть запущен для управления первым X-сеансом. Если в начало этой строки будет включен символ комментариев, GDM не будет управлять локальным устройством отображения или запускать X-сервер.

Подобно KDM, GDM позволяет пользователю выбрать диспетчер окон или окружение рабочего стола. (В GDM для этого предназначено меню Session.) Для добавления или удаления сеансов надо создать соответствующие сценарии в каталоге /etc/X11/gdm/Sessions. По умолчанию обычно используется сценарий /etc/X11/xdm/Xsession. Вам необходимо отредактировать данный сценарий или создать новый, выполняющий подобные действия, реализовав в нем возможность загрузки другого диспетчера окон или окружения рабочего стола. В большинстве систем пользователь может настраивать среду посредством редактирования файла

Запуск сервера XDMCP

Чтобы обеспечить запуск сервера XDMCP, надо настроить компьютер для работы с X Window и приема запросов на регистрацию. В большинстве дистрибутивных версий для этой цели зарезервирован уровень выполнения 5, но в некоторых случаях используются и другие уровни. Например, в версиях SuSE, предшествующих версии 7.2, регистрация с применением графического интерфейса производится на уровне 3, а в Slackware для этого используется уровень 4. В Debian и системах, созданных на ее основе, средства X Window выполняются на всех уровнях, допускающих работу нескольких пользователей.

Уровень по умолчанию задается с помощью специальной записи в файле /etc/inittab, которая выглядит приблизительно следующим образом:

id:5:initdefault:

Во многих дистрибутивных пакетах данной записи предшествуют комментарии, объясняющие ее назначение. Номер уровня содержится во втором поле; именно на этот уровень система переходит после загрузки. Если на компьютере установлены средства X Window, сервер XDCMP также будет загружен.

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

Совет

Если вы вносите изменения в конфигурацию сервера XDMCP, вам надо обеспечить, чтобы новая конфигурация была учтена при работе сервера. Сделать это вы можете, перейдя на уровень, обеспечивающий работу только в текстовом режиме, а затем вернувшись на уровень, допускающий выполнение X-программ. Для перехода на другой уровень используется утилита telinit . Кроме того, вы можете остановить работу сервера XDMCP, вызвав команду kill или killall , а затем запустить сервер снова. Для того чтобы сервер XDMCP повторно прочитал содержимое конфигурационных файлов, ему можно передать сигнал SIGHUP ; в этом случае завершать работу сервера нет необходимости.

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

• prefdm . В некоторых дистрибутивных пакетах Linux, например, в системах Red Hat и Mandrake, для загрузки сервера XDMCP применяется сценарий с именем prefdm (он находится в каталоге /etc/X11). Для выбора среды рабочего стола и сервера XDMCP данный сценарий читает файл /etc/sysconfig/desktop. Обычно в этом файле содержатся значения KDE, GNOME и AnotherLevel, которые задают в качестве XDMCP-сервера соответственно KDM, GDM и XDM.

• Сценарии запуска SysV. В Debian и системах, созданных на ее основе, запуск сервера XDMCP осуществляется посредством сценария SysV, например /etc/init.d/xdm. Заменив или отредактировав этот файл, вы можете задать использование другого сервера XDMCP. Аналогичный способ применяется в системе SuSE, но тип сервера XDMCP, запускаемого с помощью сценария определяет значение переменной окружения DISPLAYMANAGER, которое задается в файле /etc/rc.config.

• Прочие сценарии запуска. Для запуска сервера XDMCP в системе Slackware применяется сценарий /etc/rc.d/rc.4. Как было сказано в главе 4, в Slackware в явном виде не используется механизм уровней выполнения, но сценарий rc.4 выполняет те же функции, что и сценарий xdm в системах Debian и SuSE. В Caldera применяется тот же подход, но сценарий запуска называется /etc/rc.d/rс.gui. Код сценария для Slackware составлен так, что сначала предпринимается попытка запустить KDM, затем GDM, а потом XDM. Сценарий в системе Caldera запускает только KDM. Отредактировав код сценария, вы можете изменить порядок вызова серверов.

 

Настройка клиента удаленной регистрации

Подобно другим серверам, 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). В последнем случае сервер XDMCP отобразит на экране компьютера, выполняющего функции X-сервера, окно регистрации. Если вы перезапустите X-сервер, окно регистрации исчезнет и отобразится только после перезапуска сервера XDMCP.

• 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. Пример вызова X-сервера приведен ниже.

$ /usr/X11R6/bin/X -indirect xdmcp-server.threeroomco.com

Приведенные выше опции действуют так же, как и опции X-сервера для Windows, за одним исключением. Опция -broadcast не приводит к отображению списка доступных узлов; клиент устанавливает соединение с первым сервером XDCMP, который отвечает на запрос.

Совет

При желании вы можете сконфигурировать компьютер под управлением Linux как выделенный X-терминал. Конфигурацию следует задать так, чтобы X-сервер не запускался автоматически посредством сервера XDMCP. Затем следует создать сценарий запуска, который вызывал бы X-сервер с указанием требуемой опции: -query , -broadcast или -indirect . Если вы хотите отобразить список доступных локальных серверов, вам надо сконфигурировать один из серверов XDMCP так, чтобы он обрабатывал косвенные запросы, и указать при запуске X-сервера опцию -indirect . Таким образом, можно реализовать X-терминал даже посредством компьютера с процессором 386.

 

Обеспечение удаленного доступа с помощью сервера VNC

 

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

 

Взаимодействие клиента и сервера VNC

Излагая материал данной главы, я пытался обратить внимание на роль различных клиентских и серверных программ в процессе сетевого взаимодействия. Как вы уже знаете, один и тот же компьютер может действовать как сервер по одному протоколу и выполнять функции клиента по другому протоколу. Рассматривая 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) или TridiaVNC (http://www.developvnc.org). Кодирование с целью уменьшения объема передаваемых данных занимает ресурсы процессора, поэтому TightVNC или TridiaVNC желательно использовать тогда, когда на обоих концах соединения находятся быстродействующие компьютеры. Сжатие данных может также осуществляться при туннелировании VNC через SSH. При этом, в зависимости от пропускной способности линий и быстродействия процессора, эффективность работы может увеличиться либо уменьшиться.

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

 

Инсталляция сервера VNC

Программу, реализующую сервер VNC, можно получить с Web-узла VNC http://www.uk.research.att.com/vnc/. Сервер и клиент VNC поставляются со многими версиями Linux (VNC распространяется в исходных кодах). Иногда и клиент, и сервер входят в состав одного пакета (такой пакет обычно называется vnc), а иногда оформляются в виде разных пакетов (в этом случае пакеты называются vncserver и vnc). Процедура инсталляции Tight VNC и Tridia 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. Владельцем этого каталога должен быть сам пользователь. В этом каталоге будут содержаться конфигурационные файлы, в том числе файл пароля. Чтобы предотвратить утечку информации, необходимо установить права доступа 700 (rwx-------).

4. От имени пользователя, работающего с VNC, введите команду vncpasswd. Как нетрудно догадаться, с помощью утилиты vncpasswd задается пароль. В отличие от большинства других серверов регистрации, VNC не полагается на результаты процедуры аутентификации, проведенной средствами Linux. (Если VNC работает совместно с сервером XDMCP, за аутентификацию отвечает Linux, поэтому вы можете не выполнять пп. 3 и 4 данной процедуры.)

На заметку

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

 

Запуск сервера VNC

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

$ vncserver

New 'X' desktop is vncserv.threeroomco.com:1

Starting applications specified in /home/rodsmith/.vnc/xstartup

Log file is /home/rodsmith/.vnc/vncserv.threeroomco.com:1.log

Обратите внимание на данные, отображаемые при выполнении команды; особенно для вас важен номер рабочего стола. В приведенном выше примере это номер 1 — число, которое отображается после имени узла (vncserv.threeroomco.com:1). В процессе работы VNC запускает X-сервер (программа Xvnc). Этот X-сервер можно рассматривать как сервер, запускаемый посредством команды startx; он формирует среду рабочего стола или диспетчер окон. Если несколько пользователей запускают серверы с одного компьютера, необходимы средства, позволяющие идентифицировать их. В качестве идентификатора используется номер X-сервера. Номер 0 обычно выделяется для X-сервера, связанного с консолью, поэтому первому серверу VNC, вероятнее всего, будет соответствовать номер 1. В последующих сеансах VNC будут использоваться номера 2, 3 и т.д.

Внимание

Если вы зарегистрируетесь на удаленном узле средствами SSH и попытаетесь вызвать сервер VNC, вы, возможно, обнаружите, что выполняется только сервер VNC, а остальные программы (в том числе диспетчеры окон) не работают. В результате вы увидите экран, заполненный фоновым цветом без окон. Так происходит потому, что SSH пытается установить конфигурацию xauth в соответствии с настройкой своих средств туннелирования X-взаимодействия. Чтобы избавиться от этой проблемы, нужно перед запуском vncserver задать команду export XAUTHORITY=~/.Xauthority , в результате выполнения которой будут восстановлены установки по умолчанию. Можно также скопировать записи из файла, используемого по умолчанию, во временный файл SSH.

Закончив работу с сервером VNC, надо завершить сеанс взаимодействия, указав для этого опцию -kill:

$ vncserver -kill:1

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

 

Использование клиента VNC для взаимодействия с сервером

Программа, реализующая функции клиента VNC в системе Linux, называется vncviewer. Для вызова клиента надо ввести имя программы и, возможно, имя сервера и номер дисплея.

$ vncviewer vncserv.threeroomco.com:1

VNC server supports protocol version 3.3 (viewer 3.3)

Password:

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

Если вы не укажете номер дисплея, клиент VNC попытается подключиться к дисплею с номером 0, который в системе Linux не работает, так как используется локальным X-сервером. Без указания номера дисплея можно обращаться к серверу VNC, работающему в системе Windows или MacOS. Если вы не зададите имя узла, клиент VNC отобразит диалоговое окно, в котором предложит вам ввести имя узла и пароль.

Клиенты, предназначенные для работы в Windows и MacOS, действуют аналогично клиенту VNC Linux. Для запуска программы надо дважды щелкнуть на соответствующей пиктограмме, в результате чего клиент отобразит диалоговое окно для ввода имени сервера VNC и номера дисплея (например, vncserv.threeroomco.com:1). Если имя узла задано верно, у пользователя запрашивается пароль, после ввода которого будет выведено окно с рабочим столом сервера

 

Настройка сервера VNC

VNC представляет собой удобный инструмент удаленного доступа, но при использовании могут возникать проблемы. В частности, многие пользователи сообщают об ошибках, возникающих при совместной работе редактора NEdit (http://www.nedit.org) и VNC. В моей системе NEdit не реагировал на нажатие клавиш, т.е. оказался совершенно непригоден к использованию. К счастью, серьезные ошибки, подобные этой, возникают достаточно редко. В большинстве случаев проблему удается решить с помощью настройки компонентов VNC. Xарактеристики VNC можно задавать, редактируя сценарий, используемый для запуска сервера, либо изменяя содержимое конфигурационных файлов.

Установка основных характеристик сервера

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

• Автоматическая установка параметров, используемых по умолчанию. В последних версиях vncserver для определения размера дисплея, числа битов, используемых для представления цвета, и других параметров применялся вызов &GetXDisplayDefaults(). Однако при этом может быть получено значение размера, не подходящее для клиента. Если вы хотите изменить размер экрана, вам надо закомментировать данную строку, поместив в начале ее символ #, и указать размер экрана явным образом. В сценарии, поставляемом в составе пакета, размер экрана устанавливается до вызова &GetXDisplayDefaults().

• Размер экрана. При запуске программа Xvnc создает виртуальный экран определенного размера. Если вы не используете опции по умолчанию, установите размер экрана с помощью переменной $geometry. Например, чтобы задать размер 900×675, надо включить в состав сценария следующую строку:

$geometry = "900x675";

Совет

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

• Глубина цвета. Включив в состав сценария переменную $depth, вы можете контролировать число битов, используемых для представления цвета. Во многих случаях для кодирования цвета бывает достаточно 16 битов, однако программы, воспроизводящие большое количество разнообразных цветов, могут искажать данные, отображаемые другими программами. Это правило не распространяется на VNC; 16-битовое представление может привести к некорректному отображению цвета. В будущем данная проблема, скорее всего, будет решена.

• Шрифт, или путь к шрифту. Сценарий, поставляемый в составе пакета, по умолчанию настроен для использования сервера шрифтов. Изменить эту настройку можно с помощью раздела Add font path and color database stuff here. Для добавления шрифта используется параметр -fp в строке $cmd, которая используется при вызове Xvnc. При необходимости вы можете сконфигурировать VNC для работы с сервером шрифтов. Использованием сервера шрифтов описано в главе 15.

• Диспетчер окон, используемый по умолчанию. Сценарий vncserver, поставляемый в составе дистрибутивного пакета, содержит переменную $defaultXStartup, определяющую содержимое пользовательского сценария запуска. При первом запуске сценарий vncserver помещает соответствующий файл в пользовательский каталог. По умолчанию задан диспетчер окон который в настоящее время используется достаточно редко. Вы можете отказаться от значения, заданного по умолчанию, и заменить вызов twm на вызов другого диспетчера окон или среды рабочего стола, например startkde, sawmill или icewm. Изменения, внесенные в сценарий vncserver, повлияют на работу только тех пользователей, которые еще не запускали данный сценарий. Ниже будет рассмотрены средства установки конфигурации для существующих пользователей.

Даже если вы плохо знакомы с языком Perl, просмотрев данный сценарий, вы найдете сведения о многих характеристиках, которые, возможно, захотите изменить. В основном данный сценарий устанавливает опции, которые должны быть указаны при запуске Xvnc; они помещаются в строку $cmd. Разобравшись в том, как формируются опции, вы сможете легко модифицировать их. По команде Xvnc -help &> Xvnc-help.txt создается текстовый файл с именем Xvnc-help.txt, содержащий информацию о доступных опциях Xvnc.

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

Сценарии vncserver, входящие в состав некоторых пакетов, существенно отличаются от исходного варианта. Особенно это относится к сценарию, поставляемому в составе системы Debian. Тем не менее советы, приведенные выше, применимы ко всем разновидностям vncserver. Необходимо лишь перед внесением изменений ознакомиться с конкретными особенностями сценария. Например, сценарий для системы Debian создает для определения шрифта переменную $fontpath.

Изменение параметров для отдельных пользователей

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

• Самостоятельно создать сценарий запуска сервера VNC. Пользователь может скопировать сценарий в свой каталог, модифицировать его и использовать в дальнейшем для запуска сервера.

• Организовать передачу опций сценарию. Сценарий vncserver обрабатывает несколько опций, которые могут быть использованы для переопределения значений, заданных по умолчанию. Например, опция -geometry ширина_и_высота устанавливает размер рабочего стола. Эти опции в основном совпадают с опциями программы Xvnc.

• Редактировать отдельные конфигурационные файлы. Стандартный сценарий запуска сервера перед окончанием своего выполнения вызывает сценарий ~/.vnc/xstartup. В нем содержатся команды запуска диспетчера окон и xterm. Пользователь может редактировать этот файл так же, как и обычный сценарий запуска X Window. В некоторых дистрибутивных пакетах имя и расположение этого сценария отличается от указанных здесь. Например, в системе Debian вызывается сценарий /etc/X11/Xsession, который, в свою очередь, запускает пользовательский сценарий .xsession.

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

Совместная работа серверов XDMCP и VNC

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

Подобно большинству X-серверов, VNC X-сервер позволяет серверу XDMCP управлять отображением данных. Для того, чтобы это стало возможным, вам надо указать при запуске VNC X-сервера опцию -query имя_узла . Если вы используете суперсервер xinetd, соответствующая запись в конфигурационном файле будет выглядеть следующим образом:

service vnc

{

 disable = no

 socket_type = stream

 protocol = tcp

 wait = no

 user = nobody

 server = /usr/local/bin/Xvnc

 server_args = -inetd -query vncserv -once

}

В данном случае важно правильно задать параметры сервера. В частности, опция -inetd сообщает Xvnc о том, что он запущен посредством суперсервера, -query vncserv означает, что необходимо обратиться к vncserv. Опция -once свидетельствует о том, что сервер должен быть вызван однократно, а затем прекратить свою работу; в результате, если пользователь завершит сеанс взаимодействия, соединение будет разорвано. Вы можете также использовать и другие опции Xvnc, например -geometry или -fp. Кроме того, в файле /etc/services должно присутствовать описание порта.

vnc 5900/tcp

Для обычных соединений VNC использует номера портов 5900-5999, а порты 5800-5899 применяются для обработки обращений посредством Web-броузера (поддержки режима Java-сервера). Порт 5900 соответствует дисплею 0, порт 5901 — дисплею 1 и т.д. Таким образом, приведенное выше описание задает отображение приглашения к регистрации XDMCP и взаимодействие VNC через порт 0. Очевидно, что сервер XDMCP должен выполняться на компьютере, определенном посредством опции -query. Вы можете настроить систему так, чтобы она по-разному реагировала на обращения клиента через различные порты. Например, дисплею 0 может соответствовать размер рабочего стола 800×600, дисплею 1 — размер 1024×768 и т.д. Для идентификации таких серверов необходимо поместить в файл /etc/services несколько записей: по одной на каждый порт. Настроенный таким образом сервер VNC не требует ввода пароля — все детали взаимодействия обеспечивает сервер XDMCP. (Заметьте, что в отличие от традиционного VNC-взаимодействия, имя пользователя и пароль передаются в незакодированном виде.) Еще одна особенность сконфигурированного подобным образом сервера VNC состоит в том, что он может принимать обращения нескольких пользователей через один порт. Таким образом, совместное использование серверов VNC и XDMCP можно условно сравнить с применением сервера XDMCP и удаленного X-сервера. Однако эти системы имеют ряд отличий. Наиболее важные из них описаны ниже.

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

• При работе VNC на пользовательском компьютере вместо X-сервера выполняется клиент VNC. Сервер VNC распространяется в исходных кодах, поэтому он свободно доступен, в то время как большинство X-серверов для Windows и MacOS предоставляется на коммерческой основе.

• Протокол VNC имеет свои особенности. Если на пользовательском компьютере вы замените X-сервер клиентом VNC, качество системы может как повыситься, так и снизиться, в зависимости от потребностей пользователя и применяемого X-сервера.

• В большинстве случаев протокол VNC обеспечивает меньшее быстродействие по сравнению с X Window, однако в некоторых случаях применение VNC вместо X Window может повысить производительность системы.

 

Преимущества и недостатки различных технологий удаленной регистрации

В табл. 14.1 приведены наиболее важные характеристики различных технологий удаленной регистрации, рассмотренных в данной главе. Заметьте, что конкретные оценки могут различаться в зависимости от реализации протокола и конфигурации программных средств. Например, уровень безопасности при VNC-регистрации в текстовом режиме зависит от применяемого инструмента. Если вы используете для установления начального соединения SSH, то защита оценивается как отличная, если же кодирование передаваемых данных не осуществляется, информация может быть перехвачена, поэтому защита считается неудовлетворительной.

Таблица 14.1. Xарактеристики средств удаленной регистрации, поддерживающих графический интерфейс

Характеристика Регистрация в текстовом режиме SSH-регистрация XDMCP-регистрация Регистрация в текстовом режиме с использованием VNC Совместное использование VNC и XDMCP
Уровень защиты при регистрации Очень низкий Очень высокий Очень низкий От очень низкого до очень высокого Очень низкий
Уровень защиты при передаче данных Очень низкий Очень высокий Очень низкий Очень низкий Очень низкий
Вероятность возникновения проблем при наличии брандмауэра Высокая Низкая Высокая Низкая Низкая
Способность к сохранению состояния сеанса (разрыв и восстановление соединения) Низкая Низкая Низкая Высокая Низкая
Быстродействие Высокое Среднее Высокое От низкого до среднего От низкого до среднего
Вероятность возникновения проблем при работе приложения От низкой до средней От низкой до средней От низкой до средней Средняя Средняя

Итак, какие же средства удаленной регистрации следует применить, если пользователю должен быть предоставлен графический интерфейс? На этот вопрос нельзя дать однозначный ответ. X Window очень хорошо подходит для обмена данными между компьютерами под управлением Linux или UNIX в локальной сети. В этих операционных системах есть практически все необходимые программные компоненты, X Window обеспечивает высокое быстродействие, и работа с ней не вызывает затруднений. С помощью X Window удобно также запускать программы в системе Linux с компьютеров под управлением Windows и MacOS, но вам придется установить X-серверы на соответствующих машинах, а это может оказаться слишком дорого. Для установки требуются меньшие средства, кроме того, в данной системе используется традиционное расположение клиента и сервера (в отличие от X Window, где X-сервер находится на компьютере, за которым работает пользователь, а X-клиент — на удаленной машине). VNC удобно применять в тех случаях, когда клиент и сервер разделены брандмауэром. Брандмауэр с большей вероятностью будет блокировать обмен данными посредством X Window, когда сервер находится на пользовательском компьютере.

 

Резюме

Серверы удаленной регистрации — чрезвычайно полезные инструменты. В особенности они нужны в тех случаях, когда пользователи имеют учетные записи на нескольких компьютерах, или тогда, когда нужно обеспечить выполнение основных программ на центральной машине и организовать доступ к ним с менее мощных пользовательских компьютеров. Чаще всего на компьютерах под управлением Linux используется система X Window, которая позволяет пользователям регистрироваться на удаленной машине и предоставляет графический интерфейс. Организовать удаленный доступ посредством X Window можно различными способами: инициализировать X-взаимодействие посредством одного из протоколов, обеспечивающих работу в текстовом режиме, либо использовать сервер XDMCP для аутентификации удаленных пользователей. Для организации удаленного доступа можно также применять средства VNC. В этом случае в процесс обмена данными вовлекаются дополнительные компоненты, но с точки зрения пользователя работа с удаленным узлом упрощается.

 

Глава 15

Серверы шрифтов

 

В цивилизованном мире не найдется человека, который никогда не видел букв. Одна и та же буква может выглядеть по-разному. Например, буква "P" в заголовке главы отличается от той же буквы в тексте абзаца. Буква "P", отображаемая курсивом, отличается от их обеих. Рассмотренные здесь варианты буквы "P" принадлежат различным шрифтам. Шрифт определяет внешний вид букв (как в верхнем, так и нижнем регистре), цифр и знаков пунктуации. Существуют шрифты, не содержащие букв; они состоят исключительно из специальных символов. Шрифты — это необходимые компоненты программного обеспечения современных компьютеров. Приступая к работе с текстовым процессором или Web-броузером, пользователь справедливо предполагает, что в его распоряжение предоставлен набор шрифтов и что он в любой момент может выбрать наиболее подходящий шрифт. Иногда, например при решении задач электронной публикации, наличие многих шрифтов является одним из основных требований к системе. В других случаях, например при просмотре электронной почты, возможность выбора шрифта лишь создает пользователю более комфортные условия для работы.

Один из способов управления шрифтами в системе Linux состоит в использовании сервера шрифтов. Этот сервер имеет доступ к набору шрифтов и может доставлять их клиентам, подключенным к сети. На первый взгляд сервер шрифтов может показаться абсолютно бесполезным компонентом, так как на большинстве компьютеров поддерживаются свои наборы шрифтов. Однако в некоторых ситуациях сервер шрифтов существенно упрощает процедуру администрирования сети. Для того чтобы грамотно использовать сервер шрифтов, необходимо хотя бы в общих чертах знать форматы файлов шрифтов и представлять себе преимущества и недостатки этих форматов. Большинство серверов шрифтов, работающих в системе Linux, выполняют ограниченный круг задач, в основном связанных с поддержкой работы системы X Window. Но возможности сервера шрифтов могут быть расширены. Такие серверы чаще всего предназначаются для работы с текстовыми процессорами и другими подобными приложениями.

 

Использование серверов шрифтов

Одним из параметров, задаваемых в конфигурационном файле X Window, является шрифт, или путь к шрифту. В пакете XFree86 для этого используется запись FontPath. Она включается в файл XF86Config, который обычно хранится в каталоге /etc или /etc/X11. Данный параметр указывает X-серверу на расположение информации о шрифтах. В середине 1990-х годов в системе Linux в качестве пути к шрифту задавались каталоги локальной файловой системы. В этих каталогах содержались шрифты и вспомогательные файлы. Такая конфигурация до сих пор поддерживается, а в некоторых дистрибутивных пакетах даже устанавливается по умолчанию.

При работе X-сервера со шрифтами, хранящимися на жестком диске, возникает ряд проблем. Прежде всего, X-сервер должен поддерживать форматы файлов шрифтов, а это требование не всегда выполняется. Например, версии, предшествующие XFree86 4.0, не поддерживали популярный формат TrueType. Реализация средств обработки нового формата шрифтов в XFree86 — чрезвычайно трудная задача, которая, тем не менее, достаточно просто решается сервером шрифтов. Поэтому TrueType стал поддерживаться серверами шрифтов гораздо раньше, чем XFree86. Несмотря на то что задача обработки TrueType в XFree86 уже решена, время от времени возникают проблемы, связанные с появлением новых форматов шрифтов. Так, например, в настоящее время становится все более популярным формат Multiple Master, поддержку которого необходимо обеспечивать.

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

И, наконец, не стоит забывать, что серверы шрифтов обеспечивают возможности, которые не может предоставить X-сервер, который работает со шрифтами, находящимися на диске. Эти возможности бывают необходимы для текстовых процессоров, издательских систем и других подобных программ. X-сервер в основном ориентирован на отображение информации на экране монитора и не удовлетворяет всем требованиям, которые предъявляют к нему специализированные программы, предназначенные для работы с текстом. Сервер шрифтов помогает разрешить эту проблему и обеспечивает работу программ обработки текста, в частности программ WYSIWYG (what-you-see-is-what-you-get).

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

Внимание

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

 

Форматы файлов шрифтов

 

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

 

Форматы растровых шрифтов

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

В качестве примера рассмотрим рис. 15.1, на котором показано представление одного символа растрового шрифта. Даже если не принимать во внимание, какие именно пиксели закрашены черным, а какие белым цветом, данный рисунок иллюстрирует ряд характеристик растрового шрифта. Знакоместо (часть растровой сетки, предназначенная для отображения символа) имеет фиксированные размеры. В пропорциональных шрифтах, которые чаще всего используются в книгопечатании, различные символы могут иметь разную ширину. Соответственно различается ширина знакомест для разных символов одного и того же шрифта. Высота знакоместа фиксирована; фиксирована также высота большинства символов. (Существуют так называемые символы с подстрочными элементами. Подстрочный элемент располагается под нижней границей символа. Примерами подобных символов являются g, j, p, q и у. Заметьте, что на рис. 15.1 символ размещается в пределах знакоместа так, что остается место для подстрочного элемента.) Поскольку высота знакоместа фиксирована, размер шрифта на одном устройстве отображения остается постоянным. При переходе на другое устройство с другой разрешающей способностью размер символов изменится. Чтобы обеспечить отображение символов одинакового размера на различных устройствах или отображение символов разного размера на одном устройстве, необходимо иметь в наличии набор битовых карт.

Рис. 15.1. Битовая карта определяет, какие пиксели в составе знакоместа должны отображаться черным цветом, а какие — белым

Разрешающая способность дисплея обычно выражается в точках на дюйм (dpi — dots per inch), т.е. разрешение — это количество пикселей, помещающихся на отрезке в один дюйм. В большинстве устройств разрешающая способность по горизонтали и по вертикали совпадает, однако в некоторых случаях она может различаться. Мониторы компьютеров обычно имеют разрешение от 72 до 120 dpi, а разрешающая способность принтеров, как правило, лежит в пределах 144-1200 dpi. (Разрешающая способность, равная 144, характерна для матричных принтеров; кроме того, такое разрешение часто устанавливают, чтобы предельно ускорить процесс печати за счет снижения ее качества.) Разрешающая способность высокоуровневых принтеров и специализированных полиграфических устройств, как правило, намного превышает 1200 dpi. Разнообразие устройств печати и необходимость создания отдельного файла для каждого размера шрифта и для каждого значения разрешающей способности приводит к тому, что общее число файлов становится недопустимо большим.

На заметку

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

Размеры шрифтов измеряются в пунктах (эта единица измерения широко применяется в полиграфии). Для отображения текста абзаца обычно используется шрифт размером 9–14 пунктов. Выбор размера зависит от шрифта и назначения текста. Растровые шрифты чаще всего создаются в том случае, когда необходимо отображать символы фиксированных размеров на устройстве с определенной разрешающей способностью, например, если нужен текст размером 12 пунктов на устройстве с разрешением 144 dpi. Один и тот же шрифт позволяет отображать символы разного размера на устройствах с различной разрешающей способностью, однако шрифт, созданный с нуля и ориентированный на устройство с конкретным разрешением будет несколько отличаться от шрифта, перенесенного с другого устройства. При необходимости для отображения символов требуемого размера можно изменить битовые карты символов (например, уменьшить размер символов с 12 до 10 пунктов), однако в результате подобных действий отображается текст плохого качества.

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

Для представления шрифтов используются различные форматы. В ранних версиях X Window применялся формат SNF (Server Normal Format — обычный формат сервера), но сейчас он встречается редко. Как правило, в X Window используются шрифты в формате PCF (Portable Compiled Font — переносимый компилируемый шрифт). Формат BDF (Bitmap Distribution Format — формат распространения битовых карт) также часто применяется в X Window, но чтобы X-программы могли работать с ним, сервер шрифтов преобразует шрифты BDF в формат PCF. В других операционных системах используются другие форматы. Чтобы работать с ними в системе Linux, надо воспользоваться одним из преобразователей шрифтов.

На заметку

XFree86 использует PCF-шрифты, сжатые посредством программы gzip . В большинстве дистрибутивных пакетов для экономии дискового пространства шрифты поставляются в сжатом виде. При этом имена PCF-файлов оканчиваются символами .pcf.gz . Чтобы использовать эти шрифты при работе X-программ, не обязательно распаковывать их.

Шрифты, применяемые в системе Linux, не ограничиваются используемыми в X Window. Некоторые программы работают с собственными наборами шрифтов. Одной из таких программ является система TeX, в которой применяется формат Packed Font (файлы шрифтов имеют расширение .pk). Поскольку система TeX в основном разрабатывалась для подготовки материалов к печати, а представлению текста на экране монитора уделялось не слишком большое внимание, число пикселей, составляющих знакоместа в шрифтах Packed Font, существенно превышает соответствующий показатель других форматов.

 

Форматы контурных шрифтов

Одна из основных проблем, возникающих при работе с растровыми шрифтами, состоит в том, что эти шрифты плохо масштабируются. Если вам необходимо отображать на одном устройстве символы разных размеров либо выводить текст одного и того же размера на устройства с различной разрешающей способностью, вам потребуется несколько файлов шрифтов. Учитывая разнообразие имеющихся в настоящее время устройств отображения и требования к масштабированию символов, предъявляемые современными программами (например, текстовыми процессорами), становится очевидно, что, для того, чтобы отобразить высококачественный текст на разнообразном оборудовании, потребуется чрезвычайно большой набор файлов шрифтов. Решить эту проблему можно, используя контурные, или масштабируемые шрифты. Вместо битовых карт в контурных шрифтах символы представляются в виде описаний кривых, с помощью которых формируются их контуры. Вернемся к рис. 15.1. Если знакоместо 8×8 пикселей увеличить до гораздо больших размеров, например 80000×80000, контуры символа могут быть описаны набором прямых так, как это показано в табл. 15.1.

Таблица 15.1. Контурное описание символа, представленного на рис. 15.1

Операция Координата x Координата у
Установка в начальную позицию 10000 10000
Прямая 10000 60000
Прямая 20000 60000
Прямая 20000 40000
и т.д.

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

На заметку

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

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

Существуют различные форматы представления контурных шрифтов. В качестве примеров можно привести Bitstream Speedo, Adobe Type 1, Type 3, Type 5, Type 42 и Apple TrueType. (Шрифты Type 42 на самом деле представляют собой шрифты TrueType, преобразованные для вывода на PostScript-принтеры.) Различия между разными форматами контурных шрифтов гораздо более существенны, чем в случае растровых шрифтов, так как в них используются различные типы описаний прямых и кривых линий. В большинстве случаев шрифты можно преобразовать из одного формата в другой, но при этом начертания символов будут незначительно отличаться друг от друга. В частности, в процессе преобразования могут быть потеряны рекомендации разработчика, что ухудшит внешний вид символов при выводе на устройства с низким разрешением. Поэтому рекомендуется использовать исходный формат шрифта, а если это невозможно, то следует приобрести у разработчика тот же шрифт, представленный в нужном вам формате.

В Linux (а точнее, в XFree86) реализована поддержка контурных шрифтов Speedo и Adobe Туре 1. Шрифты Speedo используются достаточно редко, а шрифты Туре 1 нашли широкое применение; они распространяются на компакт-дисках и доступны через Internet. Кроме того, некоторые шрифты Туре 1 входят в поставку Linux. В Windows и MacOS шрифты TrueType намного более популярны, чем Туре 1. В частности, TrueType является стандартным форматом шрифтов для системы Windows. Считается, что шрифты TrueType позволяют обеспечить более высокое качество отображения на устройствах с низким разрешением, чем Туре 1, однако такое утверждение справедливо только в тех случаях, когда в состав шрифта включены подробные рекомендации разработчика. При отсутствии рекомендаций разработчика символы TrueType отображаются ничуть не лучше, чем символы Туре 1.

СОВЕТ

Корпорация Microsoft разработала шрифты TrueType, снабженные подробными рекомендациями. Они предназначены для использования в Web-броузерах и доступны по адресу http://www.microsoft.com/typography/fontpack/ . Если вы скопируете файлы, ориентированные на применение в Windows 3.1, то сможете непосредственно использовать их в системе Linux. Эти шрифты поставляются в виде самораспаковывающихся (в системе Windows) zip-файлов; в Linux вы можете извлечь их содержимое с помощью утилиты unzip . Порядок инсталляции шрифтов будет описан далее в этой главе. Разработчики многих Web-узлов предполагают, что шрифты, о которых идет речь, уже установлены на клиентской машине, поэтому, инсталлировав их, вы сможете наиболее корректно отобразить соответствующие Web-страницы.

В версиях XFree86, предшествующих 4.0, шрифты TrueType не поддерживались, поэтому единственным способом работы с ними было применение сервера шрифтов. В настоящее время есть возможность непосредственного использования шрифтов TrueType в X Window, однако в большинстве дистрибутивных пакетов для работы с TrueType традиционно применяется сервер шрифтов.

X Window — не единственная система, в которой используются контурные шрифты. С помощью специальных инструментальных средств можно, например, обеспечить работу TeX с этим типом шрифтов. Программа Ghostscript (PostScript-интерпретатор для принтеров, не поддерживающих PostScript) также использует растровые шрифты: чаще всего Ghostscript работает со шрифтами Туре но в некоторых случаях может применяться и формат TrueType. Растровые шрифты необходимы для обеспечения работы текстовых процессоров. Упомянутые здесь программы, за исключением текстовых процессоров, не используют сервер шрифтов.

 

Обеспечение работы традиционного сервера шрифтов

 

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

 

Программы, реализующие сервер шрифтов в Linux

Чаще всего в качестве сервера шрифтов в Linux используется программа xfs, которая поставляется в составе XFree86. По сути эта программа представляет собой набор кодов X Window, используемых для обработки шрифтов и дополненный средствами поддержки сетевого взаимодействия. Как правило, данный сервер помещается в каталог /usr/X11R6/bin; пакет, используемый для инсталляции, обычно называется XFree86-xfs или xfs.

При работе с версиями XFree86, предшествующими версии 4.0, вам понадобится модифицированный вариант сервера шрифтов, в котором реализована поддержка TrueType. Два сервера, обеспечивающих такую поддержку, описаны ниже.

• xfstt. Данный сервер ориентирован исключительно на работу с TrueType. Type 1, BDF и другие форматы шрифтов не поддерживаются. Этот продукт удобен для обеспечения поддержки TrueType в версиях XFree86, выпущенных раньше, чем XFree86 4.0. Если же вас интересует только работа с форматом TrueType, xfstt можно использовать в качестве сетевого сервера шрифтов. Инсталляционный пакет xfstt находится по адресу ftp://ftp.metalab.unc.edu/pub/Linux/X11/fonts/xfstt-1.1.tar.gz (в последующих версиях данного продукта файл xfstt-1.1.tar.gz может быть переименован). Принимая решение об использовании xfstt, следует помнить, что этот сервер предоставляет клиентам шрифты в формате, который зависит от порядка следования байтов, принятого в компьютере. Если в сети присутствуют компьютеры с различными сочетаниями байтов (например, x86 и PowerPC), xfstt не может выполнять функции сетевого сервера шрифтов.

• xfsft. Данный сервер представляет собой модифицированный вариант стандартного пакета xfs, входящего в состав XFree86 3.3.x. Сервер xfsft включает поддержку TrueType средствами FreeType (http://freetype.sourceforge.net/index2.html). Результатом данной модификации стал сервер, поддерживающий TrueType, Type 1, BDF и другие форматы шрифтов. Все возможности xfsft обеспечивает также стандартная программа xfs, входящая в состав XFree86 4.0; ее вы можете использовать даже при работе с ранними версиями XFree86. Если же вы по каким-либо причинам предпочтете работать с сервером xfsft, вы можете получить его, обратившись по адресу http://www.dcs.ed.ас.uk/home/jее/programs/xfsft/.

Описанные выше пакеты обрабатывают шрифты TrueType по-разному. Используемые в этих серверах алгоритмы обработки в свою очередь отличаются от алгоритмов, реализованных в системах Windows и MacOS. Применение разных принципов обработки приводит к тому, что символы одинакового размера, выведенные на одно и то же устройство с использованием разных серверов шрифтов, будут несколько различаться между собой. И xfstt, и xfsft обеспечивают достаточно хорошее качество воспроизведения символов. Если же при работе с каким-либо шрифтом возникнут проблемы или если внешний вид отображаемых символов не будет удовлетворять вас, вам придется рассмотреть вопрос об использовании другого сервера.

На заметку

В системах Windows и MacOS реализована возможность сглаживания границ символов (anti-aliasing). Чтобы границы символов выглядели более ровно, вместо черного или белого цвета некоторые пиксели закрашиваются оттенками серого цвета. Если пользователю не понравится внешний вид обработанных подобным образом символов, он имеет возможность отключить средства сглаживания. В X Window до появления версии 4.0.2 сглаживание не поддерживалось. Чтобы включить сглаживание, необходимо выполнить дополнительные действия по настройке, которые описаны в документе http://sdb.suse.de/en/sdb/html/chofman_ttf_72.html .

При настройке различных серверов шрифтов, предназначенных для работы в системе Linux, выполняются практически одинаковые действия. Шрифты располагаются в специально предназначенных для них каталогах, и создаются файлы, которые описывают находящиеся в них шрифты. Затем сервер шрифтов конфигурируется для просмотра каталогов и предоставления необходимых шрифтов клиентам. Последующие разделы посвящены настройке xfs и xfsft. Конфигурация xfstt лишь незначительно отличается от этих серверов.

 

Конфигурация серверов шрифтов, установленная по умолчанию

После инсталляции Linux и XFree86 система создает конфигурационный файл XFree86 с именем XF86Config и помещает его в каталог /etc или /etc/X11. Как было сказано ранее, в этом файле содержатся записи Font Path, которые указывают на каталоги в файловой системе компьютера или на серверы шрифтов. Примеры записей в файле XF86Config приведены ниже.

FontPath "/usr/X11R6/lib/fonts/Type1/"

FontPath "unix/:7100"

FontPath "tcp/zapf:7100"

На заметку

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

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

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

Третья строка определяет сервер шрифтов, доступный по сети. Ключевое слово tcp указывает на то, что к серверу можно обращаться с помощью стандартных средств TCP/IP. Имя после косой черты (в данном случае zapf) — это имя компьютера, на котором выполняется сервер шрифтов. (При необходимости вы можете задать полное доменное имя узла, например zapf.threeroomco.com.) Число, следующее за именем, определяет порт, по которому сервер принимает обращения.

Как локальный сервер шрифтов, так и сервер, доступный по сети TCP/IP, традиционно используют для приема обращений от клиентов порт 7100. (Иногда для обработки обращений от локальных программ применяется порт -1). В некоторых случаях данное соглашение приводит к возникновению конфликтов. Это может случиться, если в системе выполняется программа, которая запускает сервер шрифтов с расширенными возможностями. В подобной ситуации вам следует использовать другой порт, например 7101 или 7102.

Порядок выполнения сервера шрифтов определяется содержимым конфигурационного файла. В большинстве случаев роль конфигурационного файла выполняет файл /etc/X11/fs/conf, но в некоторых системах вместо conf используется файл с именем config. В этом файле указывается расположение файлов шрифтов и определяются особенности работы сервера. Для запуска сервера шрифтов обычно применяются сценарии SysV, но если вы включаете сервер в систему, в котором по умолчанию его выполнение не предусмотрено, вы можете воспользоваться локальным сценарием запуска. В некоторых системах, например в Red Hat, сценарий SysV проверяет каталоги со шрифтами и определяет, должен ли быть обновлен список шрифтов. При необходимости список обновляется автоматически. Это существенно упрощает включение новых шрифтов, так как вам достаточно записать новые файлы в соответствующий каталог и перезагрузить сервер шрифтов. Если же утилита, автоматически генерирующая конфигурационный файл, некорректно работает с каким-либо из шрифтов, вы можете запретить автоконфигурацию для одного или нескольких каталогов и создавать конфигурационный файл вручную.

 

Настройка сервера шрифтов для работы в сети

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

• Запустить второй экземпляр сервера шрифтов и обеспечить доступ к нему. Если вы будете использовать данный подход, вам придется модифицировать сценарий запуска или обеспечить выполнение второго сервера другим способом. Чтобы два экземпляра сервера использовали различные конфигурационные файлы, можно при вызове xfs указать опцию -config / путь_к_конфигурационному_файлу .

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

На заметку

Сервер шрифтов можно запустить даже на компьютере, на котором отсутствует система X Window. Чтобы это стало возможным, вам придется установить все программы, которые нужны для работы сервера. Несмотря на то что эти программы составляют основную часть X Window, X-сервер на этом компьютере запускать не обязательно.

Существуют два способа, позволяющие ограничить доступ к серверу шрифтов.

• Запрет установления TCP-соединения. В системе Red Hat 7.2 в файле/etc/X11/fs/config содержится строка no-listen = tcp, которая запрещает серверу принимать запросы на установление TCP-соединения. Если эта строка отсутствует, сервер принимает обращения от клиентов через порт 7100. Таким образом, чтобы обеспечить доступ к серверу, надо закомментировать данную строку, завершить работу сервера и запустить его снова. В системе Red Hat для остановки и запуска сервера может быть использован сценарий SysV с именем xfs.

• Использование порта -1. В системе Mandrake 8.1 сервер шрифтов по умолчанию настраивается для приема обращений через порт с номером -1. Такая настройка запрещает установление сетевых соединений с другими компьютерами. Для того чтобы изменить конфигурацию сервера, надо отредактировать сценарий запуска (обычно он содержится в файле /etc/rc.d/init.d/xfs) и изменить в нем номер порта. Найдите строку, которая начинается с daemon xfs -port -1, и замените число -1 на 7100 или на другой номер порта, который вы собираетесь использовать. Вам также надо отредактировать файл /etc/XF86Config, содержащийся в каталоге /etc/X11 (в зависимости от используемого X-сервера этот файл может также называться XF86Config или XF86Config-4), и указать в нем, что обращение к серверу шрифтов должно осуществляться с использованием другого номера порта. Найдите запись FontPath, ссылающуюся на unix/:-1, и замените -1 на 7100 или другой номер порта, который вы указали в сценарии запуска xfs. После этого вам придется завершить работу xfs и снова запустить его, а также перезапустить X-сервер (для этого можно использовать кнопку Restart X Server в окне регистрации Mandrake).

Внимание

Изменение конфигурации работающего сервера шрифтов представляет собой достаточно сложную задачу. Если сервер станет недоступным, прикладные программы, использующие шрифты, могут зависнуть. Поэтому лучше всего переконфигурировать сервер шрифтов, зарегистрировавшись в текстовом режиме. Если передать сценарию SysV, используемому для запуска в системах Red Hat и Mandrake, опцию restart , изменения конфигурации не будут учтены. Поэтому вам необходимо остановить работу сервера, указав опцию stop , а затем снова запустить его с помощью опции start .

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

Внимание

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

Используя сервер шрифтов, нельзя упускать из виду вопросы защиты. Если сервер шрифтов работает в локальной сети, не подключенной к Internet, о безопасности системы можно не слишком беспокоиться, особенно если вы полностью контролируете все компьютеры в сети. Если же компьютер, на котором выполняется данный сервер, доступен из Internet, нельзя полностью исключать возможность незаконного проникновения в систему посредством сервера шрифтов. Сервер шрифтов — не очень сложная программа, и при обращении к нему пароль не указывается. Как и в любом сервере, в сервере шрифтов могут быть обнаружены ошибки, допускающие возможность взлома системы. Поэтому сеть, в которой работает сервер шрифтов, рекомендуется изолировать от остальной части Internet с помощью выделенного брандмауэра. Брандмауэр следует настроить так, чтобы через порт, используемый сервером, могли обращаться только локальные машины. Вопросы конфигурирования iptables будут рассматриваться в главе 25.

 

Обеспечение доступа к шрифтам

Серверы шрифтов в основном предназначены для того, чтобы системный администратор мог, не затрачивая больших усилий, обеспечить доступ к шрифтам узлов сети, состоящей из компьютеров под управлением Linux и UNIX. (X-серверы в Windows, MacOS и других системах также иногда используют удаленные серверы шрифтов.) Для того чтобы обеспечить работу программ с использованием сервера шрифтов, необходимо выполнить два основных действия: задать пути к шрифтам для сервера шрифтов (эти пути отличаются от путей к шрифтам, задаваемых для X-сервера) и включить шрифты в соответствующие каталоги.

Указание путей к шрифтам

Пути к шрифтам задаются в конфигурационном файле сервера шрифтов (обычно это файл /etc/X11/fs/config или /etc/X11/fs/conf). Вместо ключевого слова FontPath, присутствующего в файле XF86Config, для указания шрифтов в файле config или conf используется ключевое слово catalogue. Пример записи, с помощью которой задаются пути к шрифтам, приведен ниже.

catalogue = /usr/X11R6/lib/X11/fonts/75dpi:unscaled,

 /usr/X11R6/lib/X11/fonts/Type1,

 /usr/X11R6/lib/X11/fonts/TrueType,

 /usr/X11R6/lib/X11/fonts/75dpi

Запись catalogue может занимать несколько строк. Каталоги в списке разделяются запятыми. После последнего каталога запятая не указывается, что является признаком окончания списка. Если имя каталога сопровождается выражением :unscaled, это означает, что растровые шрифты, находящиеся в этом каталоге, могут использоваться только в том случае, если их размеры совпадают с требуемыми размерами шрифтов. При отсутствии ключевого слова unscaled обработка растровых шрифтов производится следующим образом: если имя шрифта совпадает с именем, указанным в запросе, а файл, содержащий битовые карты нужного размера, отсутствует, шрифт приводится к требуемому размеру путем масштабирования (при этом качество шрифта обычно получается невысоким). Подобные соглашения действуют также при описании путей к шрифтам в файле XF86Config. В приведенном выше примере сервер шрифтов использует растровый шрифт из каталога 75dpi только в том случае, если его размер строго соответствует размеру, указанному в запросе. Если найти битовые карты подходящего размера не удается, система продолжает поиск шрифта в каталогах Type1 и TrueType, а затем возвращается к каталогу 75dpi и масштабирует один из находящихся там растровых шрифтов.

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

Включение шрифтов в каталог

Настройка сервера шрифтов предполагает создание файлов описания каталогов. Файл описания каталогов имеет имя fonts.dir, а его содержимое представляется в следующем формате:

число

имя_файла_шрифта1 XLFD1

имя_файла_шрифта2 XLFD1

...

Первая строка содержит число, которое указывает, сколько шрифтов описано в данном файле. Каждая последующая строка описывает один шрифт. Все строки, кроме первой, начинаются с имени шрифта (например, goodfont.ttf или t1f32.pfb). Файл шрифта с указанным именем должен присутствовать в каталоге.

Каждый шрифт Туре 1 реализуется в виде нескольких файлов. Файл PFB (Printer Font Binary — двоичный шрифт печати) содержит основную информацию о шрифте; имя этого файла обычно указывается в fonts.dir. Вместо PFB-файла вы можете задать в составе fonts.dir файл PFA (Printer Font ASCII — ASCII шрифт печати), в котором находятся те же данные, представленные в другом формате. Прочие файлы, определяющие шрифт, имеют расширения pfm, .afb и .afm. Эти файлы необходимы для того, чтобы сервер шрифтов мог предоставлять клиентам шрифты Туре 1.

Остальная часть строки представляет собой логический дескриптор шрифта (XLFD — X Logical Font Descriptor). Ниже приведен пример подобного дескриптора.

-bitstream-charter-medium-r-normal--0-0-0-0-p-0-iso8859-1

Логический дескриптор шрифта состоит из нескольких полей, разделенных дефисами (-). В полях дескриптора содержатся информация об изготовителе шрифта (bitstream); название семейства шрифтов (charter); "вес" шрифта (medium); сведения о том, представлены ли символы шрифта курсивом (r); ширина символов (normal); дополнительное имя стиля (в данном примере не используется); обобщенные данные о размере (строка, состоящая из нулевых значений, означает, что шрифт допускает масштабирование); сведения о том, является ли шрифт моноширинным или пропорциональным (p); средняя ширина (0 для масштабируемого шрифта) и кодировка (iso8859-1).

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

На заметку

Для поддержки семейства шрифтов серверу требуется несколько файлов. Предположим, что в текстовом процессоре используется шрифт Times и возникает необходимость выделять фрагменты текста полужирным шрифтом или курсивом. Разновидности шрифта Times по сути являются отдельными шрифтами, для их представления используются отдельные файлы шрифтов, а в файле fonts.dir создаются XLFD. Многие текстовые процессоры и подобные им программы могут имитировать курсив и полужирный текст, но гораздо лучшие результаты получаются при использовании специальных шрифтов, в особенности это относится к символам, представленным курсивом.

Утилита, позволяющая создавать файл fonts.dir на основании файлов шрифтов Туре 1, содержащихся в каталоге, называется type1inst. Эта утилита поставляется в составе многих дистрибутивных пакетов Linux, но по умолчанию она не инсталлируется. После установки данной программы надо сделать текущим каталог со шрифтами Туре 1 и ввести следующую команду:

# type1inst

Программа type1inst просматривает файлы шрифтов, извлекает имена шрифтов и другую XLFD-информацию и на основании полученных данных создает файл fonts.dir. Данная программа также оповещает пользователя о ходе обработки шрифтов, например, она может сообщить, что на данный момент создана 21 запись в файле fonts.dir, одна из них описывает шрифт, изготовителя которого не удалось определить. Файл fonts.dir, созданный программой type1inst, можно отредактировать вручную и удалить несоответствия, например, выявить файлы шрифтов, принадлежащие одному семейству, но созданные различными производителями. X-программы используют информацию, содержащуюся в файле fonts.dir, и игнорируют данные в составе шрифтов. Поэтому изменение некоторых деталей файлов шрифтов не влияет на работу этих программ. Несоответствия, о которых шла речь выше, могут привести к возникновению проблем, в частности, если информация о производителе не совпадает, то, запросив шрифт, клиент может получить ту или иную его разновидность.

Программа аналогичного назначения создана и для работы с шрифтами TrueType. Эта программа называется ttmkfdir и входит в состав библиотеки FreeType, используемой xfsft и XFree86 4.0. Программа ttmkfdir работает подобно программе type1inst, но позволяет задавать имя выходного файла посредством опции -о. Данная программа не включает в выходной файл сведения о шрифтах, в которых отсутствуют некоторые символы. Для того чтобы сведения об этих шрифтах были включены в выходной файл, необходимо задать опцию -с. Чтобы учесть изменения, внесенные в каталог со шрифтами, надо задать следующую команду:

# ttmkfdir -с -о fonts.dir

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

Внимание

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

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

# xset fp rehash

Если вы не сделаете этого, новые шрифты будут не доступны X-серверам. Если вы удалили шрифты и не оповестили об этом X-сервер, то при попытке получить отсутствующий шрифт, работа X-сервера будет приостановлена.

 

Сервер шрифтов с расширенными возможностями

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

Среди серверов шрифтов с расширенными возможностями, предназначенных для использования в системе Linux, наибольшей популярностью пользуется FontTastic (http://www.bitstream.com/categories/developer/fonttastic/). Этот сервер распространяется на коммерческой основе, функционирует как сервер шрифтов X Window и предоставляет дополнительные возможности клиентам, ориентированным на взаимодействие с ним. FontTastic снабжает клиента дополнительной информацией, например, может при необходимости предоставить ему шрифты в контурном виде, необработанные данные шрифтов и сведения о кернинге. Эту информацию нельзя получить ни с помощью традиционного сервера шрифтов, ни в результате непосредственной обработки шрифтов X-сервером. Получив подобную информацию, приложение может осуществлять действия, которые невозможно выполнить из-за ограничений, накладываемых традиционными средствами обработки шрифтов X Window. Рассмотрим, например, работу текстового процессора. В обычных условиях пользователь указывает стандартный шрифт для документа. Когда приходит время вывести сформированный документ на печать, текстовый процессор обязан скопировать нужный шрифт на принтер либо каким-то образом сообщить принтеру о том, что тот должен использовать один из встроенных шрифтов. Если пользователь выбрал нестандартный шрифт, текстовый процессор может передать принтеру только битовые карты символов, так как именно в таком виде он сам получает эту информацию. Текстовый процессор должен каким-либо способом узнать разрешающую способность принтера, запросить символы с соответствующим разрешением у сервера шрифтов и вывести требуемые данные. При этом качество часто бывает невысоким.

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

Поскольку FontTastic распространяется на коммерческой основе, этот сервер не стал стандартным инструментом для Linux. Однако на работу с ним ориентированы по крайней мере два широко используемых приложения: Corel WordPerfect Office 2000 (которое в в настоящее время уже не поддерживается разработчиком) и VistaSource ApplixWare Office (http://www.vistasource.com/products/axware/). Если вы запустите любую из этих программ, произойдет автоматическая инсталляция FontTastic и данный сервер будет выполняться в течение времени работы приложения. При необходимости FontTastic можно сконфигурировать так, что программы на других компьютерах смогут работать с ним как с обычным сервером шрифтов.

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

Для того чтобы обеспечить согласование шрифтов на экране и на принтере, некоторые программы отказываются от взаимодействия со средствами поддержки шрифтов X Window. В качестве примера такой программы можно привести WordPerfect 8. Данный продукт непосредственно работает со шрифтами. Он самостоятельно растрирует контурные шрифты, отображает их на экране, а также создает битовые карты символов для вывода на принтер.

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

 

Резюме

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

 

Глава 16

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

 

Средства удаленной регистрации, которые рассматривались в главах 13 и 14, позволяют пользователям запускать программы с удаленного компьютера. Эти инструменты можно использовать для регистрации в системе и управления ею. Существуют также специализированные инструменты, предназначенные для решения задач удаленного администрирования. Некоторые из них предоставляют дружественный интерфейс, упрощая тем самым работу начинающих администраторов. Даже если интерфейс сложен для восприятия, работать с этими инструментами все же проще, чем вручную редактировать конфигурационные файлы. Справочная информация, предоставляемая инструментами удаленного администрирования, помогает в работе даже опытным специалистам. В данной главе рассматриваются два универсальных инструмента (Linuxconf и Webmin), а также утилита, ориентированная на работу с единственным сервером (Samba Web Administration Tool, или SWAT). Кроме того, в конце главы обсуждаются вопросы безопасности при использовании инструментов удаленного администрирования.

 

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

В некоторых случаях возникает необходимость выполнять администрирование системы с удаленного компьютера. Справиться с этой задачей помогают специализированные инструменты. Эти средства можно использовать и локально. Все программы удаленного администрирования предоставляют Web-интерфейс, с помощью которого можно работать, используя в качестве клиентской программы обычный Web-броузер. Linuxconf, помимо Web-интерфейса, поддерживает также альтернативные средства взаимодействия с пользователем. Учитывая, что для удаленного администрирования подходит любой из серверов удаленной регистрации, рассмотренных в главах 13 и 14, становится ясно, что основное преимущество специализированных инструментов удаленного администрирования — это интерфейс, упрощающий работу администратора.

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

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

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

 

Использование средств удаленного администрирования для настройки различных версий Linux

Все инструментальные средства, рассматриваемые в этой главе, могут работать с различными версиями Linux. Основная трудность, возникающая при этом, состоит в том, что в программе администрирования должны быть учтены характерные особенности каждой версии системы. Так, например, в разных дистрибутивных пакетах запуск одного и того же сервера осуществляется различными способами, в качестве суперсервера в одних версиях Linux используется inetd, а в других — xinetd, нумерация сценариев запуска SysV различается в зависимости от версии операционной системы и т.д. Для инструмента, ориентированного на работу с конкретной реализацией Linux (например, для YaST, используемого в SuSE), эти различия не имеют значения, а для универсальных инструментов, таких как Linuxconf и Webmin, они чрезвычайно важны.

Для обеспечения работы Linuxconf и Webmin с разными версиями Linux используются конфигурационные модули. Каждый из этих инструментов сам по себе является не более чем базовой программой, которая осуществляет взаимодействие с клиентом и позволяет пользователям выбирать опции, вводить строки символов и выполнять другие подобные действия. Для выполнения конкретных действий с конфигурационными файлами используются модули, в которых содержится подробная информация о системе: расположение файлов, сведения об их структуре и другие данные, имеющие отношение к настройке системы. Существуют модули, предназначенные для установки общей конфигурации системы (например, для конфигурирования сценариев запуска SysV и формирования файла /etc/inittab) и для настройки конкретных серверов (например, Apache, sendmail и Samba). Если в состав системы входит инструмент Linuxconf или Webmin, дистрибутивный пакет содержит модули для серверов, поставляемых вместе с системой. При установке нового сервера необходимые модули чаще всего поставляются в инсталляционном пакете. Если вы копируете программу удаленного администрирования с Web-узла, вы найдете на том же узле набор модулей для вашей версии системы.

Конфигурационные модули обеспечивают большую гибкость таких программ, как Linuxconf и Webmin, но они же могут стать источником проблем. Если модули не отражают изменения, внесенные в систему, инструмент администрирования будет работать ненадежно. Не исключено, что конфигурационные файлы не станут обновляться или при их обновлении появятся ошибки. Использование устаревших модулей может даже привести к тому, что сама программа администрирования не будет выполняться. Эти проблемы особенно заметны при работе с Linuxconf в системе Red Hat. Чтобы исключить их, в состав Red Hat начиная с версии 7.1 включается соответствующим образом настроенная программа Linuxconf.

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

 

Выполнение Linuxconf на удаленном компьютере

 

Традиционно программа Linuxconf поставляется с Red Hat и Mandrake, однако она разрабатывалась не только для них. Данный инструмент может также использоваться в других системах, например в Caldera, Debian, Slackware и SuSE. Обратившись по адресу http://www.solucorp.qc.ca/linuxconf/, вы можете скопировать архив, содержащий код Linuxconf.

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

 

Настройка Linuxconf для выполнения на удаленном компьютере

По умолчанию Linuxconf настраивается для работы в текстовом и в одном из двух графических режимов (в большинстве дистрибутивных пакетов поддерживается GNOME-Linuxconf, но Solucorp использует другой режим). Разрабатывается также Java-интерфейс. Поскольку поддержка Web-интерфейса по умолчанию запрещена, вам надо разрешить ее самостоятельно. Для этого необходимо обеспечить выполнение Linuxconf в режиме сервера и сконфигурировать его для приема обращений по сети.

Запуск сервера Linuxconf

Для запуска Linuxconf в режиме сервера чаще всего используется суперсервер. В зависимости от версии Linux это может быть inetd или xinetd. Как вы уже знаете, для запуска программы посредством суперсервера необходимо включить в файл /etc/services описание порта. Для Linuxconf такое описание имеет следующий вид:

linuxconf 98/tcp

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

linuxconf stream tcp wait root /bin/linuxconf linuxconf --http

Если в вашей системе используется xinetd и Linuxconf входит в комплект поставки, в каталоге /etc/xinetd.d скорее всего содержится файл linuxconf-web или linuxconf, предназначенный для запуска данного сервера. Чтобы удаленный доступ к Linuxconf был возможен, следует убедиться, что в этот файл не включена строка disable = yes, если же она присутствует в файле, вам надо заменить значение yes на no.

Авторизация удаленного доступа

Сконфигурировав суперсервер для запуска Linuxconf, вы можете обращаться к данной программе, выполняющейся в режиме сервера, с помощью Web-броузера. Для этого надо ввести имя узла и указать порт 98. Например, для того, чтобы начать администрирование компьютера remote.threeroomco.com, вы должны указать URL http://remote.threeroomco.com:98. Web-броузер может выполняться на любой платформе, поэтому выполнять администрирование системы Linux можно, работая на компьютере под управлением Linux, UNIX, Windows, MacOS или любой другой системы.

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

1. Запустите программу linuxconf от имени пользователя root. Для этого введите команду linuxconf. Если вы работаете в текстовом режиме или если средства поддержки графического интерфейса Linuxconf отсутствуют, на экране отобразится текстовое меню. Если же вы работаете в системе X Window и в ней поддерживается графический интерфейс Linuxconf, вы увидите окно Linuxconf. Окно Linuxconf, отображаемое в системе Mandrake, показано на рис. 16.1. В других версиях Linux это окно может выглядеть несколько по-другому, но оно позволяет выполнить те же действия.

Рис. 16.1. Окно Linuxconf может выглядеть по-разному, но оно предоставляет один и тот же набор возможностей

2. Выберите пункт меню Config→Networking→Misc→Linuxconf Network Access Options. В результате вам станут доступны опции, показанные в окне на рис. 16.2, но поля будут пустыми. (Разные системы отображают данную информацию различными способами.)

Рис. 16.2. В этом окне можно разрешить доступ к Linuxconf по сети и указать, какие системы могут обращаться к серверу

3. Установите флажок опции Enable Network Access. В результате Linuxconf станет обрабатывать обращения по сети.

4. В первом поле network or host введите адрес 127.0.0.1, а в первом поле netmask(opt) — значение маски 255.255.255.255. Этим вы укажете Linuxconf на необходимость обрабатывать обращения с локального компьютера.

5. Во втором поле network or host введите адрес компьютера, с которого вы собираетесь выполнять администрирование Linux. В следующем за ним поле netmask(opt) задайте маску подсети. Например, значение, показанное на рис. 16.2, сообщает о том, что администрирование системы может осуществляться с любого компьютера, принадлежащего сети 192.168.1.0/24.

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

7. Переходя от окна к окну и активизируя кнопки Accept, Dismiss и Quit, сохраните внесенные изменения и завершите работу с Linuxconf. Возможно, вы получите сообщение о том, что система не синхронизирована с текущей конфигурацией. Чтобы изменения были учтены, щелкните на Do It.

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

 

Обращение к Linuxconf с помощью Web-броузера

Чтобы воспользоваться Web-интерфейсом, предоставляемым Linuxconf, вам надо задать в поле, предназначенном для ввода URL, значение http:// имя_узла :98 . Вместо имени узла можно указать его IP-адрес. В ответ вы получите описание Linuxconf. На этой же странице присутствует кнопка Enter, после щелчка на которой появится диалоговое окно, предназначенное для ввода пользовательского имени и пароля. Вам необходимо зарегистрироваться как root или указать имя другого пользователя, обладающего полномочиями на выполнение действий по администрированию Linux. Основное меню Linuxconf показано на рис. 16.3.

Рис. 16.3. Главное меню Linuxconf, отображаемое средствами Web, содержит тот же набор пунктов, что и меню, которое выводится при работе на локальном компьютере

Пункты меню, показанного на рис. 16.3, активизируются так же, как и обычные гипертекстовые ссылки, расположенные на любой Web-странице. После первых одного-двух щелчка отобразятся новые меню, но в конце концов вы увидите страницу, позволяющую вводить текст в полях редактирования, устанавливать и сбрасывать флажки опций и выполнять другие подобные действия. Например, если в окне, показанном на рис. 16.3, вы щелкнете на Networking в области Config, а на странице, которая отобразится после этого щелчка, вы активизируете ссылку Linuxconf Network Access в области Misc, то увидите Web-страницу, изображенную на рис. 16.4. На этой странице можно выполнять такие же действия, как и диалоговом окне, изображенном на рис. 16.2. Вы можете запретить доступ по сети или изменить набор компьютеров, которые имеют право обращаться к Linuxconf.

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

Web-интерфейс Linuxconf отличается от графического интерфейса, рассмотренного выше, тем, что, при работе с Web-броузером от вас требуется меньше действий для подтверждения внесенных изменений. После щелчка на кнопке Accept (эта кнопка не показана на рис. 16.4, но вы увидите ее, если воспользуетесь полосой прокрутки) сделанные вами установки будут приняты программой. Чтобы сделать то же самое, работая с графическим интерфейсом Linuxconf, надо щелкнуть на нескольких кнопках, расположенных в различных окнах.

Внимание

Закончив установку параметров посредством Web-страницы, предоставляемой сервером Linuxconf, необходимо щелкнуть на кнопке Accept , в противном случае внесенные изменения не будут учтены. Если вы хотите, чтобы сервер Linuxconf проигнорировал выполненные вами действия, завершите работу с Web-страницей щелчком на кнопке Back .

Как видно на рис. 16.1 и 16.3, модули Linuxconf организованы в виде иерархической структуры. Самый простой способ ознакомиться с набором возможностей Linuxconf — просмотреть Web-страницы, отображающиеся при активизации гипертекстовых ссылок. Если вы не хотите изменить конфигурацию системы, не активизируйте кнопку Accept, а заканчивайте работу с очередной страницей щелчком на кнопке Back. He исключено, что некоторые модули будут расположены не там, где вы ожидаете их увидеть. Возможно, вам не удастся установить с помощью Linuxconf все необходимые конфигурационные параметры. Это может произойти из-за отсутствия требуемого модуля либо потому, что в Linuxconf не учтены некоторые особенности вашей системы. Например, если Linuxconf ожидает, что конфигурационный файл находится в каталоге /etc, а на самом деле этот файл расположен в /usr/local/etc, действия по настройке не будут выполнены. Источником проблем при работе с Linuxconf может стать несоответствие версий системы. Возможно, что Linuxconf не сможет интерпретировать некоторые новые опции либо предпримет попытку установить параметры, которые уже не поддерживаются в системе.

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

 

Удаленное администрирование с помощью Webmin

 

Инструмент Webmin (http://www.webmin.com/webmin/) позволяет решить те же задачи, что и Linuxconf. Он упрощает действия администратора по конфигурированию системы и предназначен для настройки различных версий Linux. Webmin обеспечивает работу не только с системой Linux, но и с некоторыми версиями UNIX (например, Solaris и FreeBSD), а также с MacOS. (Полный список поддерживаемых систем находится по адресу http://www.webmin.com/webmin/support.html). Настройка системы с помощью Webmin во многом напоминает работу с Linuxconf. Поскольку Webmin изначально создавался как сетевой инструмент, конфигурирование этой программы для обработки обращений с удаленного компьютера осуществляется несколько проще по сравнению с Linuxconf.

 

Настройка Webmin

Из всех версий Linux, которые обсуждались в данной книге, только Mandrake поставляется с Webmin (планируется включение данного инструмента в комплект Debian 3.0). При работе с другими версиями системы вам придется скопировать Webmin с Web-узла. Пакет Webmin доступен как в формате RPM, так и в виде tar-архива. Для установки Webmin с помощью RPM приходится затрачивать меньше усилий, так как при этом автоматически выполняется сценарий, который определяет версию системы и автоматически настраивает сервер. Если вы используете tar-архив, вам потребуется вручную запустить содержащийся в нем сценарий и ответить на ряд вопросов по системе. Процедура установки Webmin с помощью tar-архива описана ниже.

1. Зарегистрировавшись в системе как root, сделайте текущим каталог, в котором должен находиться подкаталог Webmin. В документации на данный продукт рекомендуется устанавливать его в каталоге /usr/local, но при желании вы можете разместить его в другой позиции файловой системы, например в каталоге /opt.

2. Распакуйте архив Webmin, вызвав для этого команду tar xvfz / путь /webmin- версия .tar.gz . В результате выполнения этой команды будет создан подкаталог webmin- версия , в котором разместятся файлы Webmin.

3. Перейдите в созданный каталог Webmin по команде cd webmin- версия .

4. Запустите сценарий инсталляции по команде ./install.sh. Этот сценарий задаст вам ряд вопросов о системе, например, вам придется сообщить путь к интерпретатору Perl. Очень важно правильно ответить на вопрос о версии системы. Необходимо также указать имя пользователя, имеющего право выполнять администрирование системы, и пароль (эти сведения будут впоследствии использоваться при обращении к серверу Webmin). По окончании выполнения сценарий запустит Webmin, и вы сразу же сможете приступить к работе с данным инструментом.

На заметку

Инструмент Webmin написан на Perl, поэтому компилировать программу не приходится. Один и тот же пакет можно использовать в различных системах, независимо от архитектуры процессора. Чтобы программа Webmin работала, в системе должен присутствовать интерпретатор Perl, однако это требование по умолчанию выполняется во всех версиях Linux.

Конфигурация самой программы Webmin определяется содержимым файлов, находящихся в каталоге /etc/webmin (если вы используете для инсталляции Webmin tar-архив, то можете указать другое расположение конфигурационных файлов). Вероятнее всего, вам не понадобится модифицировать эти файлы, но если вы захотите изменить конфигурацию программы, вам скорее всего придется отредактировать файлы config и miniserv.conf. В этих файлах находятся такие сведения, как номер порта, через который Webmin принимает обращения, и тип системы. Кроме того, в файле miniserv.users содержатся также пользовательское имя администратора и пароль. (Если вы инсталлируете Webmin с помощью RPM, программа использует в качестве имени администратора root и читает пароль из файла /etc/passwd или /etc/shadow. Если установка Webmin производится посредством tar-архива, имя пользователя и пароль надо ввести вручную.) В подкаталогах каталога /etc/webmin содержится информация о серверах и подсистемах, поддерживаемых Webmin.

В большинстве случаев запуск сервера Webmin осуществляется посредством сценария SysV. Этот сценарий, в свою очередь, использует для запуска Perl-кода Webmin сценарий /etc/webmin/start.

 

Использование Webmin

Для того чтобы обратиться к Webmin, надо выполнить те же действия, что и при обращении к Linuxconf. Если вы зададите URL Web-сервера (указав при этом номер порта 10000), вам будет предложено ввести имя пользователя и пароль, после чего в окне Web-броузера отобразится Web-страница, показанная на рис. 16.5. Подобно Linuxconf, компоненты Webmin организованы в виде иерархии категорий, но глубина вложенности подкатегорий меньше, чем в Linuxconf. Большинство средств, которые могут потребоваться вам при работе, расположены на вкладках System и Servers. Вкладка Webmin используется для настройки самой программы Webmin. Вкладка Hardware предназначена для согласования конфигурации программы с конфигурацией аппаратных средств (например, для указания информации о разделах), а на вкладке Others расположены элементы различного назначения.

Рис. 16.5. Основная страница Webmin позволяет выбрать общую категорию, а в ней указать подсистему для настройки

После щелчка на пиктограмме, соответствующей серверу или подсистеме, Webmin предоставит Web-страницу, содержащую список компонентов, либо страницу, позволяющую непосредственно выполнять действия по настройке. Например, страница, соответствующая серверу DNS, содержит ссылки, указывающие на Web-страницы, которые можно использовать для протоколирования, управления файлами и выполнения других действий. Кроме того, как видно на рис. 16.6, для каждой зоны, обслуживаемой сервером DNS, создается отдельная ссылка. Переходя по ссылкам, вы получите страницу, содержащую поля редактирования, флажки опций, списки и другие элементы. Пример такой страницы приведен на рис. 16.7. Выполнив необходимые действия по настройке, щелкните на кнопке Save, чтобы сохранить внесенные изменения. Многие конфигурационные модули предоставляют кнопку Apply Changes, при активизации которой сервер учитывает изменения конфигурации. Другие модули, в зависимости от того, выполняется ли связанный с ними сервер, отображают на странице кнопку Stop или Start. Чтобы ваши установки были приняты, вам надо щелкнуть на кнопке Stop, а затем на кнопке Start.

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

Рис. 16.7. Webmin предоставляет приблизительно такие же средства настройки, как и Linuxconf

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

Обычно с Webmin поставляется более полный набор модулей, чем с Linuxconf. В некоторых дистрибутивных пакетах Webmin работает лучше Linuxconf, в других Linuxconf предпочтительнее. Желательно опробовать оба инструмента и выбрать тот из них, который больше подходит для вашей системы.

Окончив работу с Webmin, щелкните на ссылке Logout, расположенной на основной странице (рис. 16.5). В результате сеанс работы с Webmin будет завершен, и вам не придется закрывать Web-броузер, как это рекомендуется делать при использовании Linuxconf.

 

Настройка сервера Samba с помощью SWAT

 

SWAT (Samba Web Administration Tool), в отличие от Linuxconf и Webmin, является специализированным инструментом. Как следует из названия, SWAT предназначен для администрирования лишь сервера Samba. В результате многие проблемы, связанные с инсталляцией и настройкой для работы с конкретной версией операционной системы, типичные для продуктов Webmin и Linuxconf, не возникают, а сама программа SWAT достаточно полно охватывает набор конфигурационных параметров Samba. SWAT удобно использовать для администрирования выделенных серверов Samba, в особенности этот продукт полезен тем администраторам, которые не имеют достаточного опыта работы и чувствуют себя неуверенно, редактируя текстовые конфигурационные файлы. SWAT иногда применяют в работе даже квалифицированные администраторы, так как этот инструмент избавляет их от необходимости помнить синтаксис записей в составе конфигурационных файлов. Активизируя ссылки Help, расположенные на Web-странице рядом с интерфейсными элементами, предназначенными для редактирования параметров, вы получите данные из справочной системы, которые описывают соответствующие записи в файле smb.conf. Недостатком SWAT является тот факт, что этот продукт удаляет комментарии из файла smb.conf и не поддерживает параметр include, включающий дополнительные конфигурационные файлы. Поэтому, когда необходимо устанавливать сложную конфигурацию Samba, опытные администраторы предпочитают обходиться без помощи SWAT.

 

Запуск SWAT

Функции сервера SWAT реализованы в программе swat. Для ее запуска может быть использован любой из способов, описанных в главе 4, но чаще всего swat запускается посредством суперсервера. Соответствующая запись в файле /etc/inetd.conf имеет следующий вид:

swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat

Если в операционной системе используется суперсервер xinetd, для SWAT создается файл /etc/xinetd.d/swat. Чтобы обеспечить работу SWAT, необходимо убедиться в том, что в данном файле отсутствует запись disable = yes. Если такая строка содержится в файле, ее надо удалить либо заменить значение yes на no. Независимо от того, используется ли в системе inetd или xinetd, для того, чтобы SWAT стал доступен, вам надо перезапустить суперсервер.

На заметку

Иногда SWAT включается в состав пакетов Samba ( samba , samba-common , samba-server и т.д.), в других случаях поставляется в отдельном пакете (обычно он называется swat либо samba-swat ). В системах Mandrake, Slackware, SuSE и TurboLinux SWAT интегрируется в состав Samba, а в системах Caldera, Debian и Red Hat SWAT применяется как независимый пакет.

По умолчанию SWAT использует порт 901. При работе как с inetd, так и с xinetd в файле /etc/services должна присутствовать следующая запись:

swat 901/tcp

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

 

Использование SWAT

После установки SWAT в систему обращаться к этому серверу следует так же, как и серверам Webmin и Linuxconf, но в составе надо указывать порт 901. Например, чтобы использовать SWAT для администрирования сервера Samba, расположенного на узле сети samba.threeroomco.com, вам надо задать в поле ввода URL броузера строку http://samba.threeroomco.com:901. Как и при работе с другими серверами, вы можете использовать Web-броузер, выполняющийся на любой платформе.

На заметку

Samba обрабатывает запросы с указанием имен NetBIOS, поэтому SMB/CIFS-клиенты могут пользоваться соответствующим механизмом преобразования имен. SWAT не содержит модуля подобного назначения, но если клиентские компьютеры поддерживают имена NetBIOS, сервер SWAT будет доступен не только по доменному имени, но и по имени NetBIOS. Для этого сервер Samba должен выполняться в системе. Как правило, клиенты Windows настроены для поддержки имен NetBIOS, а клиенты, работающие в системе Linux, могут использовать только доменные имена.

Подобно другим серверам удаленного администрирования, рассматриваемым в данной главе, при первом обращении к серверу SWAT он запросит пользовательское имя и пароль. Для того чтобы получить максимальные привилегии, надо указать имя root. (Работая с инструментом SWAT, необходимо указывать пароль, используемый в системе Linux, а не пароль, применяемый для регистрации на сервере Samba.) Если вы зарегистрируетесь как обычный пользователь, SWAT позволит лишь просматривать содержимое конфигурационного файла и вносить те изменения, которые разрешены для этого пользователя. Так, например, каждый пользователь имеет право изменять свой пароль. Независимо от того, зарегистрировались ли вы под именем root или как обычный пользователь, SWAT вернет броузеру исходную страницу, показанную на рис. 16.8. После щелчка на пиктограмме или пояснительном тексте к ней вы можете вызвать другие страницы: Globals, Shares, Printers, Status, View и Password. Первые три из них предназначены соответственно для редактирования глобальных опций в файле smb.conf и определения разделяемых объектов, описывающих каталоги и принтеры. Страница Status предоставляет информацию об использовании разделяемых объектов. Страница View отображает содержимое файла smb.conf, а страница Password позволят изменять пароль. Если вы укажете имя, отличное от root, страницы Globals, Shares и Printers будут недоступны, а на страницах Status и Password будет представлен ограниченный набор опций. Помимо ссылок на описанные выше страницы, исходная Web-страница содержит ссылки на документацию по Samba.

Рис. 16.8. Исходная страница SWAT позволяет выбрать категорию для настройки, а также содержит ссылки на документы, описывающие Samba

Основные действия по настройке Samba выполняются с помощью страниц Globals, Shares и Printers. Страница Globals, показанная на рис. 16.9, позволяет задавать опции в разделе [globals] файла smb.conf. С ее помощью можно указать имя NetBIOS, имя рабочей группы, кодирование пароля и другие опции.

Рис. 16.9. Глобальные опции воздействуют на разделяемые объекты файлов и принтеров и определяют особенности выполнения основных операций Samba

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

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

• Для того чтобы удалить существующий разделяемый объект, выберите его имя, как описано выше, и щелкните на кнопке Delete Share или Delete Printer.

• Чтобы создать новый разделяемый модуль, введите в поле редактирования имя, которое вы хотите присвоить ему, и щелкните на кнопке Create Share или Create Printer. Имя объекта не надо помещать в квадратные скобки, как вы делаете это, редактируя файл smb.conf; SWAT добавит скобки самостоятельно. После создания объекта вы можете отредактировать любые опции так же, как и при работе с существующим объектом.

Как было сказано в главе 7, разделяемый объект [homes] имеет специальное назначение, но вы можете создавать, удалять и редактировать его, как любой другой объект. Принтер, помеченный в списке символом *, является принтером по умолчанию, созданным посредством объекта [printers]. Лучше всего непосредственно изменять опции в объекте [printers], но если вы хотите создать разделяемый объект для конкретного принтера, переопределяющий установки в [printers], отредактируйте объект, помеченный звездочкой.

На страницах Globals, Shares и Printers присутствует кнопка Advanced View. (На страницах Globals и Shares она появляется лишь после создания или выбора разделяемого объекта.) По умолчанию администратору доступны лишь наиболее часто используемые опции Samba. После щелчка на Advanced View в окне броузера будут представлены все опции, соответствующие некоторой категории, а кнопка Advanced View будет заменена на Basic View. При активизации кнопки Basic View SWAT снова переходит к отображению ограниченного набора опций. В большинстве случаев разделяемые объекты Samba можно отредактировать с помощью опций, отображаемых по умолчанию, а кнопку Advanced View приходится использовать лишь в отдельных случаях. При переходе к набору опций изменения, внесенные в режиме полного набора опций, не теряются.

По окончании работы со страницами Globals, Shares или Printers щелкните на кнопке Commit Changes, в результате чего внесенные вами изменения будут записаны в файл smb.conf. Чтобы эти изменения были учтены при работе сервера Samba, вам надо перезапустить его. Сделать это можно с помощью интерфейсных элементов, расположенных на странице Status. Щелкните на кнопке Restart smbd, а затем на кнопке Restart nmbd. (Некоторые изменения требуют перезапуска лишь одного из двух серверов, но если вы не знаете, какой сервер затрагивают выполненные вами действия, лучше перезагрузить оба.) Закончив работу с инструментом SWAT, надо завершить выполнение Web-броузера, в противном случае вы можете создать угрозу безопасности системы.

 

Вопросы безопасности при удаленном администрировании

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

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

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

Если помимо специализированного инструмента удаленного администрирования вы также используете сервер удаленной регистрации, опасность незаконного доступа в систему посторонних лиц возрастает. Как было сказано в главе 13, при работе с некоторыми серверами удаленной регистрации пароль передается в незакодированном виде, а другие средства, например SSH, обеспечивают шифрование не только пароля, но и всех передаваемых данных. Таким образом, если вместо регистрации на удаленном компьютере посредством SSH использовать для администрирования системы Linuxconf или SWAT, уровень защиты резко снизится. Сервер Webmin может осуществлять взаимодействие с клиентом через SSL (http://www.openssl.org), в результате чего обеспечивается кодирование пароля и других данных, но это возможно только в том случае, если на компьютерах установлены и настроены средства поддержки SSL. Из сказанного выше следует, что инструменты Linuxconf и SWAT (а также Webmin при отсутствии кодирования данных) желательно использовать лишь в локальных сетях, полностью контролируемых системными администраторами.

Инструменты удаленного администрирования, рассмотренные в данной главе, предоставляют пользователю доступ к удаленному компьютеру в том случае, если он знает имя и пароль. Средства удаленной регистрации, о которых шла речь в главе 13, могут быть настроены так, что регистрация под именем root будет запрещена. Чтобы приступить к администрированию системы, пользователю приходится сначала зарегистрироваться под своим именем, а затем получить дополнительные привилегии с помощью команды su. В этом случае необходимо знать два пароля: свой и пользователя root. Среди инструментов удаленного администрирования только Webmin обеспечивает кодирование данных, но даже он предоставляет низкий уровень защиты в случае, если злоумышленнику станет известен один из паролей. (Как вы уже знаете, существуют различные способы "подслушивания" паролей, передаваемых по сети.)

Снизить риск неавторизованного доступа к данным можно, ограничив набор компьютеров, которым разрешено обращение к инструментам удаленного администрирования. Как вы уже знаете из материала данной главы, Linuxconf позволяет указать IP-адреса компьютеров и сетей, имеющих право обращаться к нему. Если в системе используется xinetd, любая программа удаленного администрирования, запускаемая с помощью данного суперсервера, может быть защищена с помощью TCP Wrappers. Запретить доступ к серверу из внешней сети можно также с помощью брандмауэра. Все эти меры не исключают возможности подслушивания пароля, а IP-адрес, как показывает опыт, может быть фальсифицирован. Поэтому действия по обеспечению защиты лишь снижают вероятность незаконного доступа к системе, но не исключают полностью такой возможности.

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

На первый взгляд может показаться, что применение сервера удаленного администрирования с ограниченной сферой действия, например SWAT, создает меньшую угрозу безопасности системы, чем использование универсальных серверов, таких как Linuxconf и Webmin. На самом деле это не так. Если злоумышленник проникнет в систему посредством SWAT, он может создать новый разделяемый объект, позволяющий ему читать и записывать данные в файлы, содержащиеся в каталоге /etc. С помощью этого объекта можно изменить конфигурацию системы, обеспечив для себя доступ посредством одного из серверов удаленной регистрации, например Telnet. Таким образом, применение инструментов с ограниченной областью действия может в лучшем случае замедлить процесс незаконного проникновения в систему.

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

 

Резюме

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

 

Глава 17

Резервное копирование

 

Создание резервных копий вряд ли можно считать увлекательным занятием, но если вы хотите поддерживать работоспособность вашей системы в течение длительного времени, выполнять эту рутинную работу необходимо. Некоторые сети насчитывают один или два сервера и несколько клиентов, причем конфигурация клиентских компьютеров чрезвычайно проста, и они не содержат важной информации. Клиентские машины по сути выполняют функции X-терминалов. Создавая резервные копии данных в такой сети, достаточно скопировать содержимое сервера. Что же касается клиентов, для них можно создать одну копию, отражающую стандартную конфигурацию системы. Если к сети подключено несколько серверов, необходимо организовать копирование данных с каждого из них. Если же на каждом из клиентских компьютеров будет содержаться важная информация, процедура резервного копирования будет выглядеть по-другому. В начале данной главы обсуждаются общие вопросы, связанные с созданием резервных копий, после чего будут рассмотрены три способа решения задачи резервного копирования: использование tar для архивирования информации, содержащейся на компьютерах под управлением Linux или UNIX, применение Samba для копирования данных в системе Windows и координация действий по резервному копированию в сети с помощью инструмента AMANDA.

Резервное копирование данных в сети — достаточно сложная задача, которая усложняется еще больше с увеличением размеров сети. Дополнительную информацию по этой теме вы найдете в документации, поставляемой в комплекте с инструментами резервного копирования. Тем, кому необходимо подробно разобраться в данном вопросе, можно порекомендовать книгу Престона (Preston) Unix Backup & Recovery (O'Reilly, 1999).

 

Использование серверов резервного копирования

Резервные копии проще всего создавать на локальной машине. Если вы установите накопитель на магнитных лентах на компьютер, работающий под управлением Linux, вы можете пользоваться такими утилитами, как tar, cpio или dump, причем для этого вам не потребуется специально настраивать вашу систему. Резервное копирование в сетевом окружении представляет собой гораздо более сложную задачу, так как компьютеры, участвующие в сетевом взаимодействии, должны быть соответствующим образом сконфигурированы, а программы, применяемые для создания резервных копий, должны обеспечивать работу в сети. (Отсутствие сетевой поддержки в программах резервного копирования в некоторых случаях можно компенсировать за счет применения различных утилит.) Организовать восстановление данных в сети — еще более сложная задача, так как при этом приходится осуществлять взаимодействие с компьютером, на котором отсутствуют многие из сетевых инструментов. По этой причине в небольших сетях рекомендуется осуществлять резервное копирование с использованием локальных устройств. Для обеспечения подобного копирования необходимо затратить значительные средства, поскольку с ростом сети увеличивается число устройств, которые должны быть установлены на компьютерах. Стоимость накопителя, который может быть установлен на рабочей станции, составляет от 100 до 1000 долларов. К этой сумме надо добавить стоимость носителей. Устройства, позволяющие осуществлять резервное копирование в сети, стоят значительно больше, но расходы в пересчете на один компьютер оказываются намного меньше, чем при использовании локальных устройств. Таким образом, одним из аргументов в пользу сетевого резервного копирования является экономия средств.

Аппаратные средства, предназначенные для создания резервных копий

Чаще всего для хранения резервных копий данных используются магнитные ленты. Как правило, чем меньше цена накопителя, тем больше стоят ленты для него, таким образом, по мере приобретения магнитных носителей разница в цене между низкоуровневым и высокоуровневым устройством будет становиться все меньше и меньше. В небольших сетях для резервного копирования чаще всего применяются накопители среднего и высокого уровня стоимостью около 1000 долларов. Такие устройства обычно обеспечивают запись на носитель от 5 до 20 Гбайт информации. Как правило, подобные устройства используют формат DAT (Digital Audio Tape — цифровая аудиолента) или DLT (Digital Linear Tape — лента с цифровой линейной записью). Для резервного копирования в больших сетях применяются более дорогие устройства, использующие DLT либо другие "экзотические" форматы. Объем копируемой информации может быть настолько велик, что станет оправданным применение накопителей с автоматической сменой лент. Логически устройства с автоматической сменой лент могут рассматриваться как накопители с носителем сверхбольшого объема.

Магнитная лента — не единственный носитель, пригодный для создания резервных копий. В качестве альтернативы могут рассматриваться оптические носители, такие как компакт-диски (в том числе перезаписываемые) и DVD. Обычные компакт-диски имеют небольшой объем (630 Мбайт) и не всегда подходят для резервною копирования, однако на них можно хранить информацию, не изменяющуюся во времени, например, использовать для инсталляции операционной системы на клиентском компьютере. Объем перезаписываемых DVD исчисляется гигабайтами, и на них помещается операционная система в полном объеме, но для сетевого копирования он может оказаться недостаточным. Срок хранения информации на оптических носителях очень велик (для компакт-дисков он составляет от 10 до 100 лет), поэтому они хорошо подходят для создания архивов. В системе Linux подобные устройства гораздо менее удобны, чем накопители на лентах, так как для записи данных на них нужны специальные программы, например cdrecord . Однако процесс восстановления носителей очень прост, поскольку они читаются стандартными устройствами, входящими в состав практически каждого компьютера.

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

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

 

Способы резервного копирования

 

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

На заметку

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

 

Резервное копирование, инициируемое клиентом

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

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

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

• Безопасность системы. На компьютере, выполняющем роль клиента резервного копирования, не должна присутствовать программа-сервер; в результате уровень безопасности системы повышается. Если данные копируются с машины, работающей под управлением Linux или UNIX, резервное копирование может осуществляться от имени пользователя root, что обеспечивает полный доступ ко всем файлам.

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

 

Резервное копирование, инициируемое сервером

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

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

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

• Безопасность системы. На каждом клиенте резервного копирования должна выполняться некоторая серверная программа. Обычно эта программа поддерживает протокол разделения файлов, например NFS или SMB/CIFS, либо протокол, подобный FTP, и обеспечивает полный доступ к данным на компьютере. Если злоумышленник использует метод фальсификации IP-адресов и обратится к компьютеру от имени сервера резервного копирования, он может похитить важные данные, например файл /etc/shadow. Сервер резервного копирования в этом случае менее подвержен атакам, так как на нем выполняется только клиентская программа.

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

Внимание

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

 

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

tar

 

Утилита tar — одна из самых популярных программ, используемых для резервного копирования в системах Linux и UNIX. Она объединяет несколько файлов в один файл архива, что упрощает передачу информации по сети и сохранение ее на резервном носителе. Название программы представляет собой сокращение слов tape archive (архив на ленте). Утилиту tar можно использовать для организации резервного копирования как по инициативе клиента, так и по инициативе сервера. Вместо tar в системе Linux могут применяться и другие подобные программы, например cpio или dump. Особенности работы с ними описаны в документации на программы и в справочной системе Linux. В данной главе обсуждается лишь программа tar; ей уделено особое внимание потому, что она наиболее популярна среди пользователей, а также потому, что она используется другими инструментальными средствами, например smbtar и AMANDA.

 

Возможности tar

Утилита tar — чрезвычайно мощный инструмент; она поддерживает большое количество опций. Опции программы tar делятся на две категории: команды и модификаторы. Команды указывают утилите tar, какие действия она должна выполнить, например, создать архив, вывести содержимое существующего архива, извлечь файлы и т.д. Модификаторы уточняют действия программы. С их помощью можно определить устройство, на которое следует записать архив, указать файлы, которые необходимо включить в архив, или задать сжатие архива посредством gzip или bzip2 и т.д. Утилита tar вызывается следующим образом:

tar команда [ модификаторы ] имена_файлов

В качестве имен файлов в большинстве случаев задаются имена каталогов. Если при вызове программы задано имя каталога, tar включает в состав архива все файлы и все подкаталоги этого каталога. Чтобы создать архив всей файловой системы, надо указать корневой каталог (/).

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

Таблица 17.1. Часто употребляемые команды утилиты tar

Команда Сокращенный вариант Описание
--create с Создает архив
--concatenate A Добавляет tar-файл к существующему архиву
--append r Добавляет обычные файлы к существующему архиву
--update u Добавляет файлы, которые имеют более позднюю дату создания, чем файлы с соответствующими именами, присутствующие в составе архива
--diff или --compare d Сравнивает файлы в архиве с файлами на диске
--list t Выводит содержимое архива
--extract или --get x Извлекает файлы из архива

Таблица 17.2. Часто употребляемые модификаторы утилиты tar

Модификатор Сокращенный вариант Описание
--absolute-paths P Сохраняет символ / в начале пути к файлу
--bzip2 I Задает обработку архива с помощью bzip2 . (В старых версиях tar не поддерживается)
--directory каталог C Перед обработкой данных делает указанный каталог текущим
--exclude файл (отсутствует) Запрещает включать файл в архив
--exclude-from файл X Запрещает включать в архив файлы, указанные в данном файле
--file [узел:] файл f Выполняет архивирование, используя в качестве архива указанный файл на указанном узле. (Узел сети указывается при выполнении резервного копирования, инициируемого клиентом.)
--gzip или --ungzip z Задает обработку архива программой gzip или ungzip
--listed-incremental= файл g Создает или использует файл, содержащий результаты инкрементного копирования
--multi-volume M Задает обработку архива на нескольких лентах
--one-file-system 1 Сохраняет или восстанавливает только одну файловую систему
--same-permissions или --preserve-permissions p Сохраняет информацию о пользователях и о правах доступа
--tape-length N L Определяет длину ленты в килобайтах; используется совместно с --multi-volume
--verbose v Выводит информацию об обработанных файлах
--verify W Сразу после записи сравнивает исходный файл с файлом, записанным в архив

В качестве примера использования приведенных выше опций рассмотрим следующую ситуацию. Предположим, что к компьютеру через интерфейс SCSI подключен накопитель на магнитных лентах. Для доступа к этому устройству используется имя /dev/st0 или /dev/nst0. Для создания резервной копии содержимого каталога /home с сохранением прав доступа и с выводом имен архивируемых файлов надо задать следующую команду:

# tar --create --verbose --file /dev/st0 /home

Если указать сокращенные обозначения опций, приведенные в табл. 17.1 и 17.2, то данная команда примет вид:

# tar cvf /dev/st0 /home

Некоторые опции программы tar (а именно --one-file-system, --same-permissions, --listed-incremental и --verify) заслуживают более подробного обсуждения. В состав файловой системы Linux могут входить виртуальные файловые системы (например, /proс) и сменные носители. Кроме того, не исключено, что вы захотите запретить резервное копирование файловых систем, находящихся на некоторых устройствах. При использовании опции --one-file-system копироваться будут только те разделы, которые вы непосредственно укажете. Вместо --one-file-system можно задать опцию --exclude или --exclude-from, которая позволяет непосредственно исключать из процесса резервного копирования некоторые каталоги, например /proc.

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

Если при вызове tar указана опция --listed-incremental, программа создает новый файл либо использует имеющийся с информацией о файлах, включенных в архив. При пером запуске tar с этой опцией создается файл для хранения сведений об архиве, и все указанные файлы помещаются в архив. При последующих вызовах утилиты tar с опцией --listed-incremental обрабатываются только те файлы, которые были созданы или модифицированы с момента последней операции резервного копирования. Другими словами, данная опция позволяет вместо полного резервного копирования осуществлять частичное, или инкрементное, копирование. Многие администраторы раз в неделю или раз в месяц выполняют полное копирование и ежедневно — частичное. Такой подход позволяет обеспечить сохранность данных минимальными усилиями. (Восстанавливая информацию с резервной копии, созданной посредством инкрементного копирования, вы, возможно, обнаружите, что недавно удаленные файлы снова появились на диске. Дело в том, что при инкрементном копировании файлы, которые были удалены с момента последнего полного копирования, не помечаются как отсутствующие.) Выполняя резервное копирование в сетевом окружении, целесообразно в разные дни недели осуществлять полное копирование информации на разных компьютерах. Например, вы можете составить расписание и указать в нем, что в понедельник должно выполняться копирование содержимого machine1, во вторник — machine2 и т.д.

Опция --verify предназначена для проверки того, насколько корректно выполнено копирование данных. В результате такой проверки время копирования существенно возрастает, но подобное замедление работы часто бывает оправдано, особенно в тех случаях, когда в накопителе отсутствует встроенная функция проверки. (В большинстве устройств среднего и высокого уровня поверка осуществляется на аппаратном уровне.) Если вы указываете при вызове tar опцию --verify или --diff, возможны ложные сообщения об ошибках. Дело в том, что в то время, когда выполняется резервное копирование, пользователи продолжают работать в системе, поэтому с момента копирования на резервный носитель до момента проверки файл может быть изменен. Наиболее часто модифицируются файлы протоколов, содержимое очереди на печать, файлы в каталоге /tmp и другие подобные данные. Если в результате проверки выявлено несоответствие содержимого часто изменяемых файлов, повода для беспокойства нет. Если же при проверке не совпали статические данные, например файлы в каталоге /usr это может означать, что копирование выполняется некорректно.

Многие современные накопители на магнитных лентах поддерживают встроенные функции сжатия, поэтому в применении опции --bzip2 или --gzip обычно нет необходимости. Если же вы указываете данные опции при вызове tar, помните, что их использование может представлять угрозу для целостности резервной копии. Опции --bzip2 и --gzip осуществляют сжатие не отдельных файлов, а всего архива, поэтому если в процессе сжатия возникнет ошибка, данные, содержащиеся в архиве, будут утеряны. Сжатие, реализованное на аппаратном уровне, обеспечивает определенную устойчивость к ошибкам подобного рода. В случае сбоя искажаются один-два файла, а остальные данные в архиве можно использовать. Некоторые программы резервного копирования сжимают данные таким же способом, повышая тем самым надежность всей системы. Например, в коммерческом продукте BRU (http://www.tolisgroup.com) используется пофайловое сжатие информации.

 

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

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

В качестве простейшей проверки можно скопировать данные с помощью одной из команд, рассмотренных в предыдущем разделе. Чтобы сделать это, необходимо выяснить, к какому устройству следует обращаться. Для накопителей среднего и высокого уровня чаще всего используются следующие четыре имени: /dev/st0, /dev/nst0, /dev/ht0 и /dev/nht0. Первые два имени применяются для обозначения устройств SCSI, а остальные два соответствуют устройствам EIDE/ATAPI. Имена файлов, имена которых начинаются с буквы n, представляют устройства без перемотки (nonrewinding device). По окончании действий с таким устройством лента остается в той позиции, в которой были записаны последние данные, в результате вы можете размещать несколько копий на одной ленте. Если в начале имени файла буква n отсутствует, это устройство считается устройством с перемоткой (rewinding device). В этом случае по окончании операции записи лента автоматически перематывается. Заметьте, что наличие или отсутствие перемотки является характеристикой не устройства, а представляющего его файла. Каждый накопитель, в зависимости от используемого драйвера, может рассматриваться либо как устройство без перемотки, либо как устройство с перемоткой. Если к компьютеру подключено несколько накопителей на ленте, имя файла, представляющего второе устройство, будет заканчиваться следующему устройству будет соответствовать 2 и т.д.

Существуют накопители, которым соответствуют файлы устройств с другими именами. Например, раньше использовались накопители, подключаемые через порт, предназначенный для работы с гибкими дисками. Работа с ними осуществлялась посредством файлов /dev/qft0 и /dev/nqft0. Эти накопители отличаются малой емкостью носителей и низким быстродействием и не отвечают современным требованиям, предъявляемым к устройствам резервного копирования. Иногда устройства подключаются через специализированный интерфейс. Драйверы для работы с ними должны быть установлены при настройке Linux.

Если при выполнении копирования данных с локального компьютера у вас возникают проблемы, проверьте используемые аппаратные средства и драйверы устройств. Для работы с устройством SCSI необходимы как базовые средства поддержки SCSI, так и средства для взаимодействия с накопителем SCSI. Соответственно при использовании устройств EIDE/ATAPI необходимо обеспечить поддержку как EIDE, так и накопителя EIDE/ATAPI. При тестировании следует проверить не только создание резервных копий, но и восстановление данных. Целесообразно сначала испробовать сервер резервного копирования на небольшом каталоге, а потом переходить к работе с данными значительного объема. Чтобы убедиться, что информация восстановлена корректно, надо использовать режим верификации.

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

На заметку

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

Используя tar и mt, можно разместить на одной ленте несколько резервных копий. Утилита mt вызывается следующим образом:

mt [-f устройство ] операция [ счетчик ] [ параметры ]

Под операцией подразумевается одна из следующих команд: fsf (forward space files — переход к следующему файлу), bsf (backward space files — переход к предыдущему файлу), rewind (перемотка ленты) и datcompression (установка режима сжатия; параметр 0 запрещает, а параметр 1 разрешает сжатие). Например, в результате приведенной ниже последовательности команд создаются две резервные копии и осуществляется их верификация.

# tar cvplf /dev/nst0 testdir-1/

# tar cvplf /dev/nst0 testdir-2/

# mt -f /dev/nst0 rewind

# tar df /dev/nst0 testdir-1/

# mt -f /dev/nst0 fsf 1

# tar df /dev/nst0 testdir-2/

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

 

Резервное копирование, инициируемое клиентом

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

Настройка сервера для резервного копирования по инициативе клиента

Опция --file, описанная в табл. 17.2, позволяет указать программе tar файл архива. Это может быть обычный файл на диске, файл устройства, представляющий накопитель на магнитных лентах, и путь к сетевому ресурсу. В последнем случае на компьютере, выступающем в роли сервера резервного копирования, должен выполняться демон rshd (часто он называется in.rshd). Этот демон позволяет удаленной системе выполнять команды на локальной машине. Благодаря наличию программы rshd утилита tar получает возможность передать созданный ею файл на устройство, подключенное к серверу резервного копирования. Сервер rshd поставляется с большинством версией системы Linux и обычно запускается посредством суперсервера. Соответствующая запись в файле /etc/inetd.conf имеет следующий вид:

shell stream tcp nowait root /usr/sbin/tcpd \

 /usr/sbin/in.rshd -h

Если в вашей системе используется сервер xinetd, вам необходимо создать запись аналогичного назначения в файле /etc/xinetd.conf или создать отдельный файл и включить его в каталог /etc/xinetd.d. При выполнении резервного копирования чрезвычайно важны меры по ограничению доступа, предпринимаемые посредством TCP Wrappers или непосредственно предусмотренные в xinetd. Решение о предоставлении доступа через rshd принимается на основе анализа IP-адреса. Хотя TCP Wrappers и xinetd используют тот же механизм контроля за обращениями клиентов, избыточные средства обеспечения безопасности пригодятся на тот случай, если в программе rshd будут обнаружены ошибки, позволяющие обойти механизмы защиты.

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

Внимание

В некоторых системах опция -h программы rshd не обрабатывается. В этом случае приходится создавать резервные копии по-другому. Необходимо запустить на сервере резервного копирования сервер SSH и на стороне клиента связать ssh с именем rsh . При этом утилита tar для передачи данных по сети будет обращаться к программе ssh . Такой подход обеспечивает дополнительную степень защиты, и ему имеет смысл следовать даже в тех случаях, когда опция -h обрабатывается так, как указано в документации. Сервер SSH необходимо сконфигурировать таким образом, чтобы он при выполнении аутентификации не запрашивал пароль.

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

Выполнение резервного копирования

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

# tar cvlpf buserver:/dev/st0 /home /var /

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

Для управления накопителем, подключенным к серверу резервного копирования, может использоваться утилита mt. Например, по команде mt -f buserver: /dev/nst0 rewind осуществляется перемотка ленты.

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

 

Резервное копирование, инициируемое сервером

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

На заметку

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

Установка конфигурации сети для резервного копирования, инициируемого сервером

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

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

При выполнении резервного копирования по инициативе сервера возникает угроза безопасности системы. Она состоит в том, что пользователь, зарегистрированный на сервере резервного копирования под именем root, получает неограниченный доступ к данным на клиентской машине. Происходит это потому, что при экспортировании каталогов указывается опция no_root_squash. Без этой опции сервер резервного копирования не сможет прочитать системные файлы и файлы, принадлежащие различным пользователям. Такая конфигурация позволяет злоумышленнику, имеющему доступ к компьютерам локальном сети, прочитать все файлы с клиента резервного копирования, а если при экспортировании каталогов была разрешена запись, то он сможет даже изменить содержащиеся в них данные. Подобные действия имеют возможность выполнять и пользователи внешней сети, указав в запросе фальсифицированный IP-адрес. Для того чтобы уменьшить вероятность несанкционированного доступа, необходимо защитить сервер и все клиенты резервного копирования с помощью брандмауэра, а систематически просматривая файлы протоколов, вы сможете вовремя выявлять попытки взлома системы.

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

/home buserver(ro,no_root_squash)

/var  buserver(ro,no_root_squash)

/     buserver(ro,no_root_squash)

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

Выполнение резервного копирования

Команды, по которым выполняется резервное копирование, напоминают команды, рассмотренные ранее, но, для того, чтобы они выполнялись успешно, необходимо смонтировать каталоги, экспортируемые клиентом, на сервере резервного копирования. Предположим, что клиент резервного копирования имеет имя buclient, а на сервере существует каталог /mnt/client, выполняющий роль точки монтирования. Для монтирования каталогов и создания резервной копии может быть использована приведенная ниже последовательность команд.

# mount -t nfs -о soft buclient:/ /mnt/client

# mount -t nfs -o soft buclient:/var /mnt/client/var

# mount -t nfs -o soft buclient:/home /mnt/client/home

# cd /mnt/client

# tar cvlf /dev/st0 home var ./

На заметку

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

Обратите внимание на то, что среди представленных выше команд присутствует команда cd. С ее помощью точка монтирования экспортируемых каталогов объявляется как текущий каталог. При этом дерево подкаталогов выглядит так, как будто вы зарегистрировались на клиенте резервного копирования. Программа tar сохраняет информацию о каталогах, лишь начиная с точки монтирования; полный путь к файлу не записывается. В результате в архиве на ленте никак не отображена информация о том, что экспортируемые каталоги были смонтированы в точке /mnt/client и при восстановлении данных требуемые каталоги можно смонтировать в любой другой позиции файловой системы. Для создания резервной копии можно также использовать следующую команду:

# tar cvlf /dev/st0 /mnt/client/home /mnt/client/var /mnt/client

В данной команде явно указан каталог /mnt/client. (Если вы не зададите модификатор --absolute-paths, при создании архива первый символ / будет удален и сохранится лишь имя mnt/client.) В этом случае при восстановлении файлов каталоги необходимо монтировать либо в той же точке, в которой они монтировались при создании резервной копии, либо в каталоге, путь к которому оканчивается на mnt/client. В противном случае будет создан новый каталог, причем он разместится не на клиентской машине, а на сервере резервного копирования.

Внимание

Недостаток описанного способа резервного копирования состоит в том, что если клиент прекратит обмен по сети, процесс сохранения данных остановится на неопределенное время. В приведенном выше примере при монтировании указывалась опция -о soft . Она позволяет клиенту NFS на сервере резервного копирования передавать программе tar сведения об ошибках, предотвращая тем самым "зависание" процедуры копирования данных.

 

Использование SMB/CIFS

 

В предыдущем разделе рассматривалось использование утилиты tar совместно с программой rshd, выполняющейся на сервере резервного копирования, либо с сервером NFS, который выполняется на компьютере, выступающем в роли клиента резервного копирования. Для обеспечения взаимодействия компьютеров можно также использовать и другие серверы. В данном разделе рассматриваются вопросы выполнения резервного копирования с применением сервера SMB/CIFS. Такой способ создания резервных копий удобно использовать при работе в сетях, содержащих большое количество компьютеров под управлением Windows. В главе 7 описывался продукт Samba, с помощью которого можно организовать взаимодействие систем Windows и Linux по протоколу SMB/CIFS.

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

 

Создание резервной копии клиента Windows с помощью сервера Linux

Резервное копирование, инициализируемое сервером, с применением Samba осуществляется почти так же, как и копирование по инициативе сервера с использованием NFS, но работа с продуктом Samba и системой Windows имеет ряд особенностей. Необходимо обратить внимание на возможности, предоставляемые программой smbtar, и специфику поддержки длинных имен Windows.

Объявление файлов для совместного использования

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

В составе системы Windows поставляются программы поддержки сервера SMB/CIFS, однако по умолчанию эти программные средства не установлены. Для включения необходимых программных компонентов необходимо использовать элемент в составе Control Panel, который в зависимости от версии системы называется Network или Network and Dial-Up Connections. Работая с системой Windows 9x/Me, следует дважды щелкнуть на пиктограмме Network, в результате чего отобразится диалоговое окно Network. В системе Windows NT или 2000 необходимо щелкнуть правой кнопкой мыши на соответствующем объекте в Network and Dial-Up Connections и выбрать пункт Properties. Необходимый вам компонент называется File and Printer Sharing for Microsoft Networks. Если данный компонент отсутствует, щелкните на Add или Install. Перечень сетевых служб, среди которых присутствует File and Printer Sharing for Microsoft Networks, показан на рис. 17.1. Возможно, вам потребуется задать принадлежность системы к рабочей группе. Сделать это можно с помощью вкладки Identification диалогового окна Network (Windows 9x/Me) или объекта System в составе Control Panel (Windows 2000).

Рис. 17.1. Чтобы система Windows функционировала как сервер SMB/CIFS, в ней должен быть установлен компонент File and Printer Sharing for Microsoft Networks

Инсталлировав сервер SMB/CIFS, вам надо организовать разделение дисков, содержимое которых вы хотите записывать на резервный носитель. Для этого выполните следующие действия.

1. В окне My Computer щелкните правой кнопкой мыши на устройстве, доступ к которому вы хотите разрешить, и в появившемся контекстном меню выберите пункт Sharing. (Если этот пункт отсутствует, то, вероятнее всего, программное обеспечением сервера SMB/CIFS не установлено.) В результате вы увидите диалоговое окно Properties, подобное изображенному на рис. 17.2.

Рис. 17.2. Диалоговое окно Sharing системы Windows 2000. Аналогичное окно системы Windows 9x/Me содержит другой набор опций

2. Чтобы разрешить доступ к устройству, щелкните на опции Shared As или Share This Folder. При этом вам потребуется ввести имя разделяемого объекта, которое вы будете использовать при монтировании на сервере резервного копирования. В данном случае роль сервера резервного копирования выполняет компьютер под управлением Linux. (В системе Windows 2000 для ввода имени разделяемого объекта надо щелкнуть на New Share.)

3. При работе с Windows 9x/Me необходимо с помощью опции Access Type разрешить чтение и запись или только чтение и ввести пароль. Для создания резервных копий достаточно, чтобы данные были доступны только для чтения, но для восстановления данных необходимо также разрешить запись информации (в Windows 9x/Me, чтобы предоставить право чтения и записи, надо установить значение Full опции Access Туре). В Windows 2000 с помощью вкладки Security можно определить, кто имеет право доступа к разделяемому объекту.

4. Щелкните на кнопке OK, разрешив тем самым совместное использование устройства.

5. Повторите пп. 1–4 для каждого устройства, содержимое которого необходимо записать на резервный носитель.

После выполнения указанных действий устройство становится доступным для удаленных компьютеров. Чтобы убедиться в наличии доступа, можно использовать броузер Network Neighborhood либо попробовать обратиться к файлу с другого узла сети. На компьютере под управлением Linux для этой цели можно использовать инструмент smbclient.

Использование smbtar

В составе пакета Samba поставляется программа smbtar. Как нетрудно догадаться, этот инструмент сочетает в себе возможности утилиты tar и клиента SMB/CIFS. На самом деле smbtar представляет собой сценарий оболочки, который вызывает программы tar и smbclient, используя предоставляемые ими возможности для создания резервных копий данных, которые содержатся на компьютерах под управлением Windows. Инструмент smbtar можно использовать как для создания резервной копии всего разделяемого объекта, так и для копирования отдельных файлов. Сценарий smbtar вызывается с помощью следующего выражения:

smbtar -s клиент_резервного_копирования \

 [-x имя_разделяемого_объекта ] [-u имя_пользователя ] \

 [-p пароль ] [-d каталог ] [-t устройство ] [-r] [-v]

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

• s клиент_резервного_копирования . Эта единственная обязательная опция задает имя клиента резервного копирования. В качестве ее значения указывается NetBIOS-имя компьютера. В зависимости от значения опции name resolve order в файле smb.conf, система также может обрабатывать DNS-имена узлов сети.

• x имя_разделяемого_объекта . Данная опция позволяет задать имя разделяемого объекта (это имя вводится на этапе 2 описанной выше процедуры). По умолчанию принимается имя backup.

• u имя_пользователя . Если вы хотите установить соединение под именем, отличающемся от имени пользователя, под которым вы выполняете резервное копирование, вам необходимо указать данную опцию. Заметьте, что в Windows 9x/Me пользовательское имя не применяется, за исключением тех случаев, когда система входит в состав домена.

• p пароль . Если для работы с разделяемым объектом необходим пароль, вы можете задать его с помощью данной опции. При этом возникает серьезная угроза безопасности системы, так как значение пароля будет сохранено в списке предыстории, поддерживаемом оболочкой (в случае, если вы вводите команду smbtar вручную), кроме того, пароль отображается в перечне выполняемых процессов (соответствующие данные доступны посредством утилиты ps). Если же вы запускаете smbtar из сценария, необходимо проследить за тем, чтобы код сценария мог просматривать только пользователь root.

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

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

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

• v. Данная опция включает режим вывода дополнительной информации. Если опция -v задана, smbtar отображает имена копируемых файлов.

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

# smbtar -s WORK -p password -x CDRIVE -t /dev/st0 -v

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

Использование smbmount

Вместо того чтобы работать с инструментом smbtar, вы можете воспользоваться предоставляемой Linux возможностью монтировать разделяемые объекты SMB/CIFS. Для монтирования подобных объектов можно применять утилиту mount или smbmount. При использовании программы mount надо указать тип файловой системы smbfs, задать NetBIOS-имя компьютера под управлением Windows, имя разделяемого объекта и имя пользователя. Сформированная таким образом команда имеет следующий вид:

# mount -t smbfs //WORK/CDRIVE /mnt/backup -о \

 username=fred,password= password

Эквивалентная ей команда smbmount выглядит так:

# smbmount //WORK/CDRIVE /mnt/backup -о \

 username=fred,password= password

На заметку

Реализации утилиты smbmount в пакетах 2.0.x Samba существенно отличаются одна от другой. В ранних версиях данной программы использовался другой синтаксис. Приведенный выше вызов корректен для программ smbmount , поставляемых в составе версий 2.0.5a-2.2.2 Samba.

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

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

# umount /mnt/backup

Особенности обработки имен файлов Windows

Для создания резервных копий содержимого системы Windows часто используются компьютеры под управлением Linux. Однако при этом необходимо учитывать особенности обработки имен файлов. Дело в том, что программы mount и smbmount интерпретируют имена файлов иначе, чем это происходит в системе Windows. Для того чтобы понять эти различия, необходимо рассмотреть правила хранения файлов в Windows. Файловая система FAT (File Allocation Table — таблица размещения файлов), используемая в Windows 9x/Me и поддерживаемая в системах Windows NT, 2000 и XP, ориентирована на работу с файлами, имена которых содержат восемь символов, а расширение — три символа. Такие имена файлов называются именами 8.3. Для хранения длинных имен файлов в каталогах Windows предусмотрены дополнительные записи. Длинными считаются имена файлов, содержащие больше восьми символов имени и больше трех символов расширения, либо имена, составленные из символов, регистр которых должен быть сохранен. (Имена 8.3, в зависимости от используемых программ, могут отображаться символами верхнего регистра либо представляться как имя, начинающееся с прописной буквы, например File.txt. Существует также возможность указать, что имя 8.3 должно представляться символами только верхнего или только нижнего регистра.) Проблема с обработкой имен файлов в Linux возникает из-за того, что в данной системе не поддерживаются имена 8.3, а используются только длинные имена файлов.

В отличие от Windows, Linux интерпретирует имена 8.3, которые присутствуют в каталогах, смонтированных с помощью mount или smbmount, как имена, состоящие только из символов нижнего регистра (например, file.txt). Такие файлы восстанавливаются корректно, но если при создании имени 8.3 было указано, что оно должно включать только символы нижнего регистра, процедура восстановления данных может представить его как состоящее из символов верхнего регистра. Такая особенность обработки имен редко приводит к возникновению серьезных проблем, поскольку при интерпретации имен файлов Windows не учитывает регистр.

Программа smbtar интерпретирует имена 8.3 как полностью состоящие из символов верхнего регистра, поэтому при ее использовании может возникнуть следующая проблема. Предположим, что в системе Windows был создан файл, имя которого полностью состоит из символов верхнего регистра, считается длинным именем, но содержит не больше восьми, а в составе расширения — не больше трех знаков. Программа smbtar, выполняемая в среде Linux, может интерпретировать такое имя как имя 8.3, в результате чего при восстановлении оно будет обработано некорректно, т.е. не будет указано, что имя является длинным и состоит из символов верхнего регистра. Данная проблема также не является серьёзной, но может создавать неудобства для пользователей.

Существенные трудности возникают при создании имен 8.3, которые должны соответствовать длинным именам. В системе Windows эта задача решается автоматически; если в окне DOS, отображаемом в среде Windows, вы зададите команду DIR, вы увидите как короткие, так и длинные имена файлов. Поскольку система Linux не имеет информации о том, какие имена являются короткими, при восстановлении данных она полагается на соответствующие средства Windows. Как правило, регистр символов и другие особенности коротких имен не имеют значения для системы, но в некоторых случаях в результате несоответствия имен могут возникать нежелательные последствия. Например, если в конфигурационном файле указано короткое имя файла и если в результате восстановления данных это имя подверглось изменениям, программа не найдет требуемый файл. Кроме того, в системном реестре Windows некоторые имена файлов хранятся в формате 8.3, поэтому в результате восстановления файлов часть записей может оказаться некорректной. Это приведет к ошибкам в работе и даже к разрушению системы. Чтобы уменьшить вероятность возникновения подобных проблем, следует придерживаться приведенных ниже правил.

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

• Используйте длинные имена в составе конфигурационных файлов. Если вам необходимо включить в конфигурационный файл имя каталога, задавайте длинное имя. Например, если вы хотите задать каталог в качестве значения переменной PATH в файле AUTOEXEC.BAT, используйте его полное имя. Этим вы достигнете того, что при внесении изменений в имена файлов 8.3 функционирование системы не изменится.

• Создавайте длинные имена файлов, различающиеся первыми шестью символами. При создании имени 8.3 Windows оставляет первые шесть символов низменными, затем присоединяет к ним символ и порядковый номер, начинающийся с единицы. Например, имя longfilename.txt может быть преобразовано в имя 8.3 LONGFI~1.ТХТ. Если все длинные имена файлов в каталоге будут различаться первыми шестью символами, при преобразовании в формат 8.3 все они будут оканчиваться последовательностью ~1, в результате вероятность некорректного восстановления имени файла уменьшится.

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

На заметку

Файловая система NTFS (New Technology Filesystem — новая технология файловой системы), используемая в Windows NT, 2000 и XP, также поддерживает и имена 8.3, и длинные имена файлов. Однако вероятность возникновения проблем с преобразованием имен гораздо меньше, чем в тех системах, в которых используется FAT.

 

Разделяемые объекты резервного копирования

Один из способов создания резервных копий с применением Samba состоит в использовании разделяемых объектов резервного копирования. Разделяемый объект резервного копирования предоставляет собой объект Samba, связанный с устройством резервного копирования. Существует несколько подходов к работе с данными объектами, и все они могут рассматриваться как резервное копирование, инициируемое клиентом.

Что такое сервер резервного копирования

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

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

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

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

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

Разделяемые объекты резервного копирования создаются так же, как и другие типы разделяемых объектов Samba. Различие состоит лишь в том, что вы, вероятнее всего, захотите использовать сценарии для автоматического монтирования устройства при первом обращении к нему и размонтирования его по завершении процедуры создания резервной копии. Кроме того, в определении объекта резервного копирования обычно присутствует параметр max connections, ограничивающий число пользователей, которые имеют возможность одновременно работать с данным объектом. Ниже приведено определение объекта резервного копирования, который позволяет удаленным пользователям записывать резервные копии данных на устройство Zip, смонтированное в позиции файловой системы /mnt/zip.

[zip]

 comment = Zip Backups

 path = /mnt/zip

 read only = No

 max connections = 1

 preexec = /bin/mount /mnt/zip

 postexec = /bin/umount /mnt/zip

На заметку

Поскольку многие клиенты SMB/CIFS, в том числе средства, реализованные в системе Windows, не размонтируют разделяемый объект, вам, возможно, придется использовать глобальный параметр deadtime , который указывает на то, что после определенного периода бездействия соединение должно быть разорвано. Для устройства резервного копирования желательно задать параметр deadtime = 5 . Значение этого параметра сообщает, что соединение будет разорвано через пять минут после прекращения активности.

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

На сменных носителях может использоваться любая файловая система, поддерживаемая Linux. Однако, если эти носители должны читаться в других системах, вам, возможно, придется отказаться от применения некоторых форматов. Например, если пользователям необходимо читать данные, записанные на сменном диске в системе Windows, очевидно, что на нем должна быть сформирована файловая система FAT. Если же диски будут устанавливаться только на устройствах, подключенных к компьютеру под управлением Linux, то на нем может присутствовать FAT, ext2fs или любая другая файловая система, с которой может работать Linux.

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

[backup]

 path = /var/spool/samba

 printable = Yes

 print command = /usr/local/bin/samba-backup %H %s %U \

  /var/spool/samba; rm %s

Данный объект определяет псевдопринтер, который получает от клиента резервного копирования zip-файлы. Для извлечения содержимого zip-файла и копирования его на ленту с помощью tar этот объект использует сценарий /usr/local/bin/samba-backup, код которого приведен в листинге 17.1. В результате получается копия данных на ленте, аналогичная той, которая создается с помощью программы smbtar. Модифицировав сценарий или изменив параметр print command, вы можете организовать непосредственную запись zip-файла на ленту. Это позволит предотвратить потерю признаков скрытых и системных файлов при извлечении содержимого zip-файла в системе Linux.

Листинг 17.1. Сценарий, поддерживающий работу разделяемого объекта резервного копирования, реализованного в виде псевдопринтера

#!/bin/sh

# $1 = Рабочий каталог пользователя, который передал

# задание на обработку

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

# $3 = Имя пользователя, который передал задание на обработку

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

mkdir -p $1/backup/samba

cd $1/backup/samba

unzip $4/$2

tar cvpf /dev/st0 ./ > $1/tar.out

mail -s "Backup finished" $3 < $1/tar.out

rm $1/tar.out

rm -r $1/backup/samba

ВНИМАНИЕ

Описанный здесь подход предполагает, что файл устройства резервного копирования доступен всем пользователям. Существуют, однако, способы обойти это требование. Например, вы можете использовать для всех соединений учетную запись root . Также можно включить в определение разделяемого объекта в файле smb.conf параметр force user , который устанавливал бы идентификатор пользователя, по инициативе которого выполняется команда "печати". Вы можете создать специальную группу, членам которой накопитель на магнитных лентах был бы доступен для чтения и записи; в этом случае вам потребуется параметр force group .

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

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

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

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

 

Использование AMANDA

 

В предыдущих разделах данной главы рассматривались основные способы создания резервных копий и конфигурация компьютеров, необходимая для реализации этих способов. Если в вашей сети содержится относительно небольшое число компьютеров, вы, возможно, станете создавать резервные копии вручную либо напишете сценарий для автоматизации выполнения данной задачи. Если же число узлов в сети велико, вам понадобятся более сложные инструменты. Одним из таких инструментов является AMANDA (Advanced Maryland Automatic Network Disk Archiver). Данный пакет объединяет различные инструменты, предназначенные для выполнения резервного копирования в сети, и ориентирован в основном на работу в сетях небольшого и среднего размера, но может применяться и в больших сетях. Программное обеспечение AMANDA поставляется в составе версий Linux Debian, Red Hat, Mandrake и SuSE. Если же требуемые программы отсутствуют, вы можете скопировать их с Web-страницы AMANDA (http://www.amanda.org).

Внимание

В исполняемых файлах AMANDA закодированы некоторые значения, используемые при работе данного инструмента, поэтому если вы попытаетесь объединить компоненты AMANDA, предназначенные для выполнения в различных системах, то они, вероятнее всего, работать не будут. Если в вашей операционной среде установлено большое количество различных пакетов, рекомендуется самостоятельно построить создать AMANDA из исходных кодов. Убедитесь, что во всех системах посредством опций --with-user и --with-group заданы один и тот же пользователь и группа. Возможно, вы захотите создать учетную запись и группу, специально предназначенные для выполнения различных операций с помощью AMANDA.

 

Выполнение AMANDA

Пакет AMANDA включает программное обеспечение как сервера, так и клиента. Серверные программы следует установить на компьютере, выполняющем функции сервера резервного копирования, а клиентские программы — на клиенте резервного копирования. Для взаимодействия между собой эти программы применяют собственные протоколы. NFS, rshd и другие подобные протоколы при работе AMANDA не используются. (При выполнении резервного копирования данных, расположенных на компьютерах под управлением Windows, AMANDA использует программу smbclient и стандартный сервер SMB/CIFS.)

AMANDA не только поддерживает сетевые соединения, но и выступает в роли инструмента планирования. Эта возможность помогает осуществлять резервное копирование, а для сети большого размера планирование является неотъемлемой частью работ по администрированию систем. Так, например, вы вряд ли собираетесь при каждой операции резервного копирования создавать копию каждого файла на каждом компьютере. Подобная политика создала бы огромную нагрузку на сеть, и процесс копирования длился бы несколько суток. Для того чтобы минимизировать влияние процедуры резервного копирования на работу сети, при запуске простого инструмента наподобие tar задается опция --listed-incremental (или эквивалентная ей). AMANDA позволяет указать, какой компьютер должен участвовать в резервном копировании в конкретный момент времени и должно ли выполняться полное или инкрементное копирование данных.

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

 

Настройка клиентских машин для использования AMANDA

AMANDA осуществляет резервное копирование, инициируемое сервером, поэтому на компьютере, выступающем в роли клиента, должна выполняться программа-сервер. Данная программа, предназначенная для работы в системах Linux и UNIX, поставляется в составе пакета AMANDA и называется amandad. Эта программа-сервер обычно запускается с помощью суперсервера. Соответствующая запись в конфигурационном файле /etc/inetd.conf имеет следующий вид:

amanda dgram udp wait amanda amandad amandad

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

На заметку

В документации на пакет AMANDA описывается использование учетной записи и группы, специально предназначенных для выполнения резервного копирования, но такой подход часто не дает результатов. Чтобы сервер amandad работал, его следует запустить от имени пользователя root .

Для запуска сервера AMANDA с помощью суперсервера в файл /etc/services необходимо включить специальную запись. Она может выглядеть следующим образом:

amanda 10080/udp

После того как вы создали записи в конфигурационном файле суперсервера и в файле /etc/services, вам следует перезагрузить суперсервер. В результате клиент резервного копирования AMANDA станет доступен для сервера резервного копирования. Остальные действия по настройке выполняются на компьютере, выступающем в роли сервера резервного копирования.

На заметку

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

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

buserver.threeroomco.com amanda

Как было замечено ранее, для создания резервных копий данных, расположенных на компьютере под управлением Windows, AMANDA использует сервер SMB/CIFS. Настройка клиентов Windows резервного копирования для взаимодействия по протоколу SMB/CIFS рассматривалась выше в данной главе.

 

Настройка сервера резервного копирования AMANDA

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

amandaidx stream tcp nowait amanda amindexd amindexd

amidxtape stream tcp nowait amanda amidxtaped amidxtaped

Как и для программ, выполняющихся на клиенте резервного копирования, вам, возможно, придется указать полный путь к исполняемым файлам. Если же в вашей системе используется xinetd, вам надо создать в конфигурационном файле записи по соглашениям, описанным в главе 4. Чтобы указанные программы могли запускаться посредством суперсервера, надо включить в файл /etc/services следующие строки:

amandaidx 10082/tcp amidxtape 10083/tcp

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

 

Формирование конфигурационного файла AMANDA

Особенности работы пакета AMANDA определяются содержимым конфигурационных файлов amanda.conf, которые обычно находятся в подкаталогах каталога /etc или /usr/local/etc. Обычно конфигурационные файлы AMANDA размещаются на двух уровнях подкаталогов. Эти подкаталоги доступны для чтения только пользователю, который должен работать с пакетом AMANDA (в данном примере это пользователь amanda). Подкаталог верхнего уровня обычно называется amanda, а имена подкаталогов нижнего уровня выбираются в соответствии с задачами резервного копирования. Например, конфигурационный файл, описывающий правила ежедневного копирования, может размещаться в каталоге /usr/local/etc/amanda/Daily, а файл, определяющий создание архивов, — в каталоге /usr/local/etc/amanda/Archive. Если вы использовали для инсталляции AMANDA исходные коды, в вашем распоряжении имеется образец конфигурационного файла. Он находится в каталоге example инсталляционного пакета.

Установка основных опций

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

dumpcycle 4 weeks

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

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

• org. С помощью данной опции задается название организации, которое затем указывается в отчетах, генерируемых AMANDA. Значение опции org никак не влияет на процесс создания резервной копии.

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

• dumpuser. Посредством данной опции указывается имя пользователя, инициирующего процедуру резервного копирования. При инсталляции AMANDA это имя задается с помощью опции --with-user.

• dumpcycle. В качестве значения этой опции указывается число дней, составляющих цикл резервного копирования.

• runspercycle. AMANDA может запускаться каждый день, несколько раз в день или один раз в несколько дней. Периодичность запусков задается с помощью данной опции. Предположим, что цикл резервного копирования, указанный посредством опции dumpcycle, составляет четыре недели. Установив значение runspercycle, равное 20, вы сообщаете, что данные для копирования должны выбираться исходя из того, что AMANDA будет запускаться один раз в день в рабочие дни. Значение 4 говорит о том, что AMANDA будет запускаться один раз в неделю. (Заметьте, что реальный запуск AMANDA осуществляется с помощью инструмента cron. Значение опции runspercycle не влияет на периодичность запуска, оно лишь позволяет AMANDA планировать, какие данные должны быть скопированы на резервный носитель.)

• tapecycle. Значение данной опции определяет число магнитных лент, используемых в цикле резервного копирования. Учитывая, что некоторые носители могут быть повреждены, значение tapecycle должно быть несколько больше, чем значение опции runspercycle.

• tapetype. Если вы сообщите о том, какой тип накопителя вы используете, AMANDA сможет определить, как долго будет длиться запись информации. В конфигурационном файле, поставляемом в составе конфигурационного пакета, указано несколько типов накопителей. Если вы не найдете тип, соответствующий вашему устройству, вам придется выяснить эти сведения самостоятельно. Сделать это можно с помощью утилиты tapetype, которая поставляется в составе пакета AMANDA, но по умолчанию не устанавливается. Перейдите в каталог tape-src инсталляционного пакета и задайте команду make tapetype. Затем установите в устройстве ненужную вам ленту и введите ./tapetype -f /dev/ устройство (где под устройством понимается файл, соответствующий накопителю на ленте). В результате выполнения данной команды вы получите набор значений для вашего устройства. Для завершения данной процедуры потребуется несколько часов, и все данные на ленте будут уничтожены. Если в вашем накопителе реализована встроенная функция сжатия данных, вы можете увеличить значение длины ленты в полтора- два раза. При этом соблюдайте осторожность: если вы будете копировать данные, плохо поддающиеся сжатию, места на ленте может не хватить.

• tapedev. Данная опция задает файл устройства Linux, представляющий интерфейс без перемотки к накопителю на ленте. В большинстве случаев в качестве значения этой опции указывается имя /dev/nst0 или /dev/nht0.

• netusage. С помощью этой опции указывается максимальная пропускная способность линий, на которую может рассчитывать AMANDA при выполнении резервного копирования.

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

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

• infofile, logdir и indexdir. Расположение файлов протоколов AMANDA задается с помощью опций infofile и logdir. Кроме того, опция indexdir определяет индексный файл, содержащий список скопированных файлов. Значения этих опций можно оставить без изменения.

Кроме установки значений приведенных выше опций, вам также надо описать область для хранения данных. Для этого используется опция holdingdisk, значение которой занимает несколько строк и состоит из ряда подопций. К ним относятся directory (каталог для хранения файлов) и use (пространство на диске, которое может быть использовано для хранения данных). Если на диске сервера резервного копирования недостаточно места, вы можете задать отрицательное значение chunksize. При этом файл, размер которого превышает абсолютное значение chunksize, непосредственно записывается на ленту, минуя область хранения. (Положительные значения chunksize указывают на то, что большие файлы должны быть разбиты на части для размещения в области хранения. Такой подход удобно применять в тех случаях, когда файловая система на диске или особенности ядра не позволяют обрабатывать большие файлы. Например, при использовании версий ядра 2.2.x на компьютерах x86 максимальный размер файлов составляет 2 Гбайт.)

Подготовка лент

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

$ amlabel Daily DailySet123

Указанный здесь параметр Daily задает подкаталог, в котором размещается конфигурационный файл amanda.conf. В результате amlabel получает доступ к необходимым опциям. Параметр DailySet123 представляет собой метку ленты. Это значение должно соответствовать регулярному выражению, заданному в качестве значения опции labelstr в файле amanda.conf, в противном случае AMANDA не сможет работать с лентой. В большинстве случаев AMANDA копирует данные из сети на несколько лент. Чтобы вы могли различать ленты, вам необходимо разработать схему их именования.

Определение типов резервных копий

В конце файла amanda.conf, поставляемого в составе инсталляционного пакета AMANDA, содержится несколько записей dumptype. Они определяют, как должно выполняться резервное копирование содержимого клиентского компьютера или отдельной файловой системы. В составе записи dumptype могут указываться следующие опции.

• compress [client | server] [best | fast | none]. Вы можете задать тип сжатия, выполняемого клиентом или сервером копирования. Тип сжатия выбирается в зависимости от используемого процессора и сетевых ресурсов. Значение best указывает на то, что необходимо выполнить наиболее эффективное сжатие, для которого требуется большое количество ресурсов процессора. Значение fast задает быстрое, но менее эффективное сжатие. Значение none запрещает сжатие данных.

• exclude [list] " строка " . В зависимости оттого, указано ли значение list, AMANDA включает заданную строку в качестве значения опции --exclude или --exclude-from утилиты tar.

• holdingdisk логическое_значение . Задавая логическое значение yes или no, вы можете указать AMANDA, следует ли использовать область диска для хранения данных.

• index логическое_значение. Задавая логическое значение равным yes или no, вы сообщите AMANDA о том, следует ли создавать перечень файлов, скопированных на резервный носитель. Такой файл может оказать помощь в работе с резервными копиями, но он занимает место на диске, которое можно использовать для других целей.

• kencrypt логическое_значение. Данная опция позволяет указать, следует ли кодировать данные, передаваемые по сети, с помощью протоколов Kerberos. Значение, равное yes, можно указывать только в том случае, когда сеть сконфигурирована для работы с Kerberos. Вопросы использования Kerberos обсуждались в главе 6.

• program " строка " . AMANDA может использовать либо утилиту tar, либо программу dump, ориентированную на работу с конкретной операционной системой. Данная опция позволяет указать, какую из этих программ следует использовать. По умолчанию AMANDA работает с программой dump (значение DUMP данной опции). Чтобы задать использование tar, необходимо, чтобы значение опции было равно GNUTAR. (При работе с Samba по умолчанию применяется утилита tar.)

• skip-incr логическое_значение . Если значение данной опции равно true, то при инкрементном копировании файловая система, для которой указан этот тип резервной копии, не учитывается.

В определении типа резервной копии могут присутствовать и другие опции. Некоторые из них, например dumpcycle, обсуждались в предыдущем разделе. Информацию о других опциях вы найдете в справочной системе. Большинство определений типов резервных копий начинается с имени другого определения. Это означает, что новое определение создано на основе существующего и для него справедливы значения опций базового определения. Например, в конфигурационном файле amanda.conf, поставляемом в составе инсталляционного пакета, присутствует определение с именем global, включаемое в другие определения.

Заметьте, что при выполнении одной операции резервного копирования могут быть созданы копии различных типов. Например, вы можете скопировать важные системные файлы, не используя сжатие, но сжимать при копировании менее важную информацию. Вы также можете использовать утилиту dump для копирования разделов ext2fs, а утилиту tar — для копирования разделов ReiserFS.

Определение данных для копирования

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

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

Листинг 17.2. Пример содержимого файла disklist

# Создание резервной копии сервера резервного копирования

buserver.threeroomco.com / root-tar

buserver.threeroomco.com /var user-tar

buserver.threeroomco.com /hold holding-disk

# Создание резервной копии клиента Linux или UNIX

buclient.threeroomco.com / root-tar

buclient.threeroomco.com /home user-tar

# Создание резервной копии клиента Windows

buserver.threeroomco.com //WINPC/DRIVEC user-tar

Большинство записей в этом примере не нуждается в комментариях. Раздел /hold компьютера buserver.threeroomco.com содержит область для хранения данных.

В определении соответствующего типа резервной копии указано значение по опции holdingdisk, что предотвращает использование этой области для временного хранения своего же содержимого. Если в данном разделе не содержится ничего, кроме области хранения данных, вы можете исключить его из процесса копирования. Для копирования данных клиента Windows указывается имя компьютера Linux или UNIX, на котором установлен и выполняется сервер Samba, а также NetBIOS-имя клиента Windows (WINPC) и имя разделяемого объекта (DRIVEC). В листинге 17.2 в качестве компьютера, на котором установлен продукт Samba, указан сам сервер резервного копирования, но при необходимости вы можете задать имя другого компьютера. (Заметьте, что, установив Samba на сервере резервного копирования, вы уменьшаете нагрузку на сеть.) Чтобы создать резервную копию устройства на компьютере под управлением Windows, его не нужно монтировать; AMANDA обращается к системе Samba для использования smbclient. Samba использует smbclient так же, как обычный клиент резервного копирования утилиту tar или dump. В файловой системе компьютера, на котором выполняется Samba, необходимо создать файл /etc/amandapass. В этом файле следует указать имя разделяемого объекта и пароль. В качестве пользовательского имени AMANDA передает имя SAMBA, поэтому при работе с Windows NT, 2000 или XP этот пользователь должен присутствовать в системе. Для того чтобы изменить имя пользователя, применяемое по умолчанию, вам надо при установке AMANDA задать это имя в качестве значения опции --with-samba-user.

 

Создание резервных копий с помощью AMANDA

Для того чтобы инициировать процесс создания резервной копии с помощью AMANDA, необходимо запустить на сервере резервного копирования программу amdump. Введите имя программы и укажите после нее данные для копирования, т. е. задайте имя каталога, в котором находятся требуемые конфигурационные файлы. Например, команда может выглядеть так: amdump Daily. Очевидно, что перед запуском amdump вам необходимо установить на устройстве ленту, подготовленную так, как было описано выше. В результате выполнения данной команды AMANDA обнаружит области, предназначенные для копирования, обработает их содержимое и запишет на магнитную ленту. Процедура резервного копирования не обязательно будет охватывать все компьютеры в сети и даже все разделы на одном компьютере. В зависимости от значения опции dumpcycle и других опций подобного назначения, указанных в конфигурационном файле, а также от типа устройства резервного копирования, AMANDA может принять решение скопировать данные лишь с нескольких компьютеров или вместо полного копирования выполнить инкрементное копирование. Если продолжительность цикла резервного копирования не слишком мала, в течение этого цикла AMANDA выполнит резервное копирование всех компьютеров в сети.

Занимаясь администрированием сети, вы вряд ли захотите вручную вызывать программу amdump. Лучше всего запускать ее с помощью инструмента cron в то время, когда нагрузка на сеть минимальна, например ночью. Следует убедиться, что в эти часы клиенты резервного копирования доступны. Многие пользователи, уходя с работы, выключают свои компьютеры. Вам придется убедить их не делать этого.

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

 

Восстановление данных

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

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

• Полное восстановление. В этом случае предполагается восстановление всех файлов на диске или по крайней мере тех данных, которые нужны для загрузки компьютера. Необходимость в полном восстановлении может возникнуть при повреждении жесткого диска или содержащихся на нем программ. Так, например, полное восстановление придется производить после того, как от имени пользователя root была выполнена команда rm -r /.

Внимание

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

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

СОВЕТ

Даже если в вашей сети присутствует сервер резервного копирования под управлением Linux и большое число клиентов резервного копирования под управлением Windows 9x/Me, вы можете использовать для восстановления данных минимальную конфигурацию системы Linux. В этой системе должны присутствовать средства Samba, которые вы используете, чтобы запустить сервер SMB/CIFS. Этот сервер необходим для восстановления файлов с сервера резервного копирования Linux. После того как полное восстановление данных окончится, вам необходимо запустить программу FDISK системы DOS, чтобы пометить раздел как загружаемый, а затем с помощью программы SYS записать данные в загрузочный сектор раздела. При работе с Windows NT, 2000 или XP процесс восстановления данных будет более сложным, особенно, если на компьютере используется файловая система NTFS. В этом случае вам надо первоначально установить систему в небольшой загрузочный раздел. Содержимое этого раздела можно сохранять и восстанавливать посредством утилиты dd , работающей в системе Linux, или с помощью одного из коммерческих инструментов, например DriveImage.

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

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

AMANDA отличается от других средств, рассмотренных в данной главе, тем, что в состав этого пакета входят инструменты восстановления данных, предназначенные для выполнения на стороне клиента резервного копирования. Наиболее мощным из этих инструментов является amrecover, который вызывает в процессе работы другие программы, например amrestore. Если вы запустите amrecover на клиенте резервного копирования от имени пользователя root, программа отобразит приглашение для ввода команды. Допустимыми командами являются setdate (определение даты резервной копии), cd (изменение текущего каталога), add (добавление файла к набору, предназначенному для восстановления) и extract (восстановление файлов). После указания команды extract программа amrecover предложит установить соответствующую ленту, содержащую резервную копию.

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

 

Резюме

Существует несколько различных способов создания резервных копий данных. Вы можете выполнять резервное копирование по инициативе клиента или по инициативе сервера, применяя при этом NFS, SMB/CIFS, rshd, AMANDA и другие средства сетевого взаимодействия, а также tar, dump, cpio и другие программы создания архивов. Выбор конкретных средств зависит от особенностей сети. Представляя себе особенности различных способов создания резервных копий, вы сможете принять решение, наиболее приемлемое для вашей сети. Если число компьютеров в сети относительно невелико, для создания резервных копий подойдут простые инструменты наподобие утилиты tar. При работе в больших вам понадобятся сложные инструменты, например AMANDA. Создавая резервные копии, необходимо иметь в виду, что рано или поздно они понадобятся для восстановления данных. Восстановление данных нельзя рассматривать лишь как процесс, обратный резервному копированию. Для эффективного восстановления утерянных данных часто приходится применять дополнительные инструменты.