WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 7 | 8 || 10 | 11 |   ...   | 14 |

«А TV AODISON WESLEY СЕТЕВЫЕ СРЕДСТВА РОДЕРИК В. Смит Сетевые средства Linux Advanced Linux Networking W. Smith A TT ADDISON-WESLEY Boston • San Francisco • New York • Toronto • Montreal ...»

-- [ Страница 9 ] --

В качестве простейшей проверки можно скопировать данные с помощью одной из команд, рассмотренных в предыдущем разделе. Чтобы сделать это, необходимо выяс нить, к какому устройству следует обращаться. Для накопителей среднего и высокого уровня чаще всего используются следующие четыре имени: /dev/nstO, и Первые два имени применяются для обозначения устройств SCSI, а остальные два соответствуют устройствам EIDE/ATAPI. Имена файлов, имена которых начинаются с буквы п, представляют устройства без перемотки (nonrewinding device). По окончании действий с таким устройством лента остается в той позиции, в ко торой записаны последние данные, в результате вы можете размещать несколько копий на одной ленте. Если в начале имени файла буква п отсутствует, это устройство считается устройством с перемоткой (rewinding device). В этом случае по окончании операции записи лента автоматически перематывается. Заметьте, что наличие или отсут ствие перемотки является характеристикой не устройства, а представляющего его файла.

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

Существуют накопители, которым соответствуют файлы устройств с другими имена ми. Например, раньше использовались накопители, подключаемые через порт, предна значенный для работы с гибкими дисками. Работа с ними осуществлялась посредством файлов и Эти накопители отличаются малой емкостью но сителей и низким быстродействием и не отвечают современным требованиям, предъяв ляемым к устройствам резервного копирования. Иногда устройства подключаются через специализированный интерфейс. Драйверы для работы с ними должны быть установлены при настройке Linux.

Если при выполнении копирования данных с локального компьютера у вас возникают проблемы, проверьте используемые аппаратные средства и драйверы устройств. Для рабо ты с устройством SCSI необходимы как базовые средства поддержки SCSI, так и средства для взаимодействия с накопителем SCSI. Соответственно при использовании устройств EIDE/ATAPI необходимо обеспечить поддержку как EIDE, так и накопителя EIDE/ATAPI.

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

Глава 17. Резервное копирование Чтобы убедиться, что информация восстановлена корректно, надо использовать режим верификации.

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

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

ЗАМЕТКУ Архивы, созданные с помощью программы tar, располагаются на ленте после довательно один за другим.

Используя tar и mt, можно разместить на одной ленте несколько резервных копий.

Утилита mt вызывается следующим образом:

mt устройство] операция [счетчик] Под операцией подразумевается одна из следующих команд: (forward space files — переход к следующему файлу), bsf (backward space files — переход к предыдущему фай лу), rewind (перемотка ленты) и (установка режима сжатия;

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

# tar /dev/nstO # tar cvplf /dev/nstO # mt -f /dev/nstO rewind tar df /dev/nstO testdir-1/ # mt -f /dev/nstO fsf # tar df /dev/nstO testdir-2/ Большинство из этих команд предполагает выполнение некоторых действий с лен той. Первые два вызова утилиты tar сопровождаются отображением имен копируемых файлов, а в результате последующих двух вызовов выводятся имена файлов, в которых обнаружено расхождение между исходными данными и данными, записанными на ленту.

Второй вызов утилиты mt нужен при чтении архива. При создании резервных копий в этой команде нет необходимости.

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

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

400 Часть И. Серверы в локальных сетях Настройка сервера для резервного копирования по инициативе клиента Опция описанная в табл. 17.2, позволяет указать программе tar файл архива.

Это может быть обычный файл на диске, файл устройства, представляющий накопитель на магнитных лентах, и путь к сетевому ресурсу. В последнем Случае на выступающем в роли сервера резервного копирования, должен выполняться демон rshd (часто он называется rshd). Этот демон позволяет удаленной системе выполнять команды на локальной машине. Благодаря наличию программы rshd утилита tar полу чает возможность передать созданный ею файл на устройство, подключенное к серверу резервного копирования. Сервер rshd поставляется с большинством версией системы Linux и обычно запускается посредством суперсервера. Соответствующая запись в файле conf имеет следующий вид:

shell stream tcp nowait root \ -h Если в вашей системе используется сервер xinetd, вам необходимо создать запись аналогичного назначения в файле или создать отдельный файл и включить его в каталог При выполнении резервного копирования чрезвычайно важны меры по ограничению доступа, предпринимаемые посредством TCP Wrappers или непосредственно предусмотренные в xinetd. Решение о предоставле нии доступа через rshd принимается на основе анализа IP-адреса. Хотя TCP Wrappers и xinetd используют тот же механизм контроля за обращениями клиентов, избыточные средства обеспечения безопасности пригодятся на тот случай, если в программе rshd будут обнаружены ошибки, позволяющие обойти механизмы защиты.

Несмотря на то что основные меры защиты rshd базируются на использовании ин формации об IP-адресе, данная программа также проверяет имена пользователей. Это делается для того, чтобы предотвратить попытки запуска программ, которые могут нане сти вред системе. В обычных условиях rshd не обрабатывает команды, полученные от пользователя root, независимо от того, на каком компьютере он работает. Это правило можно отменить путем указания опции -h, как это было сделано в рассмотренном выше примере записи в файле Данная опция чрезвычайно важна, так как для вы полнения резервного копирования приходится иметь дело с системными файлами, а для работы с ними необходимы максимальные привилегии. Если вы не укажете опцию -h, то обычные пользователи смогут выполнять резервное копирование только в том случае, если права доступа к файлу устройства на сервере позволят им сделать это. (В большин стве дистрибутивных пакетов обычным пользователям запрещен доступ к накопителям на магнитных лентах.) ВНИМАНИЕ В некоторых системах опция -h программы rshd не обрабатывается. В этом | случае приходится создавать резервные копии по-другому. Необходимо запу стить на сервере резервного копирования сервер SSH и на стороне клиента связать с именем rsh. При этом утилита tar для передачи данных по сети будет обращаться к программе ssh. Такой подход обеспечивает дополнительную степень защиты, и ему имеет смысл следовать даже в тех случаях, когда опция -h обрабатывается так, как указано в документации. Сервер SSH необходимо сконфигурировать таким образом, чтобы он при выполнении аутентификации не запрашивал пароль.

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

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

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

# tar /home /var / В результате выполнения данной команды содержимое каталогов /home, /var и / локального компьютера будет передано на устройство записи на магнитную ленту, рас положенное на компьютере buserver. Если в подкаталогах указанных каталогов смон тированы другие файловые системы, они исключаются из процесса копирования. Если содержимое компьютера исчерпывается тремя указанными выше каталогами, в результате выполнения данной команды осуществляется полное резервное копирование.

Для управления накопителем, подключенным к серверу резервного копирования, мо жет использоваться утилита mt. Например, по команде mt /dev/nstO rewind осуществляется перемотка ленты.

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

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

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

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

402 Часть II. Серверы в локальных сетях Установка конфигурации сети для резервного копирования, инициируемого сервером Вопросы настройки компьютера под управлением Linux для экспортирования файло вых систем рассматривались в главе 8. Чтобы скопировать на резервный носитель всю информацию, содержащуюся на компьютере, надо сконфигурировать систему так, что бы на сервере резервного копирования можно было смонтировать все файловые системы.

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

Для создания резервной копии достаточно смонтировать каталоги лишь для чтения;

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

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

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

/home /var / Для восстановления файлов следует вместо указать rw и перезагрузить сервер NFS. При восстановлении данных необходимо также обеспечить сохранность информа ции о принадлежности файлов владельцам. Если некоторый файл принадлежит, например, пользователю brown, но соответствие имени и числового идентификатора установить не удается, то данные о владельце восстановленного файла могут быть искажены. Чтобы Глава 17. Резервное копирование исключить подобный эффект, надо обеспечить, чтобы на сервере и на клиенте резерв ного копирования содержались учетные записи одних и тех же и чтобы совпадали их числовые идентификаторы.

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

# mount -t nfs -о soft buclient:/ /mnt/client # mount -t nfs soft # mount -t nfs -o soft # cd /mnt/client # tar /dev/stO home var./ При составлении приведенного выше набора команд предполагалось, что сер вер NFS на компьютере, выполняющем роль клиента резервного копирования, не обеспечивает автоматическое монтирование экспортируемых подкаталогов.

Если автоматическое монтирование подкаталогов поддерживается, достаточно первой из перечисленных команд mount.

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

полный путь к файлу не записывается.

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

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

# tar cvlf /dev/stO /mnt/client/home /mnt/client/var /mnt/client В данной команде явно указан каталог /mnt/client. (Если вы не зададите моди фикатор при создании архива первый символ / будет удален и со хранится лишь имя mnt/client.) В этом случае при восстановлении файлов каталоги необходимо монтировать либо в той же точке, в которой они монтировались при созда нии резервной копии, либо в каталоге, путь к которому оканчивается на mnt/client.

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

ВНИМАНИЕ Недостаток описанного способа резервного копирования состоит в том, что ес ли клиент прекратит обмен по сети, процесс сохранения данных остановится на неопределенное время. В приведенном выше примере при монтировании ука зывалась опция -о Она позволяет клиенту NFS на сервере резервного копирования передавать программе tar сведения об ошибках, предотвращая тем самым "зависание" процедуры копирования данных.

404 Часть II. Серверы в локальных сетях Использование SMB/CIFS В предыдущем разделе рассматривалось использование утилиты tar совместно с про граммой rshd, выполняющейся на сервере резервного копирования, либо с сервером NFS, который выполняется на компьютере, выступающем в роли клиента резервного копирования. Для обеспечения взаимодействия компьютеров можно также использовать и другие серверы. В данном разделе рассматриваются вопросы выполнения резервного копирования с применением сервера SMB/CIFS. Такой способ создания резервных копий удобно использовать при работе в сетях, содержащих большое количество компьютеров под управлением Windows. В главе 7 описывался продукт Samba, с помощью которого можно организовать взаимодействие Windows и Linux по протоколу SMB/CIFS.

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

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

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

В составе системы Windows поставляются программы поддержки сервера SMB/CIFS, однако по умолчанию эти программные средства не установлены. Для включения необ ходимых программных компонентов необходимо использовать элемент в составе Control Panel, который в зависимости от версии системы называется Network или Network and Dial-Up Connections. Работая с системой Windows следует дважды щелкнуть на пиктограмме Network, в результате чего отобразится диалоговое окно Network. В системе Windows NT или 2000 необходимо щелкнуть правой кнопкой мыши на соответствующем объекте в Network and Connections и выбрать пункт Properties. Необходимый вам компонент называется File and Printer Sharing for Microsoft Networks. Если данный компонент отсутствует, щелкните на Add или Install. Перечень сетевых служб, среди ко торых присутствует File and Printer Sharing for Microsoft Networks, показан на рис.

Возможно, вам потребуется задать принадлежность системы к рабочей группе. Сделать Глава 17. Резервное копирование to ftencfck and SAP Agent Cancel Рис. 17.1. Чтобы система Windows функциониро вала как сервер в ней должен быть установлен компонент File and Printer Sharing for Microsoft Networks это можно с помощью вкладки Identification диалогового окна Network (Windows или объекта System в составе Control Panel (Windows 2000).

Инсталлировав сервер SMB/CIFS, вам надо организовать разделение дисков, содер жимое которых вы хотите записывать на резервный носитель. Для этого выполните сле дующие действия.

1. В окне My Computer щелкните правой кнопкой мыши на устройстве, доступ к ко торому вы хотите разрешить, и в появившемся контекстном меню выберите пункт Sharing. (Если этот пункт отсутствует, то, вероятнее всего, программное обеспече нием сервера SMB/CIFS не установлено.) В результате вы увидите диалоговое окно Properties, подобное изображенному на рис.

2. Чтобы разрешить доступ к устройству, щелкните на опции Shared As или Share This Folder. При этом вам потребуется ввести имя разделяемого объекта, которое вы бу дете использовать при монтировании на сервере резервного копирования. В данном случае роль сервера резервного копирования выполняет компьютер под управлени ем Linux. (В системе Windows 2000 для ввода имени разделяемого объекта надо щелкнуть на New Share.) 3. При работе с Windows необходимо с помощью опции Access Type разрешить чтение и запись или только чтение и ввести пароль. Для создания резервных копий достаточно, чтобы данные были доступны только для чтения, но для восстановления данных необходимо также разрешить запись информации (в Windows чтобы предоставить право чтения и записи, надо установить значение Full опции Access Туре). В Windows 2000 с помощью вкладки Security можно определить, кто имеет право доступа к разделяемому объекту.

4. Щелкните на кнопке ОК, разрешив тем самым совместное использование устрой ства.

406 Часть II. Серверы в локальных сетях < Took j j Quota | can share this folder among other users on Г Share | C$ ML ft Users To for how users over the configure for this stood Caching.

Cancel Рис. 17.2. Диалоговое окно Sharing си стемы Windows 2000. Аналогичное окно системы Windows содержит другой набор опций 5. Повторите пп. для каждого устройства, содержимое которого необходимо запи сать на резервный носитель.

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

На компьютере под управлением Linux для этой цели можно использовать инструмент Использование smbtar В составе пакета Samba поставляется программа smbtar. Как нетрудно догадать ся, этот инструмент сочетает в себе возможности утилиты tar и клиента SMB/CIFS.

На самом деле smbtar представляет собой сценарий оболочки, который вызывает про граммы tar и smbclient, используя предоставляемые ими возможности для создания резервных копий данных, которые содержатся на компьютерах под управлением Win dows. Инструмент smbtar можно использовать как для создания резервной копии всего разделяемого объекта, так и для копирования отдельных файлов. Сценарий smbtar вы зывается с помощью следующего выражения:

smbtar -s \ [-х \ пароль] [-t устройство] [-v] Обратившись к справочной вы получите подробную информацию об исполь зовании smbtar. Ниже описано назначение основных опций.

Глава 17. Резервное копирование • s Эта единственная обязательная опция задает имя клиента резервного копирования. В качестве ее значения указывает ся NetBIOS-имя компьютера. В зависимости от значения опции name resolve order в файле система также может обрабатывать DNS-имена узлов сети.

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

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

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

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

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

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

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

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

# smbtar -s WORK -p password CDRIVE -t /dev/stO -v При выполнении данной команды сначала выводится информация о состоянии систе мы, затем список файлов, а после этого — сведения о числе файлов и объеме сохраненных данных в байтах. Форматы файлов, созданных с помощью smbtar и tar, совпадают, поэтому при необходимости вы можете просмотреть содержимое архива посредством утилиты tar.

408 Часть II. Серверы в локальных сетях Использование smbmount Вместо того чтобы работать с инструментом вы можете воспользоваться предоставляемой Linux возможностью монтировать разделяемые объекты SMB/CIFS. Для монтирования подобных объектов можно применять утилиту mount smbmount. При использовании программы mount надо указать тип файловой системы s, задать NetBIOS-имя компьютера под управлением Windows, имя разделяемого объекта и имя пользователя. Сформированная таким образом команда имеет следующий вид:

# mount -t -о \ Эквивалентная ей команда smbmount выглядит так:

# smbmount -о \ Реализации утилиты smbmount в пакетах 2.0.x Samba существенно ся одна от другой. В ранних версиях данной программы использовался другой ЗАМЕТКУ синтаксис. Приведенный выше вызов корректен для программ smbmount, по ставляемых в составе версий Samba.

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

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

# umount /mnt/backup Особенности обработки имен файлов Windows Для создания резервных копий содержимого системы Windows часто используются компьютеры под управлением Linux. Однако при этом необходимо учитывать особенно сти обработки имен файлов. Дело в том, что программы mount и smbmount интерпре тируют имена файлов иначе, чем это происходит в системе Windows. Для того чтобы понять эти различия, необходимо рассмотреть правила хранения файлов в Windows. Фай ловая система FAT (File Allocation Table — таблица размещения файлов), используемая в Windows и поддерживаемая в системах Windows NT, 2000 и ХР, ориентирована на работу с файлами, имена которых содержат восемь символов, а расширение — три символа. Такие имена файлов называются именами 8.3. Для хранения длинных имен файлов в каталогах Windows предусмотрены дополнительные записи. Длинными счита ются имена файлов, содержащие больше восьми символов имени и больше трех симво лов расширения, либо имена, составленные из символов, регистр которых должен быть сохранен. (Имена 8.3, в зависимости от используемых программ, могут отображаться символами верхнего регистра либо представляться как имя, начинающееся с прописной буквы, например txt. Существует также возможность указать, что имя 8.3 долж Глава 17. Резервное копирование но представляться символами только верхнего или только нижнего регистра.) Проблема с обработкой имен файлов в Linux возникает из-за того, что в данной системе не поддер живаются имена 8.3, а используются только длинные имена файлов.

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

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

Существенные трудности возникают при создании имен 8.3, которые должны соответ ствовать длинным именам. В системе Windows эта задача решается автоматически;

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

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

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

• Используйте длинные имена в составе конфигурационных файлов. Если вам необходимо включить в конфигурационный файл имя каталога, задавайте длинное имя. Например, если вы хотите задать каталог в качестве значения переменной 410 Часть II. Серверы в локальных сетях PATH в файле BAT, используйте его полное имя. Этим вы достигнете того, что при внесении изменений в имена файлов 8.3 функционирование системы не изменится.

• Создавайте длинные имена файлов, различающиеся первыми шестью симво лами. При создании имени 8.3 Windows оставляет первые шесть символов низ менными, затем присоединяет к ним символ и порядковый номер, начинающий ся с единицы. Например, имя может быть преобразовано в имя 8.3 LONGFI~1 Если все длинные имена файлов в каталоге будут раз личаться первыми шестью символами, при преобразовании в формат 8.3 все они будут оканчиваться последовательностью ~1, в результате вероятность некоррект ного восстановления имени файла уменьшится.

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

Файловая система NTFS (New Technology Filesystem — новая технология фай ловой системы), используемая в Windows NT, 2000 и ХР, также поддерживает и имена 8.3, и длинные имена файлов. Однако вероятность возникновения про блем с преобразованием имен гораздо меньше, чем в тех системах, в которых используется FAT.

Разделяемые объекты резервного копирования Один из способов создания резервных копий с применением Samba состоит в исполь зовании разделяемых объектов резервного копирования. Разделяемый объект резервного копирования предоставляет собой объект Samba, связанный с устройством резервного копирования. Существует несколько подходов к работе с данными объектами, и все они могут рассматриваться как резервное копирование, инициируемое клиентом.

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

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

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

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

Создание разделяемых объектов резервного копирования Разделяемые объекты резервного копирования создаются так же, как и другие типы разделяемых объектов Samba. Различие состоит лишь в том, что вы, вероятнее всего, за хотите использовать сценарии для автоматического монтирования устройства при первом обращении к нему и его по завершении процедуры создания резервной копии. Кроме того, в определении объекта резервного копирования обычно присутству ет параметр max connections, ограничивающий число пользователей, которые имеют возможность одновременно работать с данным объектом. Ниже приведено определение объекта резервного копирования, который позволяет удаленным пользователям записы вать резервные копии данных на устройство Zip, смонтированное в позиции файловой системы comment = Zip Backups path = /mnt/zip read = No max connections preexec = /bin/mount /mnt/zip postexec = /mnt/zip Поскольку многие клиенты в том числе средства, реализованные в системе Windows, не размонтируют разделяемый объект, вам, возможно, при дется использовать глобальный параметр который указывает на то, что после определенного периода бездействия соединение должно быть разо рвано. Для устройства резервного копирования желательно задать параметр deadtime = 5. Значение этого параметра сообщает, что соединение будет разорвано через пять минут после прекращения активности.

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

На сменных носителях может использоваться любая файловая система, поддерживае мая Linux. Однако, если эти носители должны читаться в других системах, вам, возможно, придется отказаться от применения некоторых форматов. Например, если пользователям необходимо читать данные, записанные на сменном диске в системе Windows, очевид но, что на нем должна быть сформирована файловая система FAT. Если же диски будут устанавливаться только на устройствах, подключенных к компьютеру под управлением Linux, то на нем может присутствовать FAT, ext2fs или любая другая файловая система, с которой может работать Linux.

412 Часть И. Серверы в локальных сетях Совместное использование некоторых носителей обеспечить достаточно сложно. Для работы с ними необходимо создать разделяемый объект, который предпринимал бы спе циальные меры по данных на носитель. В главе 7 были приведены два примера разделяемых объектов, которые записывали информацию на компакт-диск. Модифициро ванный вариант разделяемого объекта, описанного в главе 7, представлен ниже.

[backup] path printable = Yes print command = %H %s %U \ /var/spool/samba;

rm %s Данный объект определяет псевдопринтер, который получает от клиента резервного копирования zip-файлы. Для извлечения содержимого zip-файла и копирования его на лен ту с помощью этот объект использует сценарий /usr/local/bin/samba-backup, код которого приведен в листинге В результате получается копия данных на ленте, аналогичная той, которая создается с помощью программы Модифицировав сце нарий или изменив параметр print command, вы можете организовать непосредствен ную запись zip-файла на ленту. Это позволит предотвратить потерю признаков скрытых и системных файлов при извлечении содержимого zip-файла в системе Linux.

Листинг 17.1. Сценарий, поддерживающий работу разделяемого объекта резервного ко пирования, реализованного в виде псевдопринтера _ # $1 Рабочий каталог пользователя, который передал # задание на обработку # $2 = Имя zip-файла $3 = Имя пользователя, который передал задание на обработку # $4 Путь к -p cd unzip $4/$ tar cvpf /dev/stO./ > mail -s "Backup finished" $3 < rm rm -r ВНИМАНИЕ Описанный здесь подход предполагает, что файл устройства резервного копи | доступен всем пользователям. Существуют, однако, способы обойти это требование. Например, вы можете использовать для всех соединений учет ную запись root. Также можно включить в определение разделяемого объекта в файле параметр force user, который устанавливал бы иденти фикатор пользователя, по инициативе которого выполняется команда "печати".

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

в этом случае вам потребуется параметр group.

Глава 17. Резервное копирование Данный подход может быть использован для обработки файлов, отличных от zip фалов. Например, если система получает tar-файлы, то их можно непосредственно ско пировать на ленту. В этом случае отпадает необходимость в извлечении файлов (чему посвящена основная часть сценария в листинге 17.1). Такой подход обеспечивает более высокую скорость обработки данных, но менее удобен при работе с клиентами Win dows, поскольку формат tar в основном используется в системе Linux, а в Windows он применяется крайне редко.

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

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

Использование AMANDA В предыдущих разделах данной главы рассматривались основные способы создания резервных копий и конфигурация компьютеров, необходимая для реализации этих спо собов. Если в вашей сети содержится относительно небольшое число компьютеров, вы, возможно, станете создавать резервные копии вручную либо напишете сценарий для авто матизации выполнения данной задачи. Если же число узлов в сети велико, вам понадобят ся более сложные инструменты. Одним из таких инструментов является AMANDA (Ad vanced Maryland Automatic Network Disk Archiver). Данный пакет объединяет различные инструменты, предназначенные для выполнения резервного копирования в сети, и ориен тирован в основном на работу в сетях небольшого и среднего размера, но может приме няться и в больших сетях. Программное обеспечение AMANDA поставляется в составе версий Linux Debian, Red Hat, Mandrake и SuSE. Если же требуемые программы отсутству ют, вы можете скопировать их с Web-страницы AMANDA org).

414 Часть II. Серверы в локальных сетях ВНИМАНИЕ В исполняемых файлах AMANDA закодированы некоторые значения, исполь | при работе данного инструмента, поэтому если вы попытаетесь объ единить компоненты AMANDA, предназначенные для выполнения в различных системах, то они, вероятнее всего, работать не будут. Если в вашей операцион ной среде установлено большое количество различных пакетов, рекомендуется самостоятельно построить создать AMANDA из исходных кодов. Убедитесь, что во всех системах посредством опций и заданы один и тот же пользователь и группа. Возможно, вы захотите создать учетную запись и группу, специально предназначенные для выполнения различных опе раций с помощью AMANDA.

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

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

NFS, rshd и другие подобные протоколы при работе AMANDA не используются. (При выполнении резервного копирования данных, расположенных на компьютерах под управ лением Windows, AMANDA использует программу и стандартный сервер SMB/CIFS.) AMANDA не только поддерживает сетевые соединения, но и выступает в роли ин струмента планирования. Эта возможность помогает осуществлять резервное копирова ние, а для сети большого размера планирование является частью работ по администрированию систем. Так, например, вы вряд ли собираетесь при каждой опе рации резервного копирования создавать копию каждого файла на каждом компьютере.

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

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

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

Данная программа, предназначенная для работы в системах Linux и UNIX, поставляется в составе пакета AMANDA и называется Эта программа-сервер обычно запус кается с помощью суперсервера. Соответствующая запись в конфигурационном файле conf имеет следующий вид:

wait amanda amandad amandad Данная запись запускает сервер amandad от имени пользователя amanda. Учетная запись, соответствующая этому пользователю, должна присутствовать в системе. При необходимости вы можете изменить данную запись в соответствии с особенностями си стемы, например, вам, возможно, придется указать полный путь к исполняемому файлу amandad. Если в вашей системе используется суперсервер xinetd, вы должны бу дете создать запись в его конфигурационном файле. Формат конфигурационного файла xinetd рассматривался в главе 4.

В документации на пакет AMANDA описывается использование учетной записи НА и группы, специально предназначенных для выполнения резервного копирова ния, но такой подход часто не дает результатов. Чтобы сервер amandad работал, его следует запустить от имени пользователя root.

Для запуска сервера AMANDA с помощью суперсервера в файл /etc/services необходимо включить специальную запись. Она может выглядеть следующим образом:

amanda После того как вы создали записи в конфигурационном файле суперсервера и в файле вам следует перезагрузить суперсервер. В результате клиент резервно го копирования AMANDA станет доступен для сервера резервного копирования. Осталь ные действия по настройке выполняются на компьютере, выступающем в роли сервера резервного копирования.

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

Для этого на сервере обычно устанавливается программное обеспечение клиента резервного копирования.

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

amanda Как было замечено ранее, для создания резервных копий данных, расположенных на компьютере под управлением Windows, AMANDA использует сервер SMB/CIFS. На 416 Часть И. Серверы в локальных сетях стройка клиентов Windows резервного копирования для взаимодействия по протоколу SMB/CIFS рассматривалась выше в данной главе.

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

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

stream tcp nowait amanda amindexd amidxtape stream tcp nowait amanda amidxtaped amidxtaped Как и для программ, выполняющихся на клиенте резервного копирования, вам, воз можно, придется указать полный путь к исполняемым файлам. Если же в вашей системе используется xinetd, вам надо создать в конфигурационном файле записи по соглаше ниям, описанным в главе 4. Чтобы указанные программы могли запускаться посредством суперсервера, надо включить в файл /etc/services следующие строки:

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

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

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

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

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

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

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

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

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

• runspercycle. AMANDA может запускаться каждый день, несколько раз в день или один раз в несколько дней. Периодичность запусков задается с помощью данной опции. Предположим, что цикл резервного копирования, указанный посредством опции dumpcycle, составляет четыре недели. Установив значение runspercycle, равное 20, вы сообщаете, что данные для копирования должны выбираться исходя из того, что AMANDA будет запускаться один раз в день в рабочие дни. Значение 4 говорит о том, что AMANDA будет запускаться один раз в неделю. (Заметьте, что реальный запуск AMANDA осуществляется с помощью инструмента Значение опции runspercycle не влияет на периодичность запуска, оно лишь позволяет AMANDA планировать, какие данные должны быть скопированы на ре зервный носитель.) • tapecycle. Значение данной опции определяет число магнитных лент, использу емых в цикле резервного копирования. Учитывая, что некоторые носители могут быть повреждены, значение tapecycle должно быть несколько больше, чем зна чение опции runspercycle.

• tapetype. Если вы сообщите о том, какой тип накопителя вы используете, AMAN DA сможет определить, как долго будет длиться запись информации. В конфи гурационном файле, поставляемом в составе конфигурационного пакета, указано несколько типов накопителей. Если вы не найдете тип, соответствующий вашему устройству, вам придется выяснить эти сведения самостоятельно. Сделать это мож но с помощью утилиты tapetype, которая поставляется в составе пакета DA, но по умолчанию не устанавливается. Перейдите в каталог tape-src инстал ляционного пакета и задайте команду make tapetype. Затем установите в устрой стве ненужную вам ленту и введите (где 418 Часть II. Серверы в локальных сетях под устройством понимается файл, соответствующий накопителю на ленте). В ре зультате выполнения данной команды вы получите набор значений для вашего устройства. Для завершения данной процедуры потребуется несколько часов, и все данные на ленте будут уничтожены. Если в вашем накопителе реализована встроен ная функция сжатия данных, вы можете увеличить значение длины ленты в полтора два раза. При этом соблюдайте осторожность: если вы будете копировать данные, плохо поддающиеся сжатию, места на ленте может не хватить.

• tapedev. Данная опция задает файл устройства Linux, представляющий интерфейс без перемотки к накопителю на ленте. В большинстве случаев в качестве значения этой опции указывается имя /dev/nstO или • netusage. С помощью этой опции указывается максимальная пропускная способ ность линий, на которую может рассчитывать AMANDA при выполнении резерв ного копирования.

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

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

• infofile, logdir и indexdir. Расположение файлов протоколов AMANDA задается с помощью опций и logdir. Кроме того, опция indexdir определяет индексный файл, содержащий список скопированных файлов. Значения этих опций можно оставить без изменения.

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

Такой подход удобно применять в тех случаях, когда файловая система на диске или осо бенности ядра не позволяют обрабатывать большие файлы. Например, при использовании версий ядра 2.2.x на компьютерах х86 максимальный размер файлов составляет 2 Гбайт.) Подготовка лент Для работы AMANDA необходимо, чтобы лента была подготовлена к использова нию. Подготовка осуществляется с помощью утилиты Эта утилита должна запускаться от имени пользователя, который выполняет резервное копирование. Вызов amlabel выглядит следующим образом:

Глава 17. Резервное копирование $ amlabel Daily DailySetl Указанный здесь параметр Daily задает подкаталог, в котором размещается конфи гурационный файл В результате amlabel получает доступ к необходи мым опциям. Параметр DailySetl23 представляет собой метку ленты. Это значение должно соответствовать регулярному выражению, заданному в качестве значения опции labelstr в файле в противном случае AMANDA не сможет работать с лентой. В большинстве случаев AMANDA копирует данные из сети на несколько лент.

Чтобы вы могли различать ленты, вам необходимо разработать схему их именования.

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

• compress [client | server] [best | fast | none Вы можете задать тип сжатия, выполняемого клиентом или сервером копирования. Тип сжатия выби рается в зависимости от используемого процессора и сетевых ресурсов. Значение best указывает на то, что необходимо выполнить наиболее эффективное сжатие, для которого требуется большое количество ресурсов процессора. Значение задает быстрое, но менее эффективное сжатие. Значение попе запрещает сжатие данных.

• exclude [list] "строка", В зависимости оттого, значение list, AMANDA включает заданную строку в качестве значения опции или утилиты tar.

• holdingdisk Задавая логическое значение yes или по, вы можете указать AMANDA, следует ли использовать область диска для хра нения данных.

• index Задавая логическое значение равным yes или по, вы сообщите AMANDA о том, следует ли создавать перечень файлов, ско пированных на резервный носитель. Такой файл может оказать помощь в работе с резервными копиями, но он занимает место на диске, которое можно использовать для других целей.

• Данная опция позволяет указать, следует ли кодировать данные, передаваемые по сети, с помощью протоколов Kerberos.

Значение, равное yes, можно указывать только в том случае, когда сеть сконфи гурирована для работы с Kerberos. Вопросы использования Kerberos обсуждались в главе 6.

• program AMANDA может использовать либо утилиту tar, либо про грамму dump, ориентированную на работу с конкретной операционной системой.

Данная опция позволяет указать, какую из этих программ следует использовать. По умолчанию AMANDA работает с программой dump (значение DUMP данной опции).

Чтобы задать использование tar, необходимо, чтобы значение опции было равно GNUTAR. (При работе с Samba по умолчанию применяется утилита tar.) 420 Часть II. Серверы в локальных сетях • Если значение данной опции равно true, то при копировании файловая система, для которой указан этот тип резервной копии, не учитывается.

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

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

Вы также можете использовать утилиту dump для копирования разделов ext2fs, а утилиту tar — для копирования разделов ReiserFS.

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

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

Листинг 17.2. Пример содержимого файла disklist Создание резервной копии сервера резервного копирования / root-tar /var user-tar /hold holding-disk # Создание резервной копии клиента Linux или UNIX / root-tar /home user-tar # Создание резервной копии клиента Windows user-tar Глава 17. Резервное Большинство записей в этом примере не нуждается в комментариях. Раздел /hold компьютера содержит область для хранения данных.

В определении соответствующего типа резервной копии указано значение по опции что предотвращает использование этой области для временного хране ния своего же содержимого. Если в данном разделе не содержится ничего, кроме области хранения данных, вы можете исключить его из процесса копирования. Для копирова ния данных клиента Windows указывается имя компьютера Linux или UNIX, на котором установлен и выполняется сервер Samba, а также NetBIOS-имя клиента Windows и имя разделяемого объекта В листинге в качестве компьютера, на котором установлен продукт Samba, указан сам сервер резервного копирования, но при необхо димости вы можете задать имя другого компьютера. (Заметьте, что, установив Samba на сервере резервного копирования, вы уменьшаете нагрузку на сеть.) Чтобы создать резервную копию устройства на компьютере под управлением Windows, не нужно монтировать;

AMANDA обращается к системе Samba для использования Samba использует smbclient так же, как обычный клиент резервного копирования ути литу tar или dump. В файловой системе компьютера, на котором выполняется Samba, необходимо создать файл В этом файле следует указать имя раз деляемого объекта и пароль. В качестве пользовательского имени AMANDA передает имя SAMBA, поэтому при работе с Windows NT, 2000 или ХР этот пользователь должен присутствовать в системе. Для того чтобы изменить имя пользователя, применяемое по умолчанию, вам надо при установке AMANDA задать это имя в качестве значения опции Создание резервных копий с помощью AMANDA Для того чтобы инициировать процесс создания резервной копии с помощью AMAN DA, необходимо запустить на сервере резервного копирования программу amdump. Вве дите имя программы и укажите после нее данные для копирования, т. е. задайте имя каталога, в котором находятся требуемые конфигурационные файлы. Например, команда может выглядеть так: amdump Daily. Очевидно, что перед запуском amdump вам необ ходимо установить на устройстве ленту, подготовленную так, как было описано выше.

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

Занимаясь администрированием сети, вы вряд ли захотите вручную вызывать про грамму amdump. Лучше всего запускать ее с помощью инструмента в то время, когда нагрузка на сеть минимальна, например ночью. Следует убедиться, что в эти ча сы клиенты резервного копирования доступны. Многие пользователи, уходя с работы, выключают свои компьютеры. Вам придется убедить их не делать этого.

422 Часть II. Серверы в локальных сетях По завершении резервного копирования AMANDA посылает по почте отчет о вы полненных действиях. Адрес пользователя, которому должно быть передано сообщение, указывается в качестве значения опции mailto, расположенной в файле Изучив этот отчет, вы получите сведения о том, успешно ли завершилось копирование или при его выполнении возникли ошибки. Так, например, некоторые компьютеры могли оказаться не доступными, а емкость ленты — меньше ожидаемой.

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

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

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

• Полное восстановление. В этом случае предполагается восстановление всех фай лов на диске или по крайней мере тех данных, которые нужны для загрузки компью тера. Необходимость в полном восстановлении может возникнуть при повреждении жесткого диска или содержащихся на нем программ. Так, например, полное восста новление придется производить после того, как от имени пользователя root была выполнена команда -r ВНИМАНИЕ Полное восстановление может понадобиться для того, чтобы воспроизвести со стояние системы, которое было до вмешательства злоумышленника в ее работу.

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

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

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

Этот сервер необходим для восстановления файлов с сервера резервного копи рования Linux. После того как полное восстановление данных окончится, вам необходимо запустить программу системы чтобы пометить раздел как загружаемый, а затем с помощью программы SYS записать данные в за грузочный сектор раздела. При работе с Windows NT, 2000 или ХР процесс восстановления данных будет более сложным, особенно, если на компьютере используется файловая система NTFS. В этом случае вам надо первоначально установить систему в небольшой загрузочный раздел. Содержимое этого раздела можно сохранять и восстанавливать посредством утилиты dd, работающей в си стеме Linux, или с помощью одного из коммерческих инструментов, например В некоторых случаях целесообразно использовать способ полного восстановления данных, отличный от того, который применялся для создания резервной копии. Напри мер, если резервная копия создавалась по инициативе клиента с использованием раз деляемого объекта резервного копирования, восстановление проще осуществить путем непосредственного извлечения содержимого tar-архива с помощью rshd или по инициа тиве сервера с NFS или Samba.

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

Эта система используется для восстановления остальных данных, причем в этом случае можно ограничиться частичным восстановлением.

AMANDA отличается от других средств, рассмотренных в данной главе, тем, что в состав этого пакета входят инструменты восстановления данных, предназначенные для выполнения на стороне клиента резервного копирования. Наиболее мощным из этих инструментов является amrecover, который вызывает в процессе работы другие про граммы, например amrestore. Если вы запустите amrecover на клиенте резервного копирования от имени пользователя root, программа отобразит приглашение для вво да команды. Допустимыми командами являются setdate (определение даты резервной копии), cd (изменение текущего каталога), add (добавление файла к набору, предназна ченному для восстановления) и extract (восстановление файлов). После указания ко манды extract программа amrecover предложит установить соответствующую ленту, содержащую резервную копию.

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

Резюме Существует несколько различных способов создания резервных копий данных. Вы можете выполнять резервное копирование по инициативе клиента или по инициативе сервера, применяя при этом NFS, rshd, AMANDA и другие средства сете вого взаимодействия, а также tar, dump, cpio и другие программы создания архивов.

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

ЧАСТЬ III Серверы Internet Глава Администрирование домена Для того чтобы компьютеры, подключенные к сети TCP/IP, могли обращаться друг у другу по имени, они должны иметь возможность преобразовывать доменные имена в IP адреса, а также выполнять обратное преобразование. Существуют различные средства, позволяющие осуществлять подобные преобразования. Наиболее часто для этой цели используется DNS-сервер (Domain Name System — система доменных имен), который часто называют сервером имен. В главе 2 рассматривались вопросы настройки компьютера для взаимодействия с сервером Однако, для того, чтобы такое взаимодействие было возможным, сервер DNS должен присутствовать в сети. Следует заметить, что работа всей Internet базируется на использовании иерархии серверов DNS. Установив сервер DNS в локальной сети, вы не только обеспечите преобразование имен в ее пределах, но также предоставите возможность внешним пользователям обращаться к компьютерам вашей сети по именам.

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

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

Если же потребуется установить более сложную конфигурацию, вам придется обратиться к документации на сервер DNS либо к изданиям, специально посвященным данному во просу. В качестве примеров можно привести книгу (Albitz) и Лиу (Liu) DNS and BIND, 4th Edition (O'Reilly, 2001) и книгу Ханга (Hunt) Linux DNS Server Administration (Sybex, 2000).

Глава 18. Администрирование домена Использование сервера DNS Администрирование сервера DNS — нетривиальная задача, для выполнения которой администратор должен обладать определенной квалификацией. Чтобы грамотно настро ить сервер, необходимо знать принципы его работы.

Сервер DNS, доступный из внешней сети Работа сети Internet базируется на использовании взаимодействующих между собой серверов DNS. Чтобы понять, как сервер, установленный в локальной сети, позволяет внешним пользователям обращаться к локальным компьютерам по именам, необходи мо рассмотреть процесс обмена данными между различными серверами DNS. Предпо ложим, что к серверу DNS обратился Web-броузер, пользователь которого задал URL Сервер DNS должен преобразовать символьное имя gov в IP-адрес узла сети. Локальный сервер DNS начинает процесс преобразования с того, что обращается к корневому серверу DNS. IP-адреса компью теров, выполняющих функции корневых серверов, указаны в конфигурационном файле каждого сервера DNS;

вероятность того, что эти адреса изменятся, крайне мала. Обра щаясь к корневому серверу DNS, локальный сервер передает ему имя, предназначенное для преобразования (в данном примере это имя В большин стве случаев корневой сервер не знает IP-адреса, соответствующего указанному имени, но имеет информацию о доменах верхнего уровня (TLD — top-level domain). Примерами таких доменов являются и т. д. Поэтому корневой сервер возвращает локальному серверу адреса компьютеров, поддерживающих DNS-сервер. gov, после че го локальный сервер передает запрос одному из компьютеров, обеспечивающих работу домена. gov. Сервер DNS. gov также не может преобразовать имя, но он знает IP-адреса компьютеров, ответственных за поддержку домена whitehouse. gov, поэтому передает их локальному серверу DNS. Сервер знает IP-адрес, соответствую щий имени whitehouse. gov, поэтому, получив запрос локального сервера, он возвращает ему требуемую информацию. После получения IP-адреса локальный сервер DNS передает Web-броузеру, который использует адрес при формировании запроса к Web-серверу. Процесс преобразования адресов условно показан на рис. Детали этого процесса скрыты от пользователя. С точки зрения прикладной программы или ра ботающего с ней пользователя дело обстоит так, как будто локальный сервер DNS имеет информацию о соответствии символьных имен и IP-адресов всех узлов Internet.

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

Информация хранится в кэше в течение ограниченного времени, поэтому, если админи 428 Часть III. Серверы Internet Сервер имен корневого домена Я ищу адрес www.whitehouse.gov Я не знаю этого адреса, но могу сообщить адрес сервера.gov Локальный Сервер имен компьютер домена Я ищу адрес Я ищу адрес www.whitehouse.gov www.whitehouse.gov Я не знаю этого Адрес www.whitehouse.gov адреса, но могу сообщить адрес Адрес www.whitehouse.gov Сервер имен домена whitehouse.gov Рис. 18.1. Процесс преобразования адреса предполагает передачу запросов различным серве рам DNS стратор изменит IP-адрес одного из своих компьютерах, это не приведет к возникновению проблем при обращении к этой машине.

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

Глава 18. Администрирование домена Официальные организации, осуществляющие поддержку DNS, требуют, чтобы каждый домен обслуживался как минимум двумя серверами DNS. Несмотря ЗАМЕТКУ на то что для поддержки протокола преобразования имен достаточно одного сервера DNS, второй сервер создает избыточность, позволяющую повысить на дежность системы. Если один их серверов выйдет из второй сможет обра батывать запросы. Если размеры вашей сети малы, вы можете установить в ней лишь один (первичный) DNS-сервер, а второй (вторичный) сервер разместить за пределами сети.

Вместо установки собственного сервера DNS, вы можете использовать один из серве ров, предоставляющих услуги по преобразованию имен. Этим занимаются многие органи зации, осуществляющие поддержку DNS, и провайдеры Internet. Часто подобные услуги предоставляются бесплатно, в других случаях за них надо платить, но плата невелика (обычно она составляет несколько долларов в год). Так, например, бесплатное DNS-об служивание предлагает организация Granite Canyon com). Советую вам не слишком полагаться на бесплатные услуги;

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

Существует специальное динамическое которое предоставляет ся в основном пользователям DSL и кабельных модемов. Организации, которые предо ставляют динамическое DNS-обслуживание, поддерживают обычные серверы DNS, но они позволяют быстро обновлять записи, которые соответствуют изменяющимся IP-ад ресам. Многие организации предпочитают использовать статические IP-адреса и ста тические средства преобразования имен. Динамическое DNS-обслуживание в основном предоставляется отдельным пользователям, поддерживающим собственные серверы. Ди намическое DNS-обслуживание обеспечивают многие организации. Полный их список занял бы слишком много места, поэтому здесь приводятся лишь два URL:

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

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

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

430 Часть III. Серверы Internet • Преобразование адресов по запросам компьютеров локальной сети выполняет сер вер, находящийся в той же сети, что увеличивает производительность работы. Уве личение производительности особенно заметно тогда, когда сервер DNS провайдера работает медленно или ненадежно. Локальный сервер поддерживает собственный кэш, что также способствует повышению быстродействия.

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

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

В простых сетях вместо сервера DNS можно использовать другие средства преобразо вания адресов. Так, например, в системах Linux UNIX для этой цели можно применить файл /etc/hosts. (Аналогичное средство доступно и в прочих системах, но соответ ствующий файл расположен в другом каталоге. Например, в Windows подобные функции выполняет файл В составе файла /etc/hosts содер жатся записи;

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

gingko При установке системы Linux в файл /etc/hosts помещается единственная запись, которая связывает имя localhost с адресом Если в локальной сети содержит ся небольшое число компьютеров, этот файл несложно дополнить так, чтобы он определял все узлы сети. В небольшой сети отредактировать файлы /etc/hosts гораздо проще, чем настроить сервер DNS. При увеличении размеров сети для редактирования файлов /etc/hosts приходится прилагать все больше и больше усилий, в то время как затра ты на поддержку сервера DNS увеличиваются лишь незначительно. Применение файла /etc/hosts теряет смысл, если в вашей сети присутствует сервер DHCP и используется динамическое распределение IP-адресов.

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

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

Глава 18. Администрирование домена • Домен верхнего уровня на базе кода страны (ccTLD — country code top-level do main). Эти домены принадлежат конкретным странам. Например, домен при надлежит США, а. se — Швеции.

• Универсальный домен верхнего уровня (gTLD — generic top-level domain). Эти домены не отражают географическое положение узла сети. Примерами подобных доменов являются и Начиная с 2001 г. стали доступны новые gTLD;

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

Большинство таких организаций имеют право распределять домены в составе. com,. org,. net и ряда других TLD. Некоторые страны выделяют домены в своем ccTLD на коммерческой основе. При этом имя домена может получить организация, не имеющая ни какого отношения к стране, которой принадлежит домен верхнего уровня. Списки органи заций, поддерживающих реестр доменных имен, можно найти по адресам / и Стоимость регистрации домена в составе gTLD обычно составляет от 10 до 35 долларов в год.

В некоторых доменах верхнего уровня, например в gTLD. gov и. edu, а также во многих ccTLD регистрация доменов затруднена. Список ccTLDs, включающий информа цию об организациях, ответственных за распределение доменных имен, можно найти по адресу В конце г. были изменены принципы управления доменом верхнего уровня. us. С начала 2002 г. появилась возможность регистрировать домены непосред ственно в TLD. Если вы собираетесь зарегистрировать свой домен в составе. us, вам следует обратиться по адресу us.

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

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

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

432 Часть III. Серверы Internet Серверы DNS для Linux Первое, что необходимо сделать при установке сервера DNS, — решить, какой продукт вы будете использовать в качестве сервера. Разные программы предоставляют различные возможности. Наиболее часто используемые пакеты описаны ниже.

• BIND. Сервер BIND (Berkeley Internet Name Domain) — самая популярная в насто ящее время программа, которая может обеспечивать функции сервера DNS в си стеме Linux. Именно этому серверу уделяется основное внимание в данной главе.

Пакет BIND поставляется в составе многих дистрибутивных пакетов, кроме того, вы можете скопировать с узла В настоящее время доступна версия 9.2.0, но на момент написания данной книги, т. е. в 2002 г., многие дистрибутивные пакеты Linux еще поставлялись с версия ми 8.2.x данного продукта. Заметьте, что формат конфигурационного файла старой версии 4.9.x отличается от формата, используемого в новых версиях сервера.

• djbdns. D. J. Bernstein's DNS server (сервер DNS Д. Дж. Бернстайна) представляет собой продукт, альтернативный BIND, пользующийся популярностью у некоторых пользователей. Этот сервер отличается небольшими размерами, высокой эффектив ностью и обеспечивает высокий уровень защиты. Он не принят в качестве стандарта и не поставляется ни с одним из дистрибутивных пакетов, рассматриваемых в дан ной книге. При желании вы можете заменить BIND на Дополнительная ин формация о djbdns содержится на Web-странице to/djbdns.

html.

• pdnsd. Данный продукт представляет собой демон, реализующий proxy-сервер DNS. Он ориентирован для использования в локальной сети в качестве посредника между локальными компьютерами и внешним сервером DNS. Он также предостав ляет ограниченные средства преобразования имен, но не поддерживает все возмож ности BIND или Дополнительную информацию о pdnsd можно найти по адресу • dnscache. Подобно pdnsd, dnscache представляет собой proxy-сервер DNS. Он предназначен для ускорения процесса преобразования имен. В отличие от pdnsd, dnscache не подерживает локальные компьютеры, за исключением узла localhost (127.0.0.1). Информацию о данном продукте можно получить, обра тившись по адресу Большинство администраторов, занимающихся поддержкой компьютеров под управ лением Linux, используют в качестве сервера DNS продукт BIND, поскольку он принят как стандарт и поставляется с большинством версий данной операционной системы. Ад министраторы, для которых вопросы безопасности системы имеют первоочередное зна чение, отдают предпочтение продукту djbdns. Proxy-серверы DNS в основном исполь зуются в небольших сетях для кэширования результатов запросов к внешним серверам и преобразования локальных имен. Если же вы хотите поддерживать собственный домен и выполнять преобразование имен по запросам извне, возможности подобных продуктов не позволяют решать эти задачи. Остальной материал данной главы посвящен рассмот рению BIND, но некоторые действия по администрированию этого сервера применимы также к djbdns.

Глава 18. Администрирование домена Базовая конфигурация DNS Установка конфигурации DNS предполагает решение двух задач: настройка сервера DNS (в пакете BIND функции сервера выполняет программа named) и администриро вание домена. В данном разделе обсуждаются особенности выполнения первой задачи, а администрированию домена посвящен следующий раздел. (Далее в этой главе будут рассмотрены использование локального сервера DNS для кэширования результатов пре образования имен и интеграция BIND с сервером DHCP.) При настройке сервера DNS устанавливаются основные опции, указывается расположение других серверов DNS (в частности, серверов корневого домена) и задается информация о поддерживаемых зонах.

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

Главный конфигурационный файл BIND Основные опции BIND задаются в главном конфигурационном файле с именем Этот файл обычно располагается в каталоге /etc. В некоторых дистрибутивных пакетах Linux файл с опциями, установленными по умолчанию, в каталоге /etc отсут ствует. В этом случае файл-образец надо искать в каталоге, содержащем документацию BIND (обычно это каталог Пример файла conf приведен в листинге 18.1.

Листинг 18.1. Пример файла conf options { directory forwarders { forward first;

zone { type file zone { type file zone type master;

434 _ Часть III. Серверы Internet file zone { type master;

file Файл conf состоит из нескольких разделов. В листинге 18.1 представлены раздел options и несколько разделов zone. Раздел options содержит определения глобальных опций, в частности, в нем задается каталог, в котором содержатся файлы с описанием зоны. Разделы zone описывают конкретные зоны — домены либо другие группы имен или IP-адресов. Большинство строк, содержащихся в файле оканчиваются точкой с запятой (;

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

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

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

Расположение других серверов имен Одна из основных задач, которые вам предстоит решить при инсталляции сервера DNS, — получить список корневых серверов. Сделать это можно несколькими способами.

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

• Файл са, содержащий список корневых серверов, можно скопировать по средством протокола FTP, обратившись по адресу ftp: rs. internic.

net/domain/.

• Если в вашей системе установлена программа dig, вы можете задать команду dig @a. root-servers. ns > са. Эта команда копирует файл, содержащий список корневых серверов, и присваивает ему имя са.

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

Получив файл со списком корневых серверов, скопируйте его в каталог /var/named.

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

(Каждое доменное имя должно оканчиваться точкой, но имя корневой зоны состоит только из точки.) Настройка сервера для перенаправления запросов BIND осуществляет преобразование имен одним из трех описанных ниже способов.

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

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

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

В пакете BIND реализована еще одна возможность. Он может перенаправить запрос серверу DNS, чтобы тот выполнял всю рутинную работу по преобразованию адресов.

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

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

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

Перенаправление запросов задается с помощью опций и (см.

листинг Опция позволяет задать один или несколько IP-адресов сер веров DNS, к которым локальный сервер станет обращаться перед тем, как начать вы полнение стандартной процедуры преобразования адресов. Опция допускает одно из двух значений: only или Если вы зададите only, BIND при работе будет полагаться лишь на удаленный сервер DNS, указанный с помощью опции и не будет выполнять стандартную процедуру преобразования имен. Зна чение опции forward указывает на то, что BIND должен сначала обратиться 436 Часть III. Серверы Internet к удаленному серверу DNS, а если такое обращение не дало результатов (например, если удаленный сервер не ответил на запрос), он должен осуществить преобразование имен по стандартному алгоритму. В любом случае, если к серверу поступит запрос на преоб разование имен, которые принадлежат зоне, обслуживаемой данным сервером, он будет использовать описание зоны в своем конфигурационном файле.

Описание зоны При настройке BIND вы должны указать, как следует обрабатывать запросы, в ко торых указаны определенные домены, и диапазоны IP-адресов. Различные группы имен и адресов называются зонами. Зоной может быть домен или поддомен (например, зоной является домен указанный в листинге 18.1) ли бо диапазон IP-адресов (такой диапазон присутствует в имени зоны, оканчивающемся символами arpa). Для простого сервера DNS задается лишь несколько зон.

• Корневая зона. Зона, идентифицируемая посредством точки определяет кор невой узел пространства имен. В определении зоны присутствует опция type hint, которая сообщает о том, что список серверов содержится в файле, указанном по средством опции • Локальный домен. Если ваш сервер DNS предназначен не только для кэширования, вам придется сконфигурировать BIND для поддержки зоны, соответствующей ва шему домену. В листинге примером такой зоны является com.

• Обратная зона. Несмотря на то что в большинстве случаев сервер DNS использу ется для преобразования символьных имен в IP-адреса, сервер имен также должен поддерживать обратное преобразование. Для выполнения подобного преобразова ния создается зона, имя которой оканчивается на in-addr Перед этой последовательностью символов указывается имя зоны, т. е. часть IP-адреса, за данная в обратном порядке. Например, запись для сети 192.168.1.0/24 имеет имя В определении зоны указывается тип зоны и список конфигурационных файлов, предоставляющих дополнительную информацию о зоне. Типы зон описаны ниже.

• master. Первичный, или ведущий (master), сервер содержит описание зоны. Если вы создаете сервер DNS для небольшой сети, то, вероятнее всего, объявите локаль ные зоны как master. Пример зоны такого типа приведен в листинге • slave. Вторичный, или ведомый (slave), сервер получает информацию о зоне от другого сервера DNS. Такой сервер также может выступать в роли источника ин формации о зоне. В следующем разделе данный тип зоны будет рассмотрен более подробно. Простой сервер DNS может выступать для некоторых зон как ведущий, а для других зон — как ведомый.

• stub. Сервер такого типа похож на ведомый, но он копирует только записи NS, т. е. спецификации сервера имен. Данный тип зоны следует использовать в том случае, если вы хотите создать отдельный сервер DNS для Предполо жим, что домен com содержит поддомен com Глава 18. Администрирование домена и вы хотите использовать для управления им отдельный сервер DNS. Для это го вы должны включить в состав конфигурационного файла сервера BIND для определение зоны с именем типа stub, указывающее на сервер DNS Вы можете также использовать один сервер DNS для поддержки всего домена, включая com. В этом случае вам не понадобится формировать специ альную зону • Подобно опции в разделе options, зона сообщает BIND, что запросы на получение информации о зоне должны передаваться другому серверу DNS. BIND формирует собственный запрос к указанному серверу, а за тем использует полученные данные для построения ответа. Используя зону такого типа, вы должны включить опцию указывающую BIND, какому из удаленных серверов DNS должны перенаправляться запросы.

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

Она сообщает системе, где следует искать список таких серверов. BIND должен самостоятельно обновлять данный список, обращаясь к корневому серверу имен.

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

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

zone { type slave;

file masters { } Приведенная выше запись указывает на то, что ведомый сервер должен получать со держимое конфигурационного файла для com с сервера DNS, располо женного по адресу 192.168.1.50. Если сервер функционирует как ведомый для нескольких доменов, в его конфигурационном файле содержится несколько подобных определений.

В списке masters можно указать два и более серверов DNS;

их адреса отделяются друг от друга точкой с запятой. (При необходимости ведомый сервер может синхронизировать свое содержимое посредством другого ведомого сервера.) Если сервер является ведо мым для нескольких зон, различные зоны могут синхронизироваться от разных ведущих серверов. Эту возможность удобно использовать в том случае, если вы администрируете 438 _ Часть III. Серверы Internet несколько доменов. Каждый домен обслуживается отдельным ведущим сервером, и для всех их роль ведомого может выполнять один сервер.

Зоны типа должны быть определены не только для прямого, но и для обратно го преобразования адресов (зоны com и. arpa, приведенные в листинге Для корневых серверов имен и для обратного преобра зования localhost (0. О. 127. in-addr. arpa в листинге 18.1) зоны типа slave создавать не надо.

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

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

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

В системе DNS имена узлов должны оканчиваться точкой. Если, работая с f ентскими программами Internet (Web-броузером, клиентом FTP, программой подготовки почты), вы не укажете завершающую точку, система Linux снача ла посчитает, что имя домена не указано, поэтому добавит к имени узла имя Глава 18. Администрирование домена домена, заданное в Если попытка преобразования тако го имени окажется неудачной, система вместо имени домена добавит к имени, указанному пользователем, точку и снова попытается выполнить преобразова ние. Эти действия скрыты от пользователя, поэтому он может пренебрегать точкой в конце имени без ущерба для себя. Настраивая сервер DNS, адми нистратор не может позволить себе подобной небрежности. В конфигураци онном файле можно задавать либо полностью определенное доменное имя, оканчивающееся точкой, либо имя узла, не содержащее имени домена. Если вы забудете указать точку в конце полного доменного имени, система доба вит к нему имя домена. Сформированное таким образом имя будет иметь вид Листинг 18.2. Простой конфигурационный файл зоны IN SOA ( 2002043004 serial (последовательный номер) 3600 refresh (обновление) 600 retry (повторное обращение) 604800 expire (срок действия) 86400 (время жизни) IN A 192.168.1. birch IN A 192.168.1. spruce IN A 192.168.1. IN A 192.168.1. WWW IN gingko IN CNAME j kelp IN MX @ IN MX @ IN NS @ Формат записи в конфигурационном файле зоны выглядит следующим образом:

имя IN Здесь под именем подразумевается имя компьютера или псевдоимя, связанное с адре сом и применяемое для обратного преобразования. Идентификатор IN сокращенно озна чает Internet и определяет класс записи. Кроме IN существуют и другие классы записей, но в данной главе они рассматриваться не будут. Тип записи — это код, определяющий запись для прямого или обратного преобразования адресов, или запись, используемая по чтовым сервером. Содержимое записи может занимать одну или несколько строк и обычно представляет собой IP-адрес или имя узла. Если содержимое записи является описанием зоны, оно располагается в нескольких строках, в остальных случаях вся запись помещает ся в одной строке. Признаком комментариев является точка с запятой, текст, следующий за ней, не обрабатывается сервером.

440 Часть Серверы Internet ВНИМАНИЕ В различных конфигурационных файлах BIND точка с запятой интерпретирует | ся по-разному: в файле ею заканчивается выражение, а в файле зоны она определяет комментарии. Это следует учитывать при редактировании конфигурационных файлов BIND, в противном случае сервер будет работать некорректно.

Конфигурационный файл зоны обычно помещается в каталог и ему присваивается имя, связанное с именем зоны. Обычно для такого файла выбирается имя или имя-зоны. Конфигурационному файлу можно присво ить любое имя, необходимо лишь, чтобы оно совпадало с именем, указанным в /etc/ Формирование описания зоны Для описания зоны используется запись SOA (Start of Authority — начало полномочий).

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

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

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

Чтобы его можно было использовать, надо заменить первую точку на символ так, адрес com. Будет преобразован в com.

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

В листинге 18.2 приведены комментарии, поясняющие назначение соответствую щих чисел. В строке, помеченной комментариями serial, содержится последо вательный номер, который необходимо увеличивать при каждом редактировании файла. Ведомый сервер на основании данного значения определяет, следует ли обновлять свой конфигурационный файл. Многие администраторы задают после довательный номер как дату (в формате YYYYMMDD), сопровождая ее номером изменений, произведенных в течение текущего дня. В строке refresh задает ся время в секундах между обращениями ведомого сервера к ведущему. Значение 3600, приведенное в листинге 18.2, соответствует одному часу, следовательно, ве домый сервер будет каждый час проверять, не изменились ли параметры зоны на ведущем сервере. Значение retry представляет время в секундах, по истечении которого ведомый сервер предпримет повторную попытку обращения к ведущему серверу в случае, если первая попытка окажется неудачной. Значение expire также Глава 18. Администрирование домена определяет время в секундах, в течение которого запись считается действительной, если ведомому серверу не удается связаться с ведущим. По истечении указанного времени запись не может быть использована для преобразования имен. Величи на expire обычно соответствует одной неделе и, конечно же, должна превышать значение Значение задает время жизни. В течение этого времени сервер DNS должен хранить информацию о результатах преобразования.

Обычно величина времени жизни составляет от одного дня (86400 в листинге до одной недели (604800). Если IP-адреса вашей сети часто изменяются или если вы предполагаете, что вскоре придется произвести много изменений, имеет смысл задать время жизни порядка часа.

Определение адресов и имен Большинство записей в конфигурационном файле зоны предоставляет информацию о соответствии между именами и IP-адресами. В поле имени, как правило, задается имя компьютера либо другое имя, связанное с IP-адресом. В поле имени также можно задавать символ @, заменяющий имя домена. Данный символ обычно используют в записях MX и NS (листинг 18.2). Эти записи не несут информации о взаимосвязи имен и адресов, а определяют специальные имена для всего домена.

Ниже описаны основные типы записей.

• А. В записи A (address — адрес) в поле имени задается имя узла, а содержимое записи представляет собой IP-адрес. В качестве имени узла можно использовать полное доменное имя (с завершающей точкой), например либо имя узла без указания имени домена, например birch или spruce.

Можно также в качестве имени компьютера указать имя домена, так, например, в листинге 18.2 задано соответствие между именем и IP адресом • Запись (canonical name — каноническое имя) ставит в соответствие имени другое имя. В поле содержимого может быть указано либо полное домен ное имя с завершающей точкой, либо имя узла без имени домена. Если вы задаете полное доменное имя, оно не обязательно должно принадлежать домену, определя емому посредством файла зоны. Например, в листинге имя kelp связывается с компьютером в другом домене. Записи CNAME обычно применяются в тех случа ях, когда важные IP-адреса могут изменяться без вашего участия. Например, если вы размещаете Web-страницу на внешнем компьютере, то можете связать имя с именем этой машины. Если адрес внешнего компьютера изменится, ваша запись останется корректной.

• PTR. В листинге 18.2 записи типа PTR отсутствуют. Эти записи применяются для обратного преобразования и будут рассматриваться ниже.

• Запись NS (name server — сервер имен) задает сервер имен для домена. В конфи гурационном файле должна присутствовать хотя бы одна запись NS, указывающая на компьютер, заданный в качестве ведущего сервера имен в записи SOA. В по ле имени данной записи указывается либо имя домена, либо символ @. IP-адрес компьютера, содержащего сервер имен, задается с помощью записи А.

442 Часть III. Серверы Internet • MX. Запись MX (mail exchanger — обмен почтой) предоставляет информацию о по чтовом сервере для зоны. В поле имени этой записи указывается символ либо имя домена. В поле содержимого записи содержатся два компонента: код прио ритета и имя узла. Когда удаленный почтовый сервер собирается передать сооб щение пользователю в домене (например, com), он запра шивает у сервера имен записи MX. Затем уделенный сервер пытается свзязаться с компьютером, для которого указано наименьшее значение приоритета (в листин ге это Если этот компьютер не доступен, уда ленный сервер предпринимает попытку установить соединение с тем узлом, при оритет которого выражается следующим по величине значением (в листинге 18. это Перебор компьютеров продолжается до тех пока сообщение не будет доставлено либо пока не выяснится, что все узлы, указанные в записях MX, не доступны. Очевидно, что компьютер, имя которого задано в за писи MX, должен быть настроен для приема почты. Вопросы передачи почтовых сообщений будут рассматриваться в главе 19.

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

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

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

Для того чтобы это стало возможным, необходимо создать псевдодомен В файле содержатся указатели на конфигурационные файлы, опи сывающие подмножества этого домена. Поскольку имя домена уточняется при движении справа налево, а IP-адрес уточняется по мере движения слева направо, в имени псевдодо мена адрес должен быть указан в обратном порядке. Например, имя зоны для диапазона адресов 192.168.1.0/24 будет иметь вид. in-addr Зона для обратного преобразования, или обратная зона, настраивается подобно зоне прямого преобразования. Конфигурационный файл зоны содержит записи SOA и NS, но основное место в нем занимают записи PTR. При обратном преобразовании не возникает необходимость в записях MX, А и CNAME. В листинге содержится конфигурационный файл обратной зоны, соответствующий файлу, приведенному в листинге 18.2.

В поле имени записи PTR указывается либо сокращенный вариант адреса (например, 1 для либо полный IP-адрес, расположенный в обратном порядке и сопро вождаемый именем В листинге 18.3 продемонстрированы оба подхода.

В поле содержимого включается полное доменное имея с точкой в конце. Поскольку обратная зона отличается от зоны, используемой для прямого попытка задать в поле содержимого сокращенное имя приведет к некорректному преобразованию, например, при указании birch вместо будет получен ре зультат Глава 18. Администрирование домена Листинг 18.3. Пример конфигурационного файла обратной зоны IN SOA \ ( 2002043004 serial 3600 refresh 600 retry 604800 expire 86400 default 1 IN PTR. 2.168.192 IN PTR. 3.168.192 IN PTR 4.1.168.192 IN PTR @ IN NS Настройка сервера, предназначенного только для кэширования В небольших сетях часто используются серверы DNS, основная задача которых — кэ ширование результатов преобразования имен. Сервер такого типа не поддерживает кон кретный домен (за исключением домена для обратного преобразования Вместо этого сервер перенаправляет запросы внешним серверам DNS и записывает по лученные от них сведения в кэш. Такая конфигурация сервера может ускорить работу клиент-программ, в частности, Web-броузеров, если сеть связана с Internet посредством линий с низкой пропускной способностью или большой задержкой. Так, например, линия спутниковой связи характеризуется задержкой порядка половины секунды при двусто ронней передаче данных. Задержка при использовании коммутируемых линий около 200 миллисекунд, что лучше, чем для линий спутниковой связи, но все же суще ственно замедляет преобразование имен.

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

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

Наиболее важными компонентами конфигурационного файла сервера DNS, предна значенного только для кэширования, являются опции и распо ложенные в разделе options. Опция должна содержать список серверов DNS провайдера. BIND использует эти серверы для выполнения преобразования. Вме сто выражения forward first, приведенного в листинге 18.1, необходимо указать 444 Часть III. Серверы Internet only. В этом случае сервер прекратит попытки преобразования, если серве ры, указанные в качестве значения окажутся не доступными.

ВНИМАНИЕ Если вы включите в состав конфигурационного файла корневую зону и зада | дите опцию forward то в случае, когда серверы, предназначенные для перенаправления запроса, станут не доступны, BIND предпримет попыт ку выполнения стандартной процедуры преобразования адресов. Само по себе это неплохо, но при этом процедура выявления ошибки и генерации соответ ствующего сообщения окажется длительной. В особенности этот будет заметно в том случае, если соединение с Internet осуществляется посредством линии с большой задержкой.

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

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

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

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

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

В главе 5 рассматривалась конфигурация сервера DHCP для совместной работы с сер вером DNS. Чтобы соответствующим образом настроить BIND, вам надо внести измене ния в файл Вы должны добавить в определение соответствующей зоны опцию В результате определение зоны примет следующий вид:

zone { type master;

file 18. Администрирование домена { } Теперь BIND будет принимать информацию об IP-адресах от компьютера с адресом Как нетрудно догадаться, это должен быть адрес узла на котором вы полняется сервер DHCP. Аналогичные изменения надо внести в определение обратной зоны.

Если ваш сервер DNS доступен из или если вы не полностью дове f ряете пользователям локальной сети, получение информации об обновлении представляет угрозу безопасности системы. Хакер может взломать сервер DHCP или, фальсифицировав адрес, внести необходимые ему изменения в конфигурацию сервера DNS. Чтобы уменьшить опасность атаки, желательно разместить серверы DNS и DHCP на одном компьютере и разрешить обновление только с локального узла (127.0.0.1).

* Запуск и тестирование сервера Для запуска сервера DNS можно применить любой из способов, рассмотренных в гла ве 4, но чаще всего сервер DNS запускается с помощью сценария SysV или локального сценария запуска. Запуск сервера DNS посредством суперсервера снизит скорость преоб разования имен.

Для тестирования сервера имен хорошо подходит инструмент Программа поставляется в составе большинства версий Linux;

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

$ host www.awl.com is a nickname for awl.com has address В данном примере первая строка, отображаемая программой, сообщает о том, что com представляет собой каноническое имя (заданное с помощью записи узла awl.com. Этот компьютер имеет адрес 165.193.123.224. Такой тест под тверждает, что сервер DNS может преобразовывать имена внешних узлов. Если вы скон фигурировали сервер для поддержки собственного домена, вы должны указать при про верке локальные имя и адрес. Убедитесь в том, что сервер выполняет как прямое, и обратное преобразование. При необходимости вы также можете просмотреть записи требуемого типа, задавая при вызове утилиты опцию Например, чтобы проверить записи MX для домена, вам потребуется выполнить следующую команду:

$ host -t MX awl.com mail is handled by awl.com mail is handled by mail is handled by Данная проверка показывает, что в домене com определены три почтовых серве ра:

446 Часть III. Серверы Internet оритет 20) и (приоритет 100). Если вы хотите указать сервер DNS для тестирования, вам надо при вызове программы задать имя или IP-адрес этого сервера.

$ host spruce Using domain server:

Name:

Address:

www.awl.com is a nickname for awl.com awl.com has address При этом выводятся те же данные, что и в предыдущем примере, кроме того, отобра жается подтверждение того, что программа host передала запрос конкретному серверу DNS.

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

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

Глава Передача почты: протокол SMTP В главе рассматривались протоколы POP и IMAP, которые частично решают зада чу доставки писем. Эти и другие протоколы получения почты позволяют пользователю копировать адресованные ему сообщения с центрального сервера на свой компьютер.

Pages:     | 1 |   ...   | 7 | 8 || 10 | 11 |   ...   | 14 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.