Обзор сетевых возможностей

Имеется простой способ быстрого определения номера нужного подустройства. /dev/rmtX.N N=A+B+C где, A - ?мкость (А=4, если ?мкость высокая и А=0, если ?мкость ленты низкая); В - удержание (В=2, если удержание необходимо и В=0 в противном случае); С - перематывание (С=1, если нужно перематывание и С=0, если не нужно).

Меню архивирования

Архивирование удобно выполнять с помощью SMIT:

System Storage Management (Physical & Logical)

 
Move cursor to desired item and press Enter.

  Logical Volume Manager
  File Systems
  Files & Directories
  System Backup Manager



F1=Help      F2=Refresh        F3=Cancel         F8=Image
F9=Shell     F10=Exit          Enter=Do

Процесс архивирования rootvg - mksysb

Для работы с системным архивированием необходимо установить bos.sysmgt.br. Этот процесс архивирует только группу томов rootvg. Прич?м:

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

Файл /image.data

При создании группы томов rootvg процесс установки базовой операционной системы использует файл /image.data.

Обычно, информация в станзах этого файла генерируется командами lsxx; например, lsvg для группы томов, lslv для логического тома, lsjfs для файловой системы.

Администратор при необходимости может описать дополнительные действия после установки базовой операционной системы используя поле BOSINST_FILE= в станзе post_install_data.

Описание важнейших станз

LOGICAL_VOLUME_POLICY Содержит информацию используемую при восстановлении.

Если поле SHRINK= установлено в YES то логические тома и файловые системы "обрезаются" (создаются размером установленным в полях LV_MIN_LPs и FS_MIN_SIZE) при восстановлении.

Поле EXACT_FIT= указывает на то, использовать или не использовать карту физических разделов для размещения логических томов.

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

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

Файл /bosinst.data

Файл /bosinst.data содержит требования необходимые для целевой системы, а также определяет то, как пользователь взаимодействует с ней.

control_flow:
CONSOLE=
INSTALL_METHOD=overwrite
PROMPT=yes
EXITING_SYSTEM_OVERWRITE=no
INSTALL_X_IF_ADAPTER=yes
RUN_STARTUP=yes
RM_INST_ROOTFS=no
ERROR_EXIT=
CUSTOMIZATION_FILE=
TCB=no
INSTALL_TYPE=
BUNDLES=

Наличие этого файла позволяет использовать один и тот же архивный образ для различных аппаратно целевых систем. Утилита системного архивирования просто копирует файл /bosinst.data как первый файл в образе rootvg. Если этого файла нет в директории root, то в файл /bosinst.data образа копируется содержимое файла /usr/lpp/bosinst/bosinst.template.

CONSOLE - определяет устройство (полный путь), которое вы хотите использовать как консоль.

INSTALL_METHOD - определяет метод установки (migration, preserve или overwrite)

PROMPT - определяет, используется ли меню выбора действий для пользователя при установке или нет. Если значение этой переменной установлено в no, то администратор обязан заполнить все значения в станзах locale и control_flow (исключение: значения для параметров ERROR_EXIT и CUSTOMIZATION_FILE не обязательны).

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

INSTALL_X_IF_ADAPTER - запрос насчет того, если в целевой системе существует графический адаптер, устанавливать ли AIXWindows или нет.

RUN_STARTUP - запускать ли Installation Assistant после первой загрузки после уста-новки BOS.

RM_INST_ROOTFS - удаляет все файлы и директории в директориях /usr/lpp/*/Inst_roots.

ERROR_EXIT - запускает определенную администратором исполняемую программу, если в программе установки обнаружена ошибка.

CUSTOMIZATION_FILE - определяет имя и полный путь к файлу настроек, который исполняется сразу после завершения программы установки.

TCB - определяет потребность в установке Защищенной вычислительной основы

INSTALL_TYPE - определяет какое программное обеспечение устанавливать на систему. Параметр может принимать следующие значения: full (полно-функциональная конфигурация), client (клиентская конфигурация) и personal (конфигурация персо-нальной рабочей станции).

BUNDLES - определяет какие пакеты программного обеспечения устанавливать. Имена пакетов разделяются пробелами.

Станза target_disk_data содержит значения определяющие параметры дисков системы, на которую программа должна установить BOS.

LOCATION - определяются коды размещения диска на которой должна будет установлена BOS.

SIZE_MB - определяет форматированный размер диска (в мегабайтах) где программа должна установить BOS.

HDISKNAME - определяет имя и путь целевого диска.

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

CULTURAL_CONVENTION - определяет культурные соглашения для установки.

MESSAGES - определяются директории сообщений.

KEYBOARD - определяется раскладка клавиатуры.

Восстановление информации

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

Немного подробнее хотелось бы описать процесс восстановления системы из системного образа. Для восстановления информации из системного архива необходимо загрузить систему в режим Installation/Maintenance (Установка/Обслуживание), выбрать пункт меню "Maintenance", а в нем выбрать пункт "Install from a System backup" и определить устройство на котором расположен образ системы.

Команды архивирования UNIX

Администратор может также воспользоваться известными и применяемыми в мире UNIX командами архивирования tar, cpio и dd.

Стратегия работы с архивами

1. Удостоверьтесь, что вы можете восстановить информацию быстро, просто и качественно.

2. Периодически проверяйте ваши архивы (tapechk).

4. Проверьте файловые системы после архивирования (fsck).

5. Удостоверьтесь, что файлы не находятся в использовании во время архивирования (fuser).

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

8. При команде создания ленты давайте ей метку.

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

Обзор сетевых возможностей

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

Обзор TCP/IP

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

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

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

Аббревиатура TCP/IP означает "Transmission Control Protocol/Internet Protocol". Это имена двух важнейших протоколов. В сетевой архитектуре TCP/IP имеются много других протоколов. Эти протоколы не привязаны ни к какой операционной системе и аппаратной платформе. И в силу такой независимости, для того чтобы сетевая аппаратура могла их использовать, только программный интерфейс должен быть построен в соответствии с этими протоколами.

Протоколы TCP/IP работают с различными типами сетей - от низкоскоростных соединений последовательного типа до быстрых локальных компьютерных сетей (LAN) типа Token-Ring или Ethernet и еще более быстрых сетей на основе оптического кабеля, таких как FDDI и HYPERchannel.

Сеть на основе TCP/IP называют internet (не путать с названием глобальной сети сетей The Internet, название которой пишется с заглавной буквы и которая тоже построена на основе протоколов TCP/IP).

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

Сетевой интерфейс, который подключен к internet со своим адресом TCP/IP, называется узел (host).

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

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

Имена и адресация

Каждый сетевой интерфейс в сети TCP/IP имеет имя, присваиваемое сервером им?н (DNS) или определенное в файле /etc/hosts (см.Настройка клиентской части). Например, sys3.

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

Формат IP адреса IP-адрес является 32-х разрядным бинарным (состоящим из 1 и 0) числом, которое содержит в себе адрес и сети и узла.

Чтобы облегчить работу с IP-адресами их, обычно, разделяют на четыре группы по восемь цифр (четыре октета):

и каждый октет преобразуют в десятичный вид.

Десятичная запись с точечными разделителями вышеуказанного IP-адреса:

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

? поля идентификатора сети (netid), являющегося логическим сетевым адресом подсети, к которой подключ?н данный сетевой интерфейс;
? поля идентификатора узла (hostid), являющегося логическим адресом сетевого интерфейса в данной сети.

Вместе, netid и hostid уникальным образом предоставляют сетевому интерфейсу уникальный IP-адрес.

IP-адреса организованы в классы значением первого октета:

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

Специальные IP-адреса

Существуют IP-адреса, применяемые для специальных целей:

Маска подсети

Для упрощения и ускорения определения той части IP-адреса, которая является netid, а также для выделения подсетей в диапазоне адресов стандартных классов применяют маски подсети (subnet mask).

Маска подсети - это бинарное число, которое определяет, какая часть IP-адреса является netid, а какая hostid. Использование маски подсети имеет особенно важное значение, если ваша сеть подключена к Internet. Если ваша сеть объединяет несколько удаленных филиалов вашу сеть также необходимо разбить на подсети с организацией маршрутизации между ними, чтобы уменьшить трафик по межфилиальным коммуникациям, которые, обычно, не такие скоростные, как локальная сеть.

Стандартная маска подсети для адреса класса С следующая:

Цифра 0 в маске подсети означает, что соответствующий разряд в IP-адресе является hostid. Например, чтобы разбить сеть класса С на четыре подсети необходимо применить маску подсети

Маска подсети показывает, что hostid могут находиться в диапазоне 000001 до 111110 (от 1 до 62) и первые два разряда четвертого октета могут иметь значения от 00 до 11. Следовательно, наша сеть класса С 194.93.173 (254 адреса), с помощью маски подсети разбита на четыре подсети с 62-мя адресами (248 адресов + 4 адреса пошло на netid + 2 специальных адреса).

Маршрутизация

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

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

При маршрутизации IP-адреса отправителя и получателя не изменяются. Изменяются только соответствующие аппаратные адреса.

Некоторые возможности сети TCP/IP

Стандартные возможности сети TCP/IP включают в себя:

? Mail (электронная почта)
? File Transfer (средства передачи файлов)
? Remote Login (удаленное подключение)
? Remote Execution (удаленное исполнение приложений)
? Remote Printing (печать на удаленных принтерах).

Различные приложения AIX используют протоколы TCP/IP, например такие как:

? Network File System (NFS)
? Network Information Services (NIS)
? Network Computing System (NCS)
? Distributed Computing Environment (DCE)
? Xwindow и AIXwindows
? Xstation Manager
? AIX Netwiev/6000

Конфигурирование TCP/IP

Для конфигурирования TCP/IP требуется следующая информация:

Каждый сетевой интерфейс должен иметь уникальный адрес (TCP/IP address), имя узла (hostname) и почти всегда маску подсети (subnet mask).

Каждый компьютер должен иметь доступ к таблице имен для трансляции имен в адреса. Она находится либо в файле /etc/hosts, либо в Domain Name Server (DNS).

Для использования DNS вы должны знать имя домена (Domain Name) и адрес сервера имен (Address of the Name Server).

Для обмена данными с другими сетями вы должны знать адрес стандартного шлюза (address of the default gateway).

Обзор доменной службы имен DNS

Как работает DNS

В сетях TCP/IP компьютеры для общения между собой используют IP-адреса. Однако то, что удобно машинам, неудобно людям. Есть спорное мнение, что сама человеческая натура протестует против запоминания чисел типа 192.168.1.34 (что не мешает нам запоминать телефонные номера с кодом города и страны, типа 380-564-40-06-24). К тому же IP-адреса совсем не информативны. По IP-адресу невозможно понять, что это: сервер, ПК, маршрутизатор или сетевой принтер. Приятней работать с осмысленными именами, такими как account-server.

Тем не менее сетевые устройства обращаются друг к другу, используя IP-адрес, а не имена.

Решает эту проблему система именования сетевых объектов, которая отвечает за преобразование символьных имен в IP-адреса. Система именования выполняет функции телефонной книги, в которой каждому номеру телефона поставлена в соответствие запись о фамилии или названии фирмы. Системе передается имя (например archie.univie.ac.at), а она возвращает IP-адрес (140.78.3.8).

Системы именования сетевых объектов делятся на "плоские" и иерархические (доменные).

В "стародавние времена", когда Internet еще называлась ARPANET и Сеть состояла лишь из многотерминальных компьютеров типа мэйнфреймов (при этом их количество оставалось относительно невелико), была реализована система именования для одноуровневого (плоского) пространства имен. Ее также называют "плоской" системой именования. Каждый компьютер имел файл (обычно /etc/hosts) со списком IP-адресов хостов и их символьные имена. При появлении в Internet нового компьютера информация о нем заносилась в файл hosts, затем этот файл рассылался на все другие машины.

Недостатки такой схемы начали проявляться довольно быстро: с переходом от больших машин к персональным и с ростом Internet. Трафик, связанный с обновлением информации при добавлении компьютеров в Internet, грозил забить все линии связи. Кроме того, каждое имя в сети должно быть уникальным, а сделать это становится все труднее и труднее. Поэтому к середине 80-х годов появилась другая, более гибкая система именования - система имен доменов (Domain Name System, DNS).

DNS реализует иерархическое пространство имен. Единицей измерения является домен (территория, область). Понятие домена DNS не надо путать с доменом Windows NT или доменом NIS. Они не имеют друг к другу никакого отношения.

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

Наиболее известные домены первого уровня: com - коммерческие организации (главным образом в США); edu - учебные заведения США; gov - правительственные учреждения США; mil - военные учреждения США; net - различные сетевые агентства и Internet-провайдеры; int - международные организации; org - некоммерческие учреждения; код страны - двухбуквенный код для обозначения государства (ru - для России, ua - для Украины и т.п.). Ниже доменов первого уровня располагаются домены второго уровня и так далее вплоть до хостов. Для доменов первого уровня, обозначающих государства, доменами второго уровня часто бывают города или области (например, kiev - для Киева или dp -Днепропетровская область), а доменами третьего уровня - предприятия и организации.

Любой хост или домен в Internet однозначно идентифицируется так называемым полным доменным именем (Fully Qualified Domain Name, FQDN). Его иногда еще называют абсолютным доменным адресом. Домены в FQDN записываются справа налево в порядке подчинения и разделяются точками. Каждая отдельная составляющая FQDN называется меткой (label). Длина метки не должна превышать 63 символа, а полная длина FQDN - 255 символов.

Допустимыми символами являются буквы английского языка, цифры и знак дефиса "-" (знак дефиса не может стоять в начале или конце метки). Регистр букв значения не имеет, т. е. company1.krcrme.dp.ua. и COMPANY1.KRCRME.DP.UA. обозначают один и тот же домен.

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

Кроме абсолютной применяется и относительная доменная адресация. Когда два устройства находятся в одном и том же домене, они могут обращаться друг к другу по имени, не указывая полного доменного пути. Так, host2 обращается к host1 двумя способами: по полному доменному имени host1.company1.krcrme.dp.ua. по относительному доменному адресу host1

В полном доменном имени конечную точку можно не ставить, поскольку обычно программное обеспечение TCP/IP подразумевает, что составное доменное имя (т.е. когда присутствует более двух меток) обозначает FQDN. Таким образом, company1.krcrme.dp.ua. и company1.krcrme.dp.ua суть одно и то же.

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

Как уже отмечалось, основное назначение DNS состоит в преобразовании имени хоста в его IP-адрес. На самом деле DNS является системой, не зависимой от протокола сетевого уровня, т. е. она может быть реализована не только в среде TCP/IP.

Однако функции DNS этим не ограничиваются. DNS позволяет получить следующую информацию:

Существует и ряд других, реже используемых параметров.

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

Программное обеспечение, которое общается с серверами имен, называют клиентом DNS (Resolver DNS). Клиент DNS выполняет роль посредника между сетевыми приложениями и серверами имен. При этом он, как правило, скрыт от пользовательских программ. Сетевые приложения используют клиент DNS чаще всего неявно, через функции стека TCP/IP. Однако приложение nslookup позволяет получить любую информацию из базы DNS. Клиент DNS входит в состав программного обеспечения TCP/IP. Но стек TCP/IP, по-мимо DNS, поддерживает и "плоскую" систему именования (через файл hosts). Это позволяет обеспечить работоспособность сетевых устройств при проблемах с DNS (например при отсутствии связи с сервером имен). Клиент DNS может функционировать как на отдельном компьютере, так и на сервере имен.

Сервер имен на самом деле отвечает не за домен, а за так называемую зону управления (Zone of Authority), в которую могут входить несколько смежных доменов. Более того, сервер имен способен управлять несколькими, причем не обязательно смежными, зонами одновременно.

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

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

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

Серверы имен бывают нескольких типов. Первичный сервер имен (Primary Name Server) хранит на своих дисках главные файлы (master files), в которых содержится вся информация о зонах управления данного сервера. Эти файлы загружаются в память сервера имен при его запуске.

Вторичный сервер имен (Secondary Name Server) используется как дубликат первичного сервера, что обеспечивает отказоустойчивость DNS. Он загружает информацию с первичного сервера и затем периодически ее обновляет, посылая первичному серверу запросы.

Серверы "только для кэширования" (Cache-Only Server) записывают в кэш информацию, полученную от других серверов имен. Чаще всего они используются в больших сетях для разгрузки первичного сервера.

Это, однако, еще не все типы серверов имен, но оставшиеся (серверы Forwarder и Slave Forwarder) имеют лишь незначительные отличия в обработке информации DNS.

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

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

Серверам имен других зон передается только конкретная информация (а не данные по всей зоне) и только по их запросам.

Таким путем удалось резко снизить в Internet трафик, связанный с преобразованием имен в IP-адреса.

Серверы имен могут работать в двух режимах: нерекурсивном и рекурсивном.

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

Таким образом, в нерекурсивном режиме клиент сам осуществляет все запросы к серверам имен.

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

Чтобы работать в рекурсивном режиме, сервер и клиент должны быть настроены соответствующим образом. Однако в большинстве случаев пользователь не имеет возможности менять настройку режима работы клиента, поскольку она "зашита" в программное обеспечение TCP/IP.

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

Сервисы DNS в AIX

Все сервисы доменного именования полностью реализованы в AIX. Поддерживаются следующие типы серверов имен:

1. Первичный сервер имен;
2. Вторичный сервер имен;
3. Сервер "только для кэширования";
4. Сервер Forwarder;
5. Удаленный сервер.

Клиент DNS в AIX, gethostbyaddr() и gethostbyname(), пытается определить имена ис-пользуя следующую процедуру:

Если файл /etc/resolv.conf не существует, клиент DNS считает, что в сети используется плоская система именования. Тогда он использует для определения имен файл /etc/hosts.

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

Функции сервера имен в AIX выполняет демон named. Он контролируется посредством AIX SRC (system resource control). Этот демон может стартовать автоматически при каждом перезапуске системы используя команду smit stnamed или если будет отредактирован файл rc.tcpip убрав комментарий в сроке #start /etc/named "$src_running" Демон named стартует также при команде startsrc -s named.

Хост AIX конфигурируется для использования сервера имен используя следующие шаги:

1. Создайте файл /etc/resolv.conf включив в него имя домена и адреса до 16-ти серверов имен. Например:

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

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

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

2. Создайте файл /etc/named.boot для определения имени и типа локального демона named.

3. Создайте файлы /etc/named.* для определения требуемых для демона данных. Формат этих файлов должен соответствовать формата записей стандартных ресурсов (Standard Resource Record Format).

Демон named в AIX также поддерживает записи ресурсов для почты типа MB (mailbox domain name), MR (mail rename domain name), MG (mail group member), MINFO (mailbox or mail list information) и MX (mail exchange).

Приложения пользователя AIX/6000 включает в себя программы host и nslookup. В AIX/6000 также можно воспользоваться программой dig для запросов к серверам имен.

Настройка клиентской части

Как уже было отмечено, программное обеспечение TCP/IP одновременно поддерживает и клиента DNS, и файл hosts. Содержимое файла /etc/resolv.conf мы рассмотрели уже выше. Файл hosts отвечает за "плоскую" систему именования. Местонахождение этого файла зависит от операционной системы (AIX - /etc/hosts, DOS и Windows - ETC\HOSTS, NetWare - SYS:\ETC\HOSTS).

Формат его очень прост: он состоит из строк, каждая из которых определяет один хост: <IP-адрес> <имя> [<псевдоним> ... <псевдоним>]

Обратите внимание, что файл hosts может содержать имена в доменном формате.

Настройка сервера имен

Среди администраторов сетей бытует мнение, что DNS следует использовать только при наличии подключения к Internet. Но DNS позволяет упростить администрирование локальных сетей TCP/IP независимо от того, имеют они выход в Internet или нет. При отсутствии DNS добавление компьютера в локальную сеть приводит к тому, что в файл hosts каждого хоста необходимо ввести информацию о новом компьютере. Это нетрудно, если машин в сети немного. А если их десятки или сотни? При использовании DNS вся процедура сводится к добавлению одной-двух строк в файлы базы DNS на первичном сервере имен. После этого хосты сети будут распознавать новый компьютер по имени автоматически. Если по каким-либо причинам необходимо изменить IP-адрес или имя хоста, то с DNS сделать это довольно просто. Кроме того, использование DNS значительно облегчает процедуру подключения корпоративной сети к Internet.

Стандарты DNS

Настройка базы DNS задается в специальных текстовых файлах на серверах имен. Форматы записей в этих файлах регламентируются стандартами, изложенными в документах RFC (Request For Comments). Они разрабатываются "законодательным" органом Internet - IETF (Internet Engineering Task Force). Однако сам набор файлов и порядок их загрузки на серверах имен RFC не регламентируется. Для этого существует стандарт de facto под названием BIND (Berkley Internet Name Domain). Данная спецификация была разработана в университете Беркли и впервые реализована в BSD Unix. Подавляющее большинство серверов имен поддерживают спецификацию BIND.

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

В общем случае порядок запуска серверов имен следующий: сначала создаются файлы базы DNS (напрямую или через административные утилиты), а затем запускается сервис DNS (в AIX - демон named).

Формат записей в файлах базы DNS

В файлах базы DNS серверов имен используется так называемый формат записи стандартных ресурсов (Standard Resource Record Format). Выглядит этот формат следующим образом:

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

<Name> - имя описываемого ресурса. Оно зависит от поля <Type> и может обозначать домен, зону управления, имя хоста и т. д. Если поле <Name> пустое, то в качестве него используется последнее заданное поле <Name> (в предыдущих записях).

<TTL> - время жизни (в секундах). Определяет, как долго клиент DNS будет хранить запись в кэш-памяти. Если данное поле пустое, то в качестве <TTL> берется значение поля <Minimum>, задаваемое в записи SOA (см. ниже).

<Class> описание класса используемых протоколов. Для Internet (TCP/IP) значение этого поля - IN. Если поле пустое, то в качестве него используется последний заданный класс.

<Type> - поле, задающее тип ресурса записи. Возможные значения этого поля приведены в разделе "Типы ресурсов".

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

Следующие символы в записях имеют специальное значение (ниже перечислены некоторые из этих символов).

. Отдельно стоящая точка в поле <Name> обозначает текущий домен.

@ Отдельно стоящий символ "@" в поле <Name> обозначает текущий исходный домен.

( ) Скобки используются для размещения поля <Data> на нескольких строках (когда поле <Data> занимает несколько строк).

* Метасимвол. Заменяет любой набор символов.

; Символ комментария. От этого символа и до конца строки информация игнорируется.

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

Типы ресурсов

Тип ресурса задается в поле <Type> записи ресурса. Типов ресурсов множество. Полный их список можно узнать в соответствующих RFC (см. "Дополнительную информацию"). Ниже приводятся наиболее используемые типы.

? SOA Начало полномочий (управления) сервера имен.
? NS Сервер имен.
? A Адрес хоста.
? CNAME Каноническое имя. Используется для задания псевдонимов.
? HINFO Информация о хосте.
? MX Почтовый шлюз.
? PTR Указатель.

SOA (начало полномочий)

Запись с ресурсом типа SOA обозначает начало зоны управления сервера имен. Зона управления действует до следующей записи SOA.

Здесь поле <Data> является составным и включает поля <Origin>, <Person>, <Serial> и т. д.

<Person> Почтовый ящик лица, ответственного за зону. Данное поле формируется аналогично электронному адресу, но вместо символа "@" ставится точка (т. е. alex@komtek.dp.ua заменяется на alex.komtek.dp.ua).

<Serial> Номер версии зоны. Когда производятся изменения в зоне, то это число необходимо увеличить. Именно по данному полю ориентируется вторичный сервер имен, определяя необходимость обновления информации по зоне.

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

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

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

<Minimum> Значение TTL в записях ресурсов данной зоны по умолчанию, т. е. когда поле <TTL> пустое.

NS (сервер имен)

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

<Domain> обозначает домен, а <Server> - имя сервера имен. В примере показывается, что серверы srv1.komtek.dp.ua и srv2.komtek.dp.ua представляют собой серверы имен домена komtek.dp.ua.

A (адрес)

Запись с ресурсом типа A служит для задания сетевого адреса хоста. Здесь <Host> - доменное имя хоста, а <Address>- его IP-адрес.

CNAME (каноническое имя)

Запись с ресурсом типа CNAME применяется для указания псевдонима хоста. <Nickname> обозначает псевдоним, а <Host> - официальное (каноническое) имя хоста.

HINFO (информация о хосте)

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

Поле <Host> обозначает доменное имя хоста, <Hardware> - аппаратную платформу, <Software> - ОС хоста. Значения полей <Hardware> и <Software> стандартизированы, их следует брать из RFC 1700.

MX (почтовый шлюз)

Так как не на всех хостах запущен сервер e-mail, то для отдельных хостов или всего домена запись с ресурсом типа MX позволяет определить почтовый шлюз - компьютер, куда будет направляться электронная почта, предназначенная для этих хостов. Поле <Name> обозначает домен или имя хоста, для которого устанавливается почтовый шлюз. <Host> - имя хоста почтового шлюза. <Reference> задает приоритет доставки, при этом ноль означает самый высокий приоритет.

В примере показано, что если почта предназначена для домена komtek.dp.ua, то она доставляется на машину unix1.komtek.dp.ua. Если же почта предназначена для любого компьютера домена, имя которого оканчивается на -dos, то она направляется на unix2.komtek.dp.ua.

Таким образом, письмо, отправленное по адресу:

Если администратор определяет несколько записей MX, то для указания порядка опроса почтовых шлюзов используется число (в примере - 10) первым опрашивается шлюз с меньшим числом.

PTR (указатель)

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

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

Для того чтобы облегчить эту задачу, в пределах общей доменной структуры был создан вспомогательный домен. Он имеет специальное название IN-ADDR.ARPA. Внутри этого домена существуют поддомены для каждой IP-сети. Имена этих поддоменов основаны на сетевых адресах, причем байты (октеты) IP-адресов представлены в обратном порядке.

Например, сеть cso.uiuc.edu имеет сетевой адрес 128.174 (вернее, 128.174.0.0, это IP-сеть класса B). Внутри этой сети имеется хост vmd.cso.uiuc.edu с IP-адресом 128.174.5.98. Тогда для всей сети вспомогательный домен будет 174.128.in-addr.arpa. Имя хоста в этом домене будет 98.5.174.128.in-addr.arpa.

Ресурсы с записью типа PTR служат для отображения этих специальных доменных имен в обычные. Поле <Special-name> обозначает специальное доменное имя (в домене IN-ADDR.ARPA), а поле <Name> - официальное доменное имя хоста.

Вспомогательный домен IN-ADDR.ARPA используется также для указания шлюза (маршрутизатора) для сетей. Шлюз представляет собой хост, соединяющий несколько IP-сетей. Для него существуют обычные записи PTR хоста, но, кроме того, имеются специальные записи PTR, представляющие IP-сети целиком. Эти записи включают только первые 1, 2 или 3 байта (октета) IP-адреса сети в зависимости от класса IP-сети (A, B или C).

Допустим, имеется шлюз gw.komtek.dp.ua, объединяющий сети класса A, B и C и имеющий соответствующие IP-адреса: 12.2.0.7, 129.14.1.3 и 194.140.13.2. Ниже представлены записи A и PTR для данного шлюза.

Спецификация BIND

Как уже отмечалось, стандартом de facto в описании состава файлов DNS и порядка их загрузки на сервере имен является спецификация BIND. Она поддерживается во всех Unix-системах, в NetWare (программные продукты Novell NFS Services, FTP Services, NetWare/IP) и ряде других систем.

Согласно данной спецификации существует файл загрузки базы DNS. В Unix-системах обычно это файл /etc/named.boot, в NetWare - SYS:ETC\NAMED.CFG, который загру-жается при запуске сервиса DNS на сервере имен.

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

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

1. directory <Path> Устанавливает каталог хранения файлов базы DNS, если не указаны абсолютные пути к файлам. Пример: directory /etc

2. domain <Domain> Определяет домен по умолчанию для данного сервера имен. Пример: domain komtek.dp.ua

3. primary <Domain> <FileName> Показывает, что сервер имен является первичным для домена <Domain> и что база домена хранится в файле <FileName>. Пример: primary komtek.dp.ua /usr/named.data

4. secondary <Domain> <IP-1> [<IP-2>...] <FileName> Указывает, что данный сервер имен является вторичным для домена <Domain>. Первичные серверы расположены по IP-адресам <IP-1>, <IP-2> и т. д. Данный вторичный сервер запрашивает по порядку первичные серверы и копирует полученную с первого ответившего первичного сервера информацию в файл <FileName>. Пример: secondary komtek.dp.ua 192.168.1.3 named.bak

5. cache <Domain> <FileName> Указывает, что данный сервер является кэш-сервером имен для домена <Domain>. Параметры кэш-сервера (прежде всего адреса и имена серверов имен корневого домена) считываются из файла <FileName>. Пример: cache . named.ca

6. Строка, начинающаяся с символа ";", считается комментарием. Кстати, для обозначения полного доменного имени в файле загрузки ставить точку в конце имени не обязательно: здесь все имена считаются полными.

Пример реализации DNS в локальной сети

Подводя итоги, рассмотрим пример настройки DNS на серверах имен типичной локальной сети TCP/IP. В примере принято, что локальная сеть подключена к Internet. В то же время показываются настройки, когда локальная сеть не имеет выхода в Internet. IP-адреса сетей и хостов, а также доменные имена вымышленные и приведены лишь для простоты понимания.

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

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

Рассматриваемая локальная сеть состоит из двух IP-сетей класса C: 194.170.12.0 и 194.170.13.0. Допустим, эти сети образуют один домен komtek.dp.ua.

IP-сети объединяют шлюз (маршрутизатор) gw с адресами: 194.170.12.1 и 194.170.13.4. Подключение к Internet также происходит через данный шлюз.

В домене имеется первичный сервер имен srv1 (194.170.12.2) и вторичный сервер имен srv2 (194.170.13.3), а также ряд хостов: host1, host2, host3.

Хост mail (194.170.13.2) является почтовым шлюзом для всего домена, к тому же у него есть псевдоним host4.

Ниже представлены состав и содержимое базы DNS для первичного сервера имен srv1.komtek.dp.ua и для вторичного сервера srv2.komtek.dp.ua.

СОСТАВ И СОДЕРЖИМОЕ БАЗЫ DNS НА ПЕРВИЧНОМ СЕРВЕРЕ SRV1

СОСТАВ И СОДЕРЖИМОЕ БАЗЫ DNS НА ВТОРИЧНОМ СЕРВЕРЕ SRV

Как для первичного, так и для вторичного сервера имен, в случае если локальная сеть не имеет выхода в Internet, следует убрать строку cache в файле /etc/named.boot и удалить файл /etc/named.ca.

Об именах и адресах серверов имен корневого домена, перечисленных в файле /etc/named.ca, необходимо справиться у Internet-провайдера. Кроме того, Internet-провайдер должен внести данные о серверах имен srv1.komtek.dp.ua и srv2.komtek.dp.ua в свою базу DNS, чтобы обеспечить доступ из Internet к машинам домена komtek.dp.ua.

Вспомогательный домен 0.0.127.in-addr.arpa, а также хост localhost (127.0.0.1) в каждой из зон необходимы для создания локальной "петли" TCP/IP.

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

Контроль за системой адресации

Управление адресацией и сервером имен систем по протоколу IP достаточно сложно и часто приводит к ошибкам. Двойные идентификаторы и ошибки конфигурации приводят к простоям и дорогостоящей диагностической работе. Административные системы построенные на ручном конфигурировании очень трудоемки. Поэтому автор посчитал необходимым уделить этой проблеме особое внимание.

Постановка задачи

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

По этим причинам, управление адресами IP и сервером имен (DNS) может стать очень трудо?мким для администраторов. Ранее усложняло эту проблему и тот факт, что не имелось каких-либо автоматизированных инструментальных средств для избежания дублирования IP адресов и синхронизации адресов IP с сервером имен. Поэтому для удовлетворения этой потребности в 4-й версии AIX встроена поддержка динамического протокола конфигурации узлов (DHCP), и динамического сервера имен (DDNS).

DHCP Краткий обзор

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

DHCP делает управление TCP/IP сетями намного проще и намного более точным за счет того, что эта система функционирует автоматически, без ручного вмешательства администратора. В DHCP, диапазон присваиваемых адресов IP содержится на DHCP сервере. DHCP автоматически назначает адреса IP из этого диапазона индивидуальным узлам. Эта система также обеспечивает узлы параметрами конфигурации, такими, как gateway по умолчанию, адрес сервера имен, параметры X-window и другие, определяемые пользователем значения.

Как работает модель DHCP

Решение DHCP основано на двухуровневой модели клиент/сервер. Узел сети должен быть dhcp-доступным. Процесс можно описать следующим образом:

1. Клиент вводит сеть IP в состоянии инициализации и передает по широковещательное сообщение по всем доступным сетям с запросом на получение IP адреса и описанием требований к соединению (DHCPDISCOVER).

2. Агент ретрансляции BOOTP обнаруживает это сообщение и передает его всем доступным серверам DHCP для обработки.

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

4. Клиент получает все ответы от серверов и определяет наилучшее предложение используя встроенный алгоритм.

5. Затем клиент отправляет выбранному серверу запрос на получение адреса и информации конфигурации (DHCPREQUEST).

6. В заключение, выбранный сервер DHCP посылает в сеть сообщение о подтверждении получения обслуживания (DHCPACK). После этого все другие сервера, которые не были выбраны, освобождают адреса IP, которые они предложили клиенту и возвращаются в режим опроса сети, ожидая следующий пакет DHCPDISCOVER.

7. После того, как сервер DHCP получает подтверждение от клиента DHCP, сервер автоматически модифицирует сервер имен DNS в соответствии с этим адресом IP.

8. Так как адрес IP, назначенный клиенту выдан только временно (арендуется) он должен быть периодически возобновляться, клиент стартует таймер и устанавливает его на половину продолжительности арендного договора.

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

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

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

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

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

DHCP в AIX V4

Реализация клиента и сервера DHCP в AIX состоит из следующих модулей:

? Демон клиента dhcpcd
? Демон сервера dhcpsd
? Демон агента ретрансляции dhcprd

Текущая реализация DHCP для RS/6000 поддерживает такие LAN-основанные протоколы, как Ethernet, Token-Ring и FDDI. Эта реализация как клиента, так и сервера DHCP соответствует всем доступным RFC и также была проверена на совместимость с другими клиентами и серверами DHCP.

Таблица ниже показывает перечень продуктов, способных работать с реализацией DHCP для AIX.

Каждая машина RS/6000 может выполнять одну из трех ролей: роль сервера, роль клиента или роль агента передачи сообщений BOOTP.

Конфигурирование сервера DHCP

Сервер DHCP генерирует и предлагает адреса IP, основанные на наборе предопределенных атрибутов или сред. Пользователи могут создавать эти области определения, редактируя ASCII файл или используя графический интерфейс пользователя (GUI).

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

Внутри сервера DHCP, представление информации клиента используя ключи. С этими ключами сервер DHCP может назначать IP адреса клиенту.

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

Второй ключ - идентификатор клиента. Идентификатором клиента может быть имя узла TCP/IP или MAC адрес. Сервер может использовать идентификатор клиента, чтобы обеспечить более специфические возможности.

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

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

? специфический клиент;
? класс;
? сеть;
? глобальная переменная.

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

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

Сценарий конфигурации сервера

В нижеследующем DHCP сценарии конфигурации сервера фирма "Х" имеет шесть IP сетей и имеет назначенные Центром Информации Сети Internet (InterNIC) сети диапазон адресов IP один класса C и один класса B.

Общие пользователи фирмы "Х" сгруппированы как или динамические или статические.

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

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

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

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

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

Диапазон - от 2 до 240, потому что 1 используется маршрутизатором "Х" и не должен быть назначен, и адреса выше 240 зарезервированы для будущих статических пользователей.

(Если второй параметр не определен, это подразумевает, что можно присвоить все адреса.)

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

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

Конфигурация сервера состоит из инициализации всех параметров DHCP для всех потенциальных клиентов.

Данные конфигурации сохраняются в файле /etc/dhcpsd.cnf.

Сервер может стартовать автоматически используя последовательность, размещенную в /etc/rc.tcpip или, используя SMIT.

# Smit tcpip Further Configuration - > Server Network Services - > Other Available Services - > Dhcpsd Subsystem

Графический интерфейс

Графический интерфейс сервера DHCP помогает спрятать сложность синтаксиса файла конфигурации и упрощает его конфигурацию. Для старта графического интерфейса сервера используется команда dhcpsconf.

Панель графического интерфейса состоит из трех основных рабочих областей:

Option list - список выбираемых опций, поддерживаемых сервером
Key list - значения, которые описывают клиента, включая сетевую позицию, класс и идентификатор
Main window list - резюме опций для каждого ключа

Конфигурирование DHCP клиента

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

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

Относительно сети TCP/IP - статические маршруты, сервер имен NetBIOS и т.п.

Относительно услуг сервера - управляющая программа локального принтера и спулера (LPR), сервер имен (DNS), сетевой сервер времени (NTP) и т.п.

Конфигурационная информация содержится в двух файлах:

dhcpcd.ini - файл конфигурации DHCP, состоящий из директив, которые могут быть определены для клиента. Содержит список привилегированных опций.

/etc/rc.net - информация для интерфейса запуска.

Клиент устанавливается используя SMIT нижеследующим образом:

Команды SMIT могут также использоваться, чтобы конфигурировать DHCP для TCP/IP и запускать управление демоном клиента следующим образом:

smit tcpip -> Further Configuration - > Server Network Services - > Other Available Services - > Dhcpcd Subsystem

Комбинации параметров для заявлений клиента

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

При использовании параметра <строка>, каждая <строка> должна быть уникальна. Строка клиента - устройство-зависимая строка, которая может использоваться, чтобы идентифицировать специфическое устройство соответствующим MAC-адресом.

Строка дает возможность серверу DHCP идентифицировать клиента и обеспечить его корректное обслуживание.

Синтаксис для заявления клиента показывается ниже:

Сервер DHCP	Клиенты DHCP
AIX V4.2	MacOS, Windows 3.x, Windows 95,Windows NT 3.5, Chameleon,FTP Software, AIX V4.1.4
AIX V4.1.4	OS/2 Warp Connect
OS/2 Warp Server, SUN Solaris,FTP Software, Competitive Automation	AIX V4.2, AIX V4.1.4

Подустройство	Низкая ?мкость	Перематывание(удержание)на начало при открытии	Перематывание на начало при закрытии операции
/dev/rmtX	нет	нет	да
/dev/rmtX.1	нет	нет	нет
/dev/rmtX.2	нет	да	да
/dev/rmtX.3	нет	да	нет
/dev/rmtX.4	да	нет	да
/dev/rmtX.5	да	нет	нет
/dev/rmtX.6	да	да	да
/dev/rmtX.7	да	да	нет