Алексей Быков. Системное администрирование IBM AIX version 4.x

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

Особенно интересно ознакомиться с технологиями, применяемыми в AIX, в всязи с объявленным проектом Монтерей (IBM, SCO и др.) по созданию версии UNIX для платформы Intel в которой будут применены наиболее сильные технологии AIX, такие как инструменты системного и сетевого администрирования, подсистема управления дисками.

Книга "Системное администрирование IBM AIX Version 4" дает только обзор решения базовых задач администрирования с помощью AIX.

Книга обобщает практический опыт с системами на базе AIX в процессинговом центре по обслуживанию системы безналичных расчетов на основе смарт-карт и в корпоративной информационной системе ЗАО "Комтек". Эти системы выполняют различные функции, от сервера приложений (СУБД Oracle) до сервера intranet. В этой книге, в силу специфики работы автора (см. Об авторе), делается упор на использование AIX в сфере корпоративных информационных систем.

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

Нижеследующие замечания являются личным мнением автора.

Операционная система IBM AIX - это по-прежнему UNIX, операционная система, которая вселяет страх и неприязнь в сердца приверженцев персональных компьютеров. Этот страх и неприязнь вызваны, прежде всего, тем, что традиционные системы UNIX требуют от пользователя и, тем более, от администратора, нетривиальных усилий практически по всем аспектам работы с операционной системой, начиная с процесса установки до настройки производительности. Такая сложность работы связана с общей концепцией UNIX, представляющей собой больше "конструктор" для создания той операционной системы, которая нужна пользователю, чем готовую к применению ОС. И за эту гибкость в конфигурировании приходится платить сложностью настройки и работы с нею. Коммерческие же версии UNIX представляют собой уже, в большей или меньшей степени, настроенные под различные категории пользователей варианты традиционного UNIX. Вопрос в том, как конкретная фирма понимает степень настроенности этой ОС и какие возможности добавлены в нее.

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

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

Большой проблемой для распространения AIX, наряду с предубеждениями пользователей ПК, является недостаточная маркетинговая активность корпорации IBM по продвижению систем RS/6000 с операционной системой AIX. Иногда кажется, что в IBM считают, раз они создали технически более совершенное решение, чем конкуренты, то это само по себе должно продвигать на рынке это решение. Реалии современного мира не таковы, на что явно указывает успех компании Microsoft по продвижению своих продуктов. Отечественному потребителю мало доступна информация по продуктам IBM. Это является одной из причин, почему основными пользователями её продуктов являются люди, которые в силу разных ситуаций, уже столкнулись в своей работе с этой превосходной продукцией. Для них, действительно, уже не нужно применение маркетинговых "хитростей".

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

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

Введение

Для решения различных задач по обработке информации в информационных системах существует множество решений и, по мнению автора, для каждой задачи есть оптимальное решение. Одним из таких решений является применение компьютеров IBM RS/6000 с операционной системой AIX.

Когда рекомендуется применять системы RS/6000 с операционной системой AIX в корпоративных информационных системах? Тогда, когда необходимо обеспечить более высокий, по сравнению с системами и серверами на основе персональных компьютеров, уровень надежности, производительности, масштабируемости и безопасности. Тогда, когда нам нужно обеспечить соответствие открытым стандартам и развитые коммуникационные возможности.

Общие характеристики и преимущества AIX четвертой версии

Четвертая версия AIX основана на традиционной операционной системе UNIX и стандартах X/Open XPG4. Она соответствует Portable Operating System Interface for Computer Environments (POSIX) IEEE 1003.1-1990 и модели распределенных вычислений IBM Open Blueprint, а также спецификации Single UNIX (SPEC 1170) и имеет марку X/Open XPG4 UNIX 95. Наряду с соответствием этим жизненно важным стандартами в AIX добавлены различные возможности для использования в различных сферах применения информационных технологий: от лабораторий до коммерческих систем. Четвертая версия AIX имеет много свойств популярных в мире мейнфреймов, таких как высокая системная интегрированность, гибкое, мощное и относительно простое системное управление, а также средства обеспечения высокой надежности и доступности системы.

Характеристики и преимущества четвертой версии AIX:

Полностью распараллельное ядро системы Является основой для поддержки распаралельных приложений для многопроцессорных систем.

Бинарная совместимость с основными приложениями AIX 3.2 Помогает обновлять систему безболезненным способом. Может помочь снизить затраты на поддержку разработчиками используемых приложений.

Масштабируемость Общий код компиляции для систем на базе процессоров POWER, POWER2, P2SC и PowerPC обеспечивает масштабируемость и предоставляет возможность получить преимущества новых систем RS/6000 SP, SMP и на базе процессора PowerPC.

Возможность установки клиентского и серверного вариантов Вы устанавливаете только те функции, которые вам необходимы (см. Пакеты AIX).

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

Основана на X/OPEN XPG4 и сертифицирована на соответствие UNIX 95; соответствует Single UNIX Specification (SPEC1170) Возможность переноса приложений между гетерогенными UNIX платформами. Поддержка согласованности со стандартами открытых систем.

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

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

AIX интегрирован с CDE Предлагает соответствие стандартным промышленным интерфейсам (см. Common Desktop Environment (CDE)). Может помочь росту продуктивности пользователя использующему простые в использовании возможности интерфейса.

Соответствие уровню безопасности C2 Обеспечивает высочайшую степень безопасности доступа к системе (см. Безопасность).

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

Network Installation Manager (NIM) Простое распространение и установка программного обеспечения на сетевых клиентах.

Сертификация ITAA на решение проблемы 2000 года Правильно обращается с данными и файлами данных после 31 декабря 1999 года.

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

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

Способность LVM к расслоению (striping) диска Поддержка высшей скорости доступа к данным, использующим технологию программного расслоения диска (см. Расслоение (RAID 0)).

Поддержка IBM Network Station Предложена поддержка нового семейства сетевых компьютеров. Позволяет иметь доступ к приложениям Java и Internet.

Welcome Center Предлагается дружественное введение в мир RS/6000 и AIX. Облегчает электронный доступ к важным ресурсам, таким как, например, услуги по поддержке.

Дополнительные характеристики и преимущества версии AIX 4.3

Поддержка 64-bit Поддержка бинарной совместимости с основными 32-разрядными приложениями для защиты инвестиций в существующее аппаратное и программное обеспечение. Поддерживается одновременное выполнение 32-х и 64-ти битных приложений на 64-битной аппаратуре. Предоставляется окружение для разработки 64-битных приложений. Поддерживается до 16GB реальной памяти на 64-битной аппаратуре.

Web-ориентированное системное управление Позволяет управлять системой AIX с любого места в Интернет/интранет с помощью любого броузера поддерживающего Java 1.1

Документация на базе HTML Большая часть документации доступна в формате HTML (некоторые документы остались в формате Adobe Acrobat PDF или troff). Предлагается простой доступ к документации с помощью любого web-броузера.

Java Developer Kit (JDK) 1.1.2 с компилятором IBM Just-In-Time (JIT) Включает в себя полный комплект средств разработки. Компилирует байт-коды Java в "родные" коды компьютера для выполнения Java программ с наивысшей производительностью (ускорение в 25 раз по сравнению с интерпретатором байт-кода Java).

Поддержка протокола Internet Protocol Version 6 (IPV6) Преодоление ограничения адресации, свойственные протоколу IP. Увеличение безопасности IP с помощью избыточной маршрутизации, динамической маршрутизации и туннелирования.

Предлагает IPsec аутентификацию и безопасность для IPV4 и IPV6.

Поддержка сервера LDAP Предлагается Secure Sockets Layer (SSL) Version 3 для шифрования данных и аутентификации используя сертификатов публичных ключей X.509v3. Анонсируются продукты для простой разработки приложений каталога LDAP.

2000 Ready ОС AIX 4.3 готова к 2000 году и не совершает никаких ошибок при переходе границ тысячелетия ни в 2000, ни в 2001 годах. Кроме того, она корректно учитывает тот факт, что 2000 год будет високосным.

Улучшения Print spooler Предлагается надежная сетевая поддержка сети с возможностью одновременных 1000 работ печати.

X11R6 Расширенные функции Xwindow с защищенными 64-битными клиентскими библиотеками для разработки графических приложений.

Интерфейсы прикладного программирования (API) OpenGL, GL 3.2 и graPHIGs Позволяет разрабатывать комплексные приложения 3D. Предоставляется возможность простого и совместного использования графических API, которые могут быть использованы в сети.

Инструменты анализа/контроля производительности Для системного администратора предоставляются комплексные инструменты статистического анализа производительности для локальной системы AIX.

CacheFS из набора ONC+ Предоставляет возможность быстрого доступа к файлам, когда используется монтирование Network File System.

Прямой ввод/вывод Для производительной работы критических приложений предоставляется скоростной ввод/вывод.

Улучшения производительности Telnet Предоставляется улучшение производительности от 40% до 60%.

Unicode 2.0 Позволяет разрабатывать приложения на базе UCS.

Уровень безопасности C2 Система защиты разработана для соответствия уровню безопасности согласно спецификаций C2 US DOD, но пока официально не сертифицирована (ОС AIX 4.2.0 сертифицирована по европейскому стандарту ITSEC на соответствие уровню безопасности F-C2/E3).

Bonus Pack Version 4.3 Усиливает AIX как платформу для сетевых вычислений. Комплект приложений, который даёт пользователям инструменты, которые могут быть ценными в их работе:

ћ Ultimedia Services для AIX
ћ Adobe Acrobat Version 2.01
ћ Lotus Domino Go Webserver 4.6
ћ Network Station Manager (NSM) Version 2.5
ћ IP Security xx-bit DES
ћ DCE Client Version 2.1
ћ Netscape Navigator 3.0.3
ћ Netscape Navigator 4.0.3 (только броузер)
ћ Netscape FastTrack Server 2.0.1
ћ LDAP-SSL Version 3 xx-bit encryption

Процессоры и система RS/6000

Операционная система AIX работает на платформе IBM RS/6000, а также устанавливается на серверы некоторых других производителей (например, Apple Computer) с процессорами PowerPC. Малое количество поддерживаемых платформ, с одной стороны, ограничивает сферу применения этой операционной системы, но, с другой стороны, позволяет обеспечивать более высокую степень совместимости с аппаратными средствами. Не следует также забывать, что семейство IBM RS/6000 представлено очень широким спектром компьютерных систем, от ноутбука до массово-параллельных суперкомпьютеров IBM RS/6000 SP.

И прежде всего эта платформа характеризуется использованием процессоров двух семейств: Power и PowerPC. Оба семейства процессоров построены на технологии RISC (Reduced Instruction Set Cycles). Эта технология позволяет процессору выполнять несколько инструкций за один такт, поэтому, прямое сравнение характеристик процессоров по рабочей тактовой частоте с процессорами, построенными по технологии CISC (например, процессоры Intel), прямо скажем, не правомерно. Процессоры семейства Power оптимизированы на исполнение команд с плавающей запятой (например, программ научных расчетов или программ обработки графической информации). Процессоры семейства Power используются в массово-параллельных системах IBM RS/6000 SP. Процессоры семейства PowerPC оптимизированы на выполнение инструкций с фиксированной точкой (например, программы работы с базами данных).

Классическая система RS/6000

Так называемая классическая система RS/6000 характеризуется применением микроканальной шины MCA (MicroChannel) разработки IBM и SCSI-дисков. Основным визуальным признаком является наличие специального переключателя, от положения ключа в котором, зависит режим загрузки операционной системы.

Система RS/6000 с шиной PCI

Новые системы RS/6000 комплектуются шиной PCI, которая является недорогой и более распространенной альтернативой шине MCA. Использование специальных мостов позволяет компьютерам с шиной PCI использование адаптеров для шин ISA (стандартно поставляется) и MCA, EISA или NuBus (шина, используемая в компьютерах Apple Macintosh).

Диски RS/6000

Система RS/6000 может содержать как внутренние дисковые системы, так и внешние. Внешне подключаемые диски могут быть как одиночными дисками, так и дисковыми подсистемами, которые содержать в себе более одного диска. Также доступны диски, извлекаемые из дискового устройства. Их удобно применять для переноса больших объемов информации. Стандартно диски подключаются по протоколу SCSI. Для лучшей производительности, управляемости, а также при необходимости формирования больших дисковых пространств доступны диски, подключаемые по протоколу последовательного интерфейса SSA.

Подсистема ввода/вывода

Стандартная система ввода/вывода RS/6000 содержит встроенные в системный блок два последовательных порта, один параллельный порт и порты для подключения клавиатуры, мыши и дигитайзера. Для подключения асинхронных устройств (например, терминалов и асинхронных принтеров) доступны 8-ми, 16-ти и 128-ми портовые асинхронные адаптеры. Для связи с другими системами и создания компьютерных сетей доступно множество адаптеров, которые поддерживают протоколы Token-Ring, Ethernet, FastEthernet, FDDI, Fiber Channel Switch, ATM, X.25 и другие. Для прямого подключения к мейнфреймам существует адаптер протокола SDLC.

Конфигурация рабочей станции

Одной из основных конфигураций RS/6000 является конфигурация POWERStation, - однопользовательской графической рабочей станции, используемой для выполнения соответствующих графических приложений (например, CAD/CAM). В этой конфигурации в систему RS/6000 встроен графический адаптер, к которому подключается графический дисплей. Существует множество различных графических адаптеров, которые различаются скоростью, поддерживаемым разрешением, количеством цветов, 2D и 3D поддержкой и т.п. Графический дисплей (включительно до 23-х дюймового IBM PowerDisplay) должен поддерживать режимы графического адаптера.

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

Многопользовательская система

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

Сетевая система

Более комплексная система может содержать несколько RS/6000 и других устройств, таких как персональные компьютеры, подключенные к локальной сети типа Ethernet или Token-Ring. В этом случае RS/6000 требуется соответствующий коммуникационный (сетевой) адаптер. Естественно, что для такой системы не исключена возможность подключения ASCII устройств.

XStation

XStation (X станция) это подсоединенная по локальной компьютерной сети графическая дисплейная станция, которая состоит из дисплея, клавиатуры, мыши и содержит собственную видеопамять (не оперативную память) и не имеет собственных дисков. Приложения выполняются на одном или нескольких RS/6000 или других компьютерах, на которых выполняется программа XStation Manager.

Бездисковые рабочие станции

Ранее, когда дисковые подсистемы были очень дорогими, в целях экономии применялись бездисковые рабочие станции. Эти рабочие станции имеют собственный процессор и оперативную память, исполняют локально операционную систему и приложения и могут иметь подключенные к ней терминалы, но не имеет локальной дисковой подсистемы или имеют дисковую подсистему малого объема, которая используется только как пространство загрузки, пейджинга и т.п. Четвертая версия AIX предлагает как серверную, так и клиентскую поддержку бездисковых рабочих станций. Сервером бездисковой станции может быть также другая UNIX система с соответствующей поддержкой TCP/IP и NFS. Клиентами могут быть компьютеры RS/6000, которые могут загружаться по сети, а также бездисковые станции Sun 3 или Sun 4. Серверная поддержка включает в себя поддержку удаленной загрузки, удаленные файловые системы, пейджинговое пространство и свободное пространство и использует NFS V4, а также поддержку удаленной установки. В настоящее время использование бездисковых рабочих станций, по мнению автора, неоправданно.

Сетевые компьютеры (Network Computers)

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

Роль системного администрирования

Цель системного администрирования

Основной целью системного администрирования является приведение информационной системы в соответствие целям и задачам предприятия или организации.

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

Система дает возможность администратору уделить больше внимания на решение вопросов типа "что сделать?", а не "как сделать?".

Обязанности системного администратора

ћ Установка и конфигурация аппаратных устройств;

ћ Архивирование (резервное копирование) информации;

ћ Создание и управление счетами пользователей;

ћ Документирование системной конфигурации.

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

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

Система безопасности AIX предоставляет возможности для решения администраторских задач в основном пользователю root (а также некоторым пользователям из администраторских групп для выполнения особых задач (см. Группы системных администраторов)).

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

Администратору рекомендуется входить в систему как обычному пользователю и при необходимости воспользоваться привилегиями root, использовать команду su. Эта команда, набранная без параметров, при вводе соответствующего пароля дает пользователю привилегии root. После выполнения задач администрирования рекомендуется закрывать сеанс с привилегией root командой exit или нажатием комбинации клавиш <Ctrl-D>.

Рекомендуется использовать полное сетевое имя команды su: /bin/su, а также ограничение этой команды и бюджета root определенными терминалами. Подробно об этом читайте в главе "Безопасность".

Примечание: команда su [имя_пользователя] позволяет получить полномочия любого пользователя, пароль которого вы знаете.

Установка

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

Планирование

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

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

Способы установки

Существует несколько различных способов загрузки и установки базовой операционной системы (BOS): Загрузка и установка с ленты (4mm, 8mm, QIC120, QIC525) требует наличия как минимум 16 мегабайт оперативной памяти.

Метод установки с ленты не применяется для RS/6000 с шиной PCI. На этих компьютерах загрузка и установка BOS производится с CD-ROM. Для установки с CD-ROM требуется только 8 мегабайт оперативной памяти.

Сетевая установка возможна при использовании AIX Network Installation Manager (NIM). Такой вид установки позволяет администратору управлять установкой BOS и дополнительного программного обеспечения на один или несколько компьютеров по сети.

При покупке новых систем вы можете заказать в IBM компьютер RS/6000 с уже установленной BOS.

Пакеты AIX

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

Клиентский пакет содержит функциональные возможности для работы с RS/6000 в роли сетевого клиента без выполнения функций сервера. Поддерживается только 1-2 клиента системы + пользователь root. Такие системы используются в основном как клиент сети, производительная рабочая станция, сервер печати, сервер имен, сервер сбора данных или маршрутизатор.

Серверный же пакет содержит полные функциональные возможности для работы RS/6000 в роли сервера. Такая система используется в основном для решения следующих задач:

ћ Сервер приложений;
ћ Файловый сервер сети;
ћ Сервер печати;
ћ Сервер имен;
ћ Сервер коммуникаций и Internet;
ћ Маршрутизатор;
ћ Сервер лицензирования;
ћ Сервер разработки приложений;
ћ Сервер вычислений;
ћ Для комбинации вышеперечисленного.

Этот продукт разработан как многопользовательская система. По умолчанию предлагаются серверные пакеты на 1-2 пользователей и пользователя root. Дополнительные пользовательские лицензии необходимо докупать отдельно в соответствии с политикой лицензирования IBM.

Установка на классическом RS/6000 (шаг 1)

ћ Включите ключ в позицию service.
ћ Включите систему или нажмите дважды кнопку reset.
ћ Вставьте ленту в лентопротяжное устройство или CD-ROM в дисковод. Система должна загрузится из первого, указанного в списке загрузки устройства, в котором находится носитель.

Установка на RS/6000 с шиной PCI (шаг 1)

ћ Включите все периферийные устройства (SCSI или SSA дисковые системы).
ћ Включите систему.
ћ Вставьте CD-ROM в дисковод. Система будет пытаться загрузиться с первого, указанного в списке загрузки устройства в котором вставлен носитель.

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

Выбор консоли и определение языковой среды установки (шаги 2 и 3)

******* Please define the System Console. *******

Type a 2 at this terminal and press <Enter>
if you want this display to be the System Console.

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

Предварительно должны быть установлены следующие характеристики терминала:

Тип терминала (Terminal type) dumb
Скорость (Speed) 9600
Паритет (Parity) no
Бит на символ (Bits per character) 8
Кол-во стоп битов (Stop bits) 1
Контроль линии (Line Control) IPRTS
Режим процесса (Operation mode) echo
Turnaround character CR

Программа загрузки не повторит это сообщение после первой загрузки. И если у вас неправильно сконфигурирован терминал (сообщения вы не увидите), вы должны нажать клавишу <2> и затем <Enter> и скорректировать эту проблему в будущем.

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

Меню установки и обслуживания (шаг 4)

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

Welcome to Base Operating System
Installation and Maintenance

Type the number of your choise and press Enter. Choice indicated by >>>

1 Start Install now with Default Settings
2 Change/Show Installation Settings and Install
3 Start Maintenance Mode for System Recovery

88 Help ?
>>> Choice [1]: 2

Параметры установки

Installation Settings

Either type 0 or press Enter to install with current settings, or type the
number of the setting you want to change and press Enter.

1 System Settings
Method of installation New and Complete Overwrite
Disk where you want to Install hdisk0

2 Primary Language Enviroment Settings (AFTER install)
Cultural Convention C (POSIX)
Language C (POSIX)
Keyboard C (POSIX)

3 Install Trusted Computing Base no

0 Install with the settings listed above

88 Help ?
99 Previous Menu Warning: Base Operating System Installation
will destroy or impair recovery of SOME data
on the destination disk hdisk0

>>> Choice [1]:

При установке Trusted Computing Base (TCB) будут установлены trusted path, trusted shell и проверка целостности системы. Trusted path защитит вашу систему в случае злоумышленной подмены программы (например, su), которую вы хотите запустить, на другую. Trusted path проверяет и даёт гарантию, что программе, которую вы запускаете, можно доверять. Если вы решили установить TCB (что рекомендуется, см.Trusted Computing Base), то вы должны это указать на этом шаге, так как установки TCB нельзя поменять позднее (необходима полная переустановка BOS). Установка TCB влечет за собой более длительное время установки.

Методы установки

Change Method of Installation

Type the number of your choice and press Enter.

1 New and Complete Overwrite
Overwrites EVERYTHING on the disk selected for installation.
Warning: Only use this method if the disk is totally empty or there is nothing
on the disk you want to preserve.

2 Preservation Install
Preserves SOME of the exiting data on the disk selected for installation.
Warning: This method overwrites the usr (/usr), variable (/var), temporary
(/tmp), and root (/root) file systems. Other product (application) files and
configuration data will be destroyed.

3 Migration Install
Upgrades the Base Operating System to current release. Other product
(application) files and configuration data will be spared.

88 Help ?
99 Previous Menu

>>> Choice [3]: 1

1. New and Complete Overwrite - для новой системы это единственно доступный метод установки. Используйте этот метод для полностью чистых дисков или в случае, если диск содержит данные, которые вам не нужно сохранять.

2. Preservation Install - используется в случае, когда нам необходимо перезаписать BOS при сохранении пользовательских данных. Этот метод перезаписывает содержимое файловых систем /(root), /usr, /var и /temp.

3. Migration Install - используется для перехода с более поздних версий AIX на четвертую версию. При выборе этого метода сохраняется содержимое всех файловых систем и только пересоздается файловая система /tmp.

Выбор диска для установки

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

Change Disk Where You Want to Install

Type one or more numbers for the disk(s) to be used for
installation and press Enter. To cancel a choice, type the
corresponding number and press Enter. At least one bootable
disk must be selected. The current choice indicated by >>>

Size VG
Name Location Code (MB) Status Bootable
1 hdisk0 00-01-00-0.0 305 rootvg yes
2 hdisk1 00-01-00-1.0 305 rootvg no

>>> 0 Continue with choices indicated above

66 Disks not known to Base Operating System Installation
88 Help ?
99 Previous Menu

>>> Choice [0]:

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

Выбор первичного языкового окружения

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

Начало установки классический RS/6000

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

RS/6000 с шиной PCI

Так как система RS/6000 с шиной PCI не имеет ключа, то весь процесс установки отличается от процесса установки на классическом RS/6000 только отсутствием сообщения о необходимости включить ключ в положение Normal.

Завершение установки (шаг 5)

классический RS/6000

После окончания всего процесса установки перед перезагрузкой системы удалите установочный носитель (ленту или CD-ROM) и переместите ключ в положение Normal.

RS/6000 с шиной PCI

После сообщения об окончании установки необходимо не забыть вынуть установочный диск из дисковода и нажать <Enter> для перезагрузки системы. В процессе перезагрузки установите дискету с System Management Services, нажмите <F4> и проверьте, установлен ли диск, на который вы установили AIX в списке загрузочных устройств.

Установки Installation Assistant Menu (шаг 6)

После установки BOS запускается с параметрами по умолчанию: один пользователь (root), дата и время, выставленные при изготовлении компьютера и другие основные параметры. Вы, вероятно, захотите изменить сразу некоторые или все эти параметры. Также вы можете предоставить информацию о системе и сети для установления связи с другими системами.

Вновь установленная BOS перезагружает систему и запускает программу Installation Assistant, которая позволит вам изменить основные параметры. Когда вы запускаете Installation Assistant сразу после установки BOS, то будут доступны к изменению параметры в соответствии с выбранным вами методом установки.

Вы можете завершить работу Installation Assistant путем выхода "Tasks Completed - Exit to AIX Login" только один раз. При следующих запусках Installation Assistant этот пункт меню будет не показан на дисплее. Пользователь должен иметь права доступа root для использования Installation Assistant. Для доступа к Installation Assistant позже наберите следующую команду: Install_assist

Инструменты управления системой

Способы управления системой

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

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

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

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

Инструменты для решения задач администрирования в AIX Version 4

Четвертая версия AIX предлагает для решения всех общих функций системного администрирования единый меню-ориентированный интерфейс System Management Interface Tools (SMIT), который поставляется в стандартной поставке AIX.

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

Существует два интерфейса SMIT: алфавитно-цифровой (ASCII) и графический (Motif). Для управления другими компьютерами по сети (с операционными системами AIX, SunOS 4.1.3 и HP-UX 9.0) существует такой инструмент как Distributed System Management Interface Tools (DSMIT) (см.DSMIT).

Для решения самых частых задач, согласно исследованиям занимающих до 70% времени администрирования (управление пользователями, дисками, устройствами, принтерами), существует инструмент администрирования с графическим интерфейсом - Visual System Manager (VSM), который позволяет выполнять основные задачи администратора посредством простой манипуляции объектами (см.Инструменты Visual System Management (VSM)).

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

Принцип работы инструментов по управлению системой

Для своей работы инструменты администратора AIX пользуются специальной базой данных называемой Object Data Manager (ODM), которая содержит информацию о командах инструментов администрирования и о том, как с их применением строятся эти команды (и не только). Каждый раз, когда администратор в инструментах администрирования нажимает <Enter> или функциональные клавиши, идет обращение к базе данных ODM, на основании которой формируются меню и команды. Все требуемые меню и команды встроены в базу данных ODM.

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

Компоненты интерфейса пользователя SMIT

Пользователь может использовать интерфейс как ASCII так и AIXWindows которые, предоставляют аналогичные возможности только с несколько иным представлением на экране.

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

ћ Меню;
ћ Диалоговый экран (экран выбора);
ћ Списки;
ћ Панель вывода;
ћ Контекстная помощь;

Главное меню SMIT (ASCII)

Главное меню SMIT позволяет выбрать требуемую административную функцию.

System Management

Move cursor to desired item and press Enter.

Software Installation and Maintenance
Software License Management
Devices
System Storage Management (Physical and Logical Storage)
Security & Users
Communication Application and Services
Print Spooling
Problem Determination
Performance & Resource Scheduling
System Environment
Processes & Subsystems
Application
Using SMIT (information only)

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

Диалоговый экран

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

Schedule a Job

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
YEAR [98]
MONTH [Sep] #
DAY (1-31) [12] +
* HOUR (0-23) [10] #
* MINUTES (0-59) [30] #
SHELL to use for job execution Korn (ksh) +
* COMMAND or SHELL SCRIPT [] /
(full pathname)

F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

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

Поля, в которые не помещаются на экране все данные выделяются стрелками < >.

Для указания того, какие данные могут быть введены используются специальные символы:
* поле, в которое обязательно необходимо ввести значение;
# для этого поля требуется ввод цифрового значения;
/ для этого поля необходим ввод пути (pathname);
Х требуется ввод шестнадцатеричного значения;
? вводимое значение не показывается на экране;
+ доступен список значений поля.

Для доступа к списку значений вводимого поля (если, конечно, присутствует специальный знак +) нажмите клавишу <F4>.

Очень удобной возможностью для контроля и обучения является предварительный просмотр сформированной SMIT команды AIX. Такой просмотр возможен при нажатии клавиши <F6>.

Экран вывода

COMMAND STATUS

Command: OK stdout: yes stderr: no

Before command completion, additional instructions may appear
below.

[TOP]
UID PID PPID C STIME TTY TIME CMD
root 1 0 4 20:15:04 - 1:49 /etc/init
root 1719 1 0 20:16:14 - 0:10 /etc/syncd 60
root 2003 1 0 20:16:19 - 0:00 /etc/srcmstr
root 2233 1 0 20:16:14 - 0:00 /usr/lib/errdemon
ray 3525 1 0 17:01:28 0 0:00 -ksh
root 3806 2003 0 20:16:23 - 0:00 /etc/syslogd
ray 4162 3525 6 19:53:22 0 0:04 smit
root 5355 1 0 20:16;27 - 0:12 /etc/cron
root 6649 2003 0 20:16:32 - 0:00 qdaemon
ray 7303 4162 8 20:09:45 0 0:00 ps –ef

[MORE . . . 6]

F1=Help F2=refresh F3=Cancel F6=Command
F8=Image F9=Shell F10=Exit /=Find
n=Find Next

В верхней строке экрана вывода указывается статус выполнения команды. Если вывод информации не помещается на экране вы можете используя клавиши прокрутки <PgDn>, <PgUp>, <Home>, <End> просмотреть полный листинг.

Файлы SMIT аудита и составления пакетных файлов

При первом запуске SMIT создает два файла smit.log и smit.script в директории $HOME того пользователя, который запустил SMIT. Если эти файлы уже существуют, то в них добавляется информация нового сеанса работы со SMIT.

Файл smit.log содержит запись всех экранов SMIT, выполненных команд и экраны вывода этих команд. Этот файл используется для изучения команд, их синтаксиса, а также для диагностики всех действий пользователя.

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

DSMIT

Инструмент DSMIT добавляет к функциональности SMIT возможности для построения команд и распределения их для других клиентов в сети. В отличие от SMIT, DSMIT имеет только ASCII интерфейс. DSMIT используется для управления компьютерами по сети и поддерживает, кроме AIX версии 4.1 и старше, следующие операционные системы: Sun OS 4.1.3 и HP-UX 9.0.

Пользоваться инструментом DSMIT для удаленных систем может только пользователь с правами root (для этих удаленных систем). Для запуска DSMIT наберите в командной строке dsmit.

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

Инструменты Visual System Management (VSM)

Реалии современного мира информационных технологий предполагают наличие графических упрощенных средств администрирования системы. Поэтому, в версии AIX 3.2.5 был объявлен, как отдельно заказываемая программа, инструмент Visual System Management (VSM).

В четвертой версии AIX VSM - уже стандартно поставляемый графический инструмент администрирования.

Эта программа использует объектно-ориентированный стандарт визуального представления Common Desktop Environment (см. Common Desktop Environment (CDE)), единый практически для всех современных коммерческих, и не только, версий UNIX. Дизайн этого инструмента базируется на интуитивном графическом интерфейсе для решения наиболее общих и наиболее часто решаемых задач администрирования (занимающих порядка 70% общего времени управления системой) посредством манипулирования графическими объектами. Большинство задач решается методом "взял-и-переместил" (drag-and-drop). Этот инструмент комплектуется множеством готовых шаблонов для создания новых объектов администрирования.

Инструменты VSM:

Установка и обслуживание программного обеспечения

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

Для AIX существует множество пакетов прикладных программ для решения задач по обработке информации в различных сферах человеческой деятельности. Корпорация IBM предлагает для построения клиент-серверных и ориентированных на сеть решений пакет программ IBM Software Server, который содержит в себе следующие компоненты: IBM Communications Server, IBM Database Server (DB/2), IBM Directory and Security Server, IBM Internet Connection Server (Web-server), IBM System Management Server (IBM SystemView Server), IBM Transaction Server, Lotus Notes Release 4.

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

Определение пакетов программного обеспечения

Лицензированный программный продукт (LPP) - это комплексный программный продукт, который содержит в себе все пакеты (package) и наборы файлов (fileset), ассоциированные с этим LPP.

Наименьшей устанавливаемой индивидуально единицей является набор файлов (fileset). Этот набор является какой-либо одной функцией полного программного продукта. Наборы файлов группируются в пакеты (package), как в группу наборов файлов с общими функциями.

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

Например, набор файлов для обеспечения работы сетевой файловой системы (NFS) для протокола TCP/IP bos.net.tcp.nfs является одним из наборов файлов в пакете для работы в сети bos.net из LPP bos.

.adt Инструмент разработчика для LPP
.com Общий код для двух подобных наборов файлов
.compat Код для совместимости, который будет удален в будущих версиях LPP
.data Часть набора файлов, помещаемый в /usr/share
.dev Поддержка устройств для LPP
.diag Диагностика для набора файлов
.fnt Шрифтовая часть набора файлов
.info[lang] База данных InfoExplorer для LPP
.help[lang] Файлы помощи для конкретного LPP
.loc Место действия для LPP
.mp Код специфичный для многопроцессорной конфигурации
.msg[lang] Сообщения
.rte Минимальный набор или run time
.smit Инструменты и диалоги добавляемые в SMIT
.ucode Микрокод для набора файлов
.up Код специфичный для однопроцессорной конфигурации

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

Связки (Bundles)

Используя SMIT вы можете организовывать свои комплекты наборов файлов и пакетов даже из разных LPP, называемые связками (bundle). Связки известны также как профили установки.

Supporting Code Service

Каждый компонент программного обеспечения содержит в себе три части для поддержки кодового сервиса и бездисковых рабочих станций:

root файлы, размещаемые в файловой системе root, копию которых должна иметь каждая машина;
usr файлы, которые могут быть обслуживаемы другой системой;
share разделяемые файлы, которые размещаются в /usr/share.

Все эти части, размещаемые на одной машине должны быть все одной версии.

Пакеты обновления программного обеспечения

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

Другая (Maintenance Level Bundle), используется для обновления программного продукта до последней версии.

Fix States

Обновления программного продукта могут находится в двух состояниях:

Applied Обновление установлено, но старая версия продукта сохраняется;
Commited При этом состоянии удаляется старая версия продукта.

Меню установки и обслуживания программного обеспечения

Меню установки и обслуживания программного обеспечения содержит в себе три пункта:

1. Установка и обновление программного обеспечения (Install and Update software);
2. Обслуживание установленного программного обеспечения (Maintain Installed Software);
3. Управление сетевой установкой (Network Installation Management). Меню пользовательской установки (Custom Install)

Install/Update Selectable Software (Custom Install)

Move cursor to desired item and press Enter.

Install Software Products at Latest Level
Install Bundles of Software
Install Maintenance Levels
Install Fileset Updates by Fix
Install Additional Printer/Plotter Software
Install Additional Device Software
Install/Update From All Available Software

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

Ниже приводится пример экрана установки программного обеспечения.

Install Software Products at Latest Level

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
* INPUT device/directory for software /dev/rmt0.1
* SOFTWARE to install [all_licensed] +
PREVIEW only? (install operation will not occur)no +
COMMIT software updates? yes +
ALTERNATE save directory []
AUTOMATICALLY install requisite software? yes +
EXTEND filesystem if space needed? yes +
OVERWRITE same or never versions? no +
VERIFY install and check file sizes? no +
Include corresponding LANGUAGE filesets? yes +
DETAILED output? no +

F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

Для просмотра списка установленного программного обеспечения администратор может использовать команду lslpp -L имя пакета.* или воспользоваться SMIT (команда быстрого вызова меню списка установленного ПО: smit lslpp).

Старт и останов системы

Режимы старта системы

Для классического RS/6000

Ключ на передней панели системы определяет режим старта системы и может находится в трех позициях:

Normal Система должна загрузится с жесткого диска с поддержкой многопользовательского режима и сети.
Secure Система не загружается. Проводится диагностика аппаратуры.
Service Система будет пытаться загрузится с доступных устройств в следующей последовательности: магнитная лента, CD-ROM, жесткий диск, дискета (например при установке системы, запуска диагностики с CD-ROM) Доступна только консоль. Сеть не стартует. Доступен только ограниченный набор команд.

Для RS/6000 с шиной PCI

Normal Mode
ћ Программы и процессы выполняются;
ћ Терминалы доступны;
ћ Имеется доступ ко всем системным файлам;
ћ Стартует поддержка коммуникаций;
ћ Многопользовательский режим.

Standalone Mode
ћ Старт системы с дискеты System Management Services diskette
ћ Доступны следующие системные программы:

Для вызова режима standalone необходимо сделать следующие действия:

1. Вставить дискету с System Management Services в дисковод.
2. Включить или перезагрузить систему.
3. При появлении первого изображения на экране нажать <F1> для загрузки в графическом режиме или <F4> для загрузки в режиме ASCII

Из standalone режима вы можете перезапустить систему используя следующие методы:

1. Нажмите <Ctrl+Alt+Del>.
2. Нажмите <F3>.
3. Выключите и снова включите систему.

Только не забудьте вытащить дискету из дисковода.

Описание старта системы

Классический RS/6000

Когда система стартует вы можете контролировать процесс загрузки с помощью LED индикатора на системном блоке. Первым при старте системы производится встроенное самотестирование аппаратуры (BIST). В это время инициализируются самые базовые компоненты системы, такие как процессор, память и системная плата. Когда выполняется BIST индикатор показывает цифры от 100 до 199. После окончания встроенного самотестирования стартует самотестирование при включении (POST) и загрузка программы инициализации (IPL). На этом этапе старта системы определяется устройство загрузки и с него загружается в память загрузочная программа. В это время индикатор показывает цифры от 201 до 298. Следующим этапом является этап загрузки ядра ОС. Индикатор показывает цифру 299. После загрузки ядра выполняется конфигурация (цифры от 500 до 999). Начиная с цифры 553 выполняется процесс init и запускаются подсистемы и процессы определенные в файле /etc/inittab.

RS/6000 с шиной PCI

Для RS/6000 с шиной PCI существуют два режима старта системы: нормальный (запускаются процессы и программы, терминалы доступны, есть доступ ко всем системным файлам, стартуют коммуникации, многопользовательский режим) и монопольный (вызывается при использовании для старта системной дискеты (или CD) System Management Service Diskette). Монопольный режим используется для просмотра информации и изменения таких установочных параметров системы, как список устройств для первоначальной загрузки, пароля при включении и обновления программы на системной дискете. В этом режиме можно также произвести тестирование аппаратной части системы.

Аудит процесса старта системы

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

Поддерживаемые системой типы журналов регистрации: boot, bosinst и nim. Чтобы выполнять команду alog при каждом запуске системы её необходимо поместить в сценарий загрузки rc.boot.

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

Для записи информации о функционировании программы (например, boot) в текстовый файл вы также можете использовать программу tee.

Файл /etc/inittab

Файл /etc/inittab содержит список процессов, которые запускаются когда стартует демон init, а также в нём определяется то, как они должны стартовать. Если этот файл поврежден, то система не сможет правильно загрузиться. Поэтому всегда имейте архивную копию этого файла.

Идентификатор_процесса имя процесса (до 14 символов). Терминалы используют для имени процесса имя своего логического устройства.

Уровень Уровень определяет, какой набор системных ресурсов нужно задействовать. Возможные значения 0-9, S, s (одно- пользовательский режим), M или m. Когда стартует демон init, то пользователю предлагается ввести уровень выполнения (если уровень не задан как аргумент). Если задан уровень S или s, init входит в однопользовательский режим, а для уровня M или m, в режим обслуживания. В противном случае он находит в файле /etc/inittab элементы, соответствующие указанному уровню, и выполняет установленные в них команды. Уровень по умолчанию - 2 (запуск в многопользовательском режиме. Если уровень не указан, то это означает, что процесс запускается на любом уровне запуска.

Действие Указывает, что должен делать демон init. Разрешенные уровни следующие:

Пример несколько фрагментов из файла /etc/inittab (неполный список):

Для того, чтобы демон init заново прочел файл /etc/inittab (например, при удалении из него службы getty для терминала, с которым связь невозможна из-за ошибок в линиях связи) необходимо использовать команду telinit -q.

Для изменения файла /etc/inittab вместо прямого его редактирования предпочтительнее пользоваться командами mkitab и chitab.

System Resource Controller (SRC)

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

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

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

Для минимизации необходимости вмешательства администратора в контроле за процессами подсистем используется System Resource Controller (SRC).

Синтаксис SRC

Старт подсистемы: startsrc [options]{-s ПОДСИСТЕМА|-g ГРУППА}
Останов подсистемы: stopsrc [options]{-a|-g группа|-p PID_подсистемы|-s подсистема}
Перезапуск подсистемы: refresh {-g ГРУППА|-p PID_ПОДСИСТЕМЫ|-s ПОДСИСТЕМА}
Просмотр состояния подсистемы: lssrc {-a|-g группа|-s подсистема}

Некоторые опции:
-f используется для быстрого останова подсистемы без ожидания завершения активности любых приложений;
-s указывает, что команда относится к одной подсистеме;
-g указывает, что команда относится ко всей группе подсистем для определенной группы.

Проблема загрузки графического входа в систему

После первоначальной загрузки операционной системы для машин с графическим адаптером и дисплеем в некоторых случаях не загружается графическое приглашение к входу в систему (CDE Login).

В этом случае необходимо сделать следующее:

ћ Вставить установочный компакт диск и перезагрузить машину;
ћ Выбрать из меню System Maintenance;
ћ Получить доступ к файловой системе root;
ћ Смонтировать файловую систему /usr командой MOUNT /USR
ћ Выполнить команду /usr/dt/bin/dtconfig -d #disable CDE
ћ Затем размонтировать файловую систему /usr командой unmount /usr
ћ Перезапустить машину командой shutdown -r
ћ Появится приглашение к входу в ASCII режиме;
ћ Войдите в систему;
ћ Выполните команду /usr/dt/bin/dtconfig -e #enable CDE
ћ Снова перезапустите машину;
ћ Графическое приглашение к входу в систему должно появиться.

Останов системы

Для корректного останова системы в обычных ситуациях используется команда shutdown (через SMIT это опция Stop the System).

На всех терминалах будет выведено следующее сообщение:

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

Вы можете использовать команду shutdown с параметрами -F для более быстрого останова системы (без вывода сообщения), -r для указания необходимости перезапуска после останова, -m для перехода системы в режим обслуживания.

Параметр -k имитирует останов системы. При таком останове все пользователи, кроме пользователя root, не могут зарегистрироваться в системе.

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

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

System Enviroment

Move cursor to desired item and press Enter.

Stop the system
Assing the Console
Change/Show Date, Time, and Time Zone
Manage Language Enviroment
Change/Show Characteristics of the Operating System
Change/Show Number of Licensed Users
Manage AIX Floating User Licenses for this Server
Broadcast Message to all Users
Manage System Logs
System Dump
Change System User Interface

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

Во время инсталяции в файл /etc/environment заносится информация о значении переменной LANG на основании выбора языкового окружения введенного пользователем.

Используя команду chlang <имя языкового окружения> вы измените системный Национальный Язык, который используется для вывода сообщений InfoExplorer, on-line help в SMIT и для всех сообщений об ошибках.

Manage Language Environment

Move cursor to desired item and press Enter.

Change/Show Primary Language Environment
Add Additional Language Environments
Remove Language Environment
Change/Show Language Hierarchy
Change/Show Applications for a Language
Convert System Messages and Flat Files

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

Для конвертирования ASCII текстов из одной кодовой таблицы в другую (например, из KOI-8r в WIN1251 или наоборот), используется команда lconv, доступная также через SMIT.

Устройства

Терминология

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

ћ Физические устройства - аппаратные устройства, которые подсоединены к системе различными способами
ћ Порты - физические коннекторы/адаптеры, через которые подсоединены к системе физические устройства. Многие порты являются программируемыми с помощью системного программного обеспечения, чтобы обеспечить возможность подключения различных типов физических устройств.
ћ Драйверы устройств - программное обеспечение ядра, с помощью которого контролируется активность портов и определяется формат передаваемых в устройства данных.
ћ Логические устройства - программный интерфейс (специальные файлы) которые являются виртуальным представлением физических устройств для пользователей и программ.

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

Все логические устройства делятся на два типа:

ћ Блок-ориентированные устройства - устройства с произвольным доступом. Обычно это дисковые файловые системы. Осуществляют ввод/вывод большими порциями (блоками). Буферизация используется для реализации блокового доступа.
ћ Байт-ориентированные устройства - потоко-ориентированные устройства без буферизации.

Основные блок-ориентированные устройства также имеют свои эквиваленты в виде байт-ориентированных устройств. Например, возможно обращение к логическому тому, как к блок-ориентированному буферизированному устройству /dev/hd1, так и как к байт-ориентированному устройству /dev/rhd1.

cd0 CD-ROM
fd0, fd0l, fd0h Дискета
hd1, lv00 Логический том
hdisk0 Физический том

console, lft, tty0 Терминал
lp0 Принтер
rmt0 Ленточное устройство
tok0, ent0 Адаптер
kmem, mem, null Память
rfd0, rfd0l, rfd0h Дискета
rhd1, rlv00 Логический том
rhdisk0 Физический том

/dev - Директория которая содержит все логические устройства, к которым возможен прямой доступ пользователя (некоторые логические устройства определены в ODM и не могут быть доступны напрямую для пользователя).

Для просмотра содержимого директории /dev из командной строки используется следующая команда ls -l /dev

Базы предопределенных и используемых устройств

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

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

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

Просмотр списка всех предопределенных устройств из командной строки: lsdev -P -H

Просмотр списка всех используемых устройств из командной строки: lsdev -С -H

-P выборка информации из базы предопределенных устройств
-C выборка информации из базы используемых устройств
-H показывать заголовки при выводе -c указание класса устройств (например, lsdev -Pctape; lsdev -Ccmemory и т.п)

Команда lsattr -E -l [имя_логического_устройства] используется для получения детализированной информации об эффективных атрибутах реально сконфигурированных устройств.

Статус устройства

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

Определено (Defined) - в системе имеется имя логического устройства и порт для устройства с определенными атрибутами. Устройство не готово к использованию и нет доступа к логическому устройству.

Доступно (Available) - устройство определено и готово к использованию. Интеллектуальные устройства (например, ленточное устройство SCSI), которые выключены при старте системы, переходят в статус определенных устройств и затем при их включении могут быть установлены в статус доступных устройств.

Примечание: устройство inet0 может находиться в статусе stopped (т.к. ему необходим запуск служб TCP/IP).

Адресация устройств

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

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

Код размещения состоит из четырех групп пар цифр. Его формат:

Две группы AA и BB используются для указания места размещения внешних адаптеров. Три группы (AA-BB-CC) используются для указания адреса встроенных устройств. Четыре группы (AA-BB-CC-DD) используются для адресации портов устройств или размещения портов на концентраторе портов.

AA - Первая цифра идентифицирует шину ввода/вывода, обычно 0 Вторая цифра указывает номер разъема в системном блоке (0 на рабочих стан-циях)

BB - Первая позиция указывает тип шины ввода/вывода (0 - MCA или PCI; 1 - ISA; 2 - pcmcia) Вторая цифра - указывает номер разъема для адаптера памяти или адаптера шины ввода/вывода. Для адаптеров ISA вторая цифра заменяется на x.

CC - Разъем на адаптере или системной плате. Для встроенных устройств: 0P - параллельный порт, 0S - SCSI, S1, S2 - последовательные порты, 0D - флоппи-дисковод, 0K - клавиатура, 0M - память, 0T - дигитайзер

DD - Номер асинхронного порта или номер порта на концентраторе портов.

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

CC - 00 для недифференциальных устройств
01 для дифференциальных устройств
0S Разъем внешней шины встроенного SCSI контроллера
S - SCSI адрес устройства (для внутреннего адаптера всегда 7) Рекомендуется для загрузочного диска устанавливать SCSI адрес 0
L - Номер системного блока для устройства (например, для внешних массивов дисков)

Самоконфигурируемые устройства

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

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

Конфигурация ISA устройств

Особым типом устройств являются устройства для шины ISA, так как шина ISA не является интеллектуальной подобно, например, шине PCI.

Особо необходимо контролировать следующие пять ресурсов адаптеров ISA:

Диапазон адресов ввода/вывода (I/O address)
Диапазон адресов памяти шины (bus memory address)
Номер системного прерывания (IRQ)
Номера каналов DMA (DMA channels)
Диапазон адресов памяти шины для DMA (bus memory DMA address)

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

Некоторые адаптеры (например, IBM Ethernet adapter) не имеют никаких аппаратных переключателей для выставления ресурсов и конфигурируются программно. Вы должны иметь программу конфигурирования адаптера и сконфигурировать его с её помощью перед тем как устанавливать адаптер в машину RS/6000.

Формат команды mkdev для подключения ISA адаптера Ethernet (в одну строку):

где IRQ - номер прерывания;
IO - диапазон адресов ввода/вывода;
MEM - адреса общей памяти адаптера;
TYPE - тип подключаемого кабеля (bnc, utp и т.п).

Меню управления устройствами

Вызывается командой быстрого доступа smit devices

Devices

Move cursor to desired item and press Enter.

Install/Configure Devices Added After IPL
Printer/Plotter
TTY
Asynchronous Adapters
PTY
Console
Fixed Disk
CD ROM Drive
Read/Write Optical Drive
Diskette Drive
Tape Drive
Communication
Graphic Displays
Graphic Input Devices
Low Function Terminal (LFT)
SCSI Initiator Device
Xstation Configuration
SCSI Adapter
Asynchronous I/O
Multimedia
List Devices
Install Additional Device Software
ISA Adapter
PCMCIA Adapter

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

ћ TTY любое устройство подсоединяемое к последовательному порту (например, модем, терминал)
ћ PTY псевдотерминальное устройство. Предоставляет для приложений возможности реального терминала, но не имеет подключения к физическому порту. Используется для таких приложений как AIXWindows и для связи TCP/IP.
ћ Communication адаптеры для различных типов связи (Ethernet, X.25 и пр.)
ћ Xstation Configuration это меню добавляется при установке ПО Xstation Manager

Добавление устройства

Для добавления устройства администратор может использовать команду mkdev. При этом он должен знать ее синтаксис, а также:

а) класс устройства, тип и подкласс;
б) размещение адаптера и подключения;
в) атрибуты устройства.

Но гораздо удобнее добавлять устройства с помощью SMIT. Например, добавление НГМД требует ввода следующей команды:

Ниже приводится пример меню SMIT для этой же операции:

Add a Diskette Drive

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
* PORT number [] +
Diskette DRIVE TYPE 3.5 inch +

F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

Документирование конфигурации аппаратной части системы

1. Запустите команду, которая обеспечивает информацией об имени, статусе и размещении, а также описание устройств, lsdev -CH с выводом в файл.
2. Запустите команду, которая выдает детальный список сконфигурированных устройств с указанием такой информации как, например, part number устройства, lscfg -v с выводом в файл
3. Запустите команду lsattr -E -I sys0, которая показывает детальную информацию об атрибутах сконфигурированного устройства.

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

Примечание: Для компьютеров на базе шины PCI, на которых установлены ISA адаптеры, администратор должен вручную записать номер разъема и установки этих адаптеров.

Последовательные устройства

При загрузке системы команда cfgmrg запускает определенные и доступные устройства в системе, например, адаптеры MCA, PCI или SCSI. Некоторые же устройства не имеют механизма для самоидентификации. Одними из таких устройств, которые не конфигурируются автоматически и должны быть определены вручную, являются ASCII терминалы и принтеры.

Добавление терминала

Перед добавлением нового терминала администратор должен уяснить для себя следующую информацию:

ћ TTY интерфейс (RS232 или RS422)
ћ Адаптер
ћ Номер порта
ћ Характеристики линии (скорость, четность, кол-во стоп-битов ...)
ћ Тип терминала (dump, IBM 3151, DEC,...)
ћ Атрибуты клавиатуры

Для добавления терминала в SMIT используется опция подменю Add TTY в меню TTY.

disable порт определен, но доступен только как порт вывода для асинхронной связи с другим компьютером
enable порт доступен для входа в систему, если порт не используется, то должен быть запущен процесс опроса порта getty.
delay порт доступен для входа в систему, но приглашения входа в систему не появляется на дисплее, пока пользователь не нажмет любую клавишу на клавиатуре
share порт может быть использован под управлением иного устройства (для модемов и т.п.)

Решение проблем с терминалами

При неправильных типе/установках терминала Измените установки терминала с помощью SMIT

При зависании терминала (крушение программы или при попытке вывести на дисплей содержимое бинарного файла)

а) Попытайтесь нажать <Ctrl+D>;
б) Перезапустите терминал через его меню Setup;
в) Попытайтесь выполнить следующую процедуру: Нажмите <Ctrl+j>, наберите stty sane, затем <Ctrl+j>, затем выйдите из системы и снова зайдите (log of/on).

Чтобы узнать pid_of_login_shell наберите команду ps -ef
login_shell помечается дефисом - в отличие от других запущенных shell'ов.

Документирование установок терминалов

1. Всегда имейте карту физического подключения терминалов к концентраторам портов.
2. Документируйте установки из меню Setup терминала.
3. Запустите команду lscfg с выводом в файл.

Принтеры и печать

Концепция очередей

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

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

Важнейшими преимуществами системы очередей являются следующие:

ћ Одно задание может принадлежать нескольким очередям;
ћ Пользователь может распределять свои задания по различным очередям;
ћ С ресурсом (например, принтером) может быть связано несколько очередей.

Описание процесса печати

Когда пользователь дает одну из команд вывода файла в очередь (qprt, lp или lpr) запрос на печать задание размещается в каталог /var/spool/lpd/qdir (при необходимости, файл копируется в каталог /var/spool/qdaemon).

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

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

Процесс qdaemon контролируется файлом /etc/qconfig. Этот файл содержит станзы (stanza) (поименованные блоки данных) для каждой очереди.

Станза очереди

Станза очереди начинается с имени очереди (до 20 символов) оканчивающемся двоеточием. Первая очередь в файле /etc/qconfig является очередью по умолчанию и используется в том случае, если в команде на печать не было специально указана имя очереди. Затем указывается ссылка на используемое этой очередью устройство(а).

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

Станза устройства

Станза устройства начинается с имени устройства (до 20 символов), оканчивающемся двоеточием. Станза устройств должна иметь атрибут backend, который указывает местоположение выходной программы (например, программы локальной печати piobe).

Станза устройств может иметь также следующие атрибуты:

Системные файлы, ассоциированные с печатью

ћ Каталог /var/spool/lpd/qdir содержит информацию о файлах заданных на печать.
ћ Файл /etc/qconfig описывает очереди и устройства, которые с ними связаны, доступные для команд печати для размещения заданий.
ћ Каталог /var/spool/qdaemon содержит копии файлов заданных на печать.
ћ Каталог /var/spool содержит файлы и каталоги используемые программами и демонами печати.
ћ Каталог /var/spool/lpd/stat содержит информацию о статусе заданий сохраненных и обновленных для использования qdaemon и выходными программами. Рекомендуется для работы с этими ресурсами использовать SMIT.

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

Задание работ печати и просмотр очереди

В различных системах UNIX используются различные команды на выполнение печати. Все эти команды имеют совсем различные опции. Для совместимости в AIX вы можете использовать все типы команд задания на печать и просмотра заданий в очереди, используемые в UNIX System V, BSD и AIX.

Решение проблем с печатью

ћ Проверьте подключение кабелей.
ћ Проверьте включен ли принтер в состояние on-line и ready.
ћ Проверьте, существует ли файл устройства.
ћ Проверьте файл /etc/qconfig.
ћ Проверьте состояние qdaemon (может быть запущено два qdaemon). В этом случае рекомендуется дать команду stopsrc -s qdaemon (остановятся оба экземпляра), а затем дать команду startsrc -s qdaemon.

Управления очередями

Изменение характеристик очереди

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

Удаление очереди

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

Управление очередью с помощью SMIT

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

Состояния очереди

Введение в управление дисками

Типы дисковых подсистем в AIX Version 4

Базовыми "строительными блоками" дисковых подсистем в AIX являются:

ћ файлы;
ћ директории;
ћ файловые системы;
ћ логические дисковые подсистемы;
ћ физические дисковые подсистемы;
ћ Logical Volume Manager (LVM).

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

Дисковые подсистемы в традиционном UNIX

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

Основные свойства LVM

Для устранения недостатков традиционного подхода к работе с дисками и связанного с ним проблем в AIX применяются логические тома (дополнительный уровень абстракции при работе с дисками) управляемые Logical Volume Manager (LVM).

ћ Непрерывное пространство логического тома;
ћ Логический том может размещаться на нескольких дисках;
ћ Возможно динамическое увеличение размера логического тома;
ћ Логический том может зеркалироваться;
ћ Жесткие диски подсоединяются к системе проще;
ћ Логические тома могут быть перемещены.

Физические диски

Физическим диском называют реально подключенный диск к системе (как внутреннее или внешнее устройство). Перед тем как использовать физический диск, пользователь должен добавить его в существующую или новую предварительно созданную группу томов. Когда физический диск добавляется в систему в директории /dev образуется файл устройства /dev/hdiskn. Этот файл может использоваться для прямого доступа к диску, но так не принято.

Наименьшим разделом дискового пространства физического диска является физический раздел. Все физические разделы в одной группе томов имеют одинаковый размер. По умолчанию размер физического раздела 4 мегабайта. Размер физического раздела для вашей группы томов определяется следующим способом:

где L - размер физического раздела;
SV - общий объем дискового пространства в группе томов;
1016 - максимальное количество физических разделов в группе томов.

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

Группа томов (например, внешне подключаемые SCSI диски) может быть отсоединена от одной системы и подключена к другой системе.

Группы томов

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

Когда имеет смысл создавать новую группу томов:

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

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

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

Область описания группы томов (VGDA)

Область описания группы томов (VGDA) - это область на диске, в которой содержится полная информация о группе томов. Для одного физического диска обычно имеется одна VGDA (+ её копия).

Количество VGDA, которые должны быть доступны для активации группы томов (varyonvg), называется кворумом. Требования кворума предусматривают доступность 51% или более VGDA. Кворум необходим для обеспечения целостности управляющих данных.

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

Логические диски

Физический раздел является структурной наименьшей единицей физического размещения информации на диске. В дисковой подсистеме AIX введено понятие логического раздела как ссылки на физический раздел.

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

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

Типичный размер физического/логического раздела 4 МБ (может быть от 1-го до 256-ти МБ).

Зеркалирование (RAID 1)

При создании логического тома вы можете задать зеркалирование логических разделов на нем. Размещение логического раздела на 2-х или 3-х физических разделах (которые могут находиться на одном или на различных физических дисках) значительно уменьшают возможность потери данных из-за поломки диска (за счет увеличения количества необходимых дисков). По статистике IBM срок службы ее дисков - 5 лет.

Не требуется чтобы физический раздел был непрерывным.

Существуют два способа синхронизации данных на зеркальных логических разделах:

1. Параллельный - Запрос на запись передается для каждой копии одновременно. Ответ приложению возвращается после записи данных на первый диск. Если сбой с каким-то из дисков произойдет в момент записи, то есть возможность потерять данные. Поэтому для устранения такой ситуации обязательно необходимо включить опцию непротиворечивости записи при зеркалировании (mirror write consistency option).
2. Последовательный - Когда данные записываются на логический раздел, ответ приложению возвращается только после записи всех копий. Это более медленный, но и более надежный способ зеркалирования, чем параллельный.

Расслоение (RAID 0)

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

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

Для расслоенных дисков существуют также следующие ограничения:

1. Расслоеный логический том не может быть зеркалирован.
2. Число физических разделов, распределенных на расслоенном логическом томе должно быть равномерно распределенно среди дисков.
3. Требуется по меньшей мере 2 физических тома.
4. Желательно использовать большее число адаптеров SCSI (или SSA).
5. Для расслоенных логических томов необходимо создание выделенной логической группы.

Политика размещения логических томов

С помощью Logical Volume Manager при создании/изменении логического тома администратор может определить политику размещения физических разделов. Эта политика нужна из-за соображений производительности дисковой подсистемы.

Внутренняя политика размещения физических разделов (Intra-physical volume allocation policy) определяет то, на каких разделах физического тома будет размещен логический том. Существуют три значения: центральное, среднее и крайнее. Для данных в разделах при центральном размещении самое быстрое время доступа, по сравне-нию с данными при среднем и крайнем размещениях.

Внешняя политика (Inter-physical volume allocation policy) указывает на то, как много физических томов могут быть использованы размещения логических томов. Максимальное число физических томов которое может быть использовано логическим томом может быть определено (обычно это количество физических томов в логической группе).

Вариантов определения количества томов два:

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

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

Использование логических томов

ћ Журнальную файловую систему;
ћ Пейджинговое пространство;
ћ Записи журнала;
ћ Загрузочный логический том;
ћ Ничего (raw device).

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

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

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

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

Загрузочный логический том - это непрерывная область на диске, которая содержит загрузочный образ (boot image).

Raw device - это просто пустой логический том. Некоторые приложения, например, пакеты систем управления базами данных, могут размещать на raw device свои данные своим особым образом.

Введение в файловые системы

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

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

Причины использования файловых систем

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

Стандартные файловые системы в AIX Version 4

После первой установки AIX существует только пять журнальных файловых систем:

ћ / (root) = /dev/hd4 Вершина иерархии файлового дерева. Содержит файлы и директории, критичные для системного выполнения, включая директорию устройств и программ, завершающих процесс загрузки
ћ /usr = /dev/hd2 Команды операционной системы, библиотеки и программы приложений. Эта файловая система должна быть определена как доступная по сети.
ћ /var = /dev/hd9var Место размещения различных файлов подкачки и аудита.
ћ /home = /dev/hd1 Домашние директории пользователей. Традиционное место размещения пользовательских файлов данных.
ћ /tmp = /dev/hd3 Пространство используемое всеми пользователями для сохранения временных файлов и рабочего пространства. Целесообразно часто очищать.

Файл /etc/filesystems

Файл /etc/filesystems документирует характеристики компоновки или атрибуты файловых систем. Этот файл организован в виде станз (stanza). Каждое имя станзы в этом файле относится к файловой системе, которая нормально смонтирована.

Атрибуты файловой системы описывают следующие её параметры:

ћ check используется командой fsck для определения файловых систем проверяемых по умолчанию. Значение True разрещает проверку.
ћ dev Для локальных точек монтирования идентифицирует или специальный блочный файл, где файловая система постоянно находится, или файл или директорию, в которую будет установлена файловая система.
ћ mount используется командой mount для определения точки монтирования файловой системы по умолчанию. Возможные значения:

ћ type используется для группировки вместе связанных файловых систем, которые могут весь быть установленны командой mount -t.
ћ vfs описывает тип монтирования (например, nfs)
ћ vol используется командой mkfs для установки ярлыка (label) новой файловой системы.
ћ log устройство на которое будут записываться данные об модификации данной файловой системы (опция работает только с JFS).

Монтирование файловой системы

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

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

Когда SMIT создает файловую систему, точка монтирования создаётся автоматически.

Файловые системы, ассоциированные с устройствами, представлены в специальном файле в логическом томе /dev. При монтировании файловой системы к пустой директории её структура директорий и файлы просто становятся частью иерархического дерева директорий.

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

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

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

Структура журнальной файловой системы

Журнальная файловая система AIX размещается на логическом томе, который разделен на кластеры размером по 4Кбайта. В тоже время, для совместимости с другими системами UNIX, файловая система может быть поделена на блоки кратные 512 байт.

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

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

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

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

Фрагментация диска

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

Для решения этой проблемы может применяться фрагментация диска на более мелкие структурные единицы - фрагменты (размером по 512, 1024, 2048 и 4096 байт). Размер фрагментов определяется только при создании файловой системы.

Компрессирование файловой системы

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

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

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

Ведение журнала

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

Типовая транзакция содержит в себе следующие операции:

1. При записи информации в файл данные сначала размещаются в оперативной памяти.
2. Каждую минуту выполняется системный вызов sync, который записывает данные в информационные блоки на диске. При этом данные об необходимых изменениях в inodes записываются в специальный файл jfslog (/dev/hd8) размером 4МБ. Этот файл является журналом транзакций журнальной файловой системы. Обновление информации в нём происходит циклически. Такой файл имеется для каждой группы томов.
3. Только после удачной записи всех информационных блоков происходит операция подтверждения COMMIT, о которой также производится запись в jfslog и только после этого происходит обновление в inodes.
4. Завершает транзакцию системный вызов sync.

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

Список файловых систем

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

Команда lsfs также показывает информацию о сетвеых файловых системах (NFS) и файловых системах CD-ROM.

где, опция -q используется если вам нужен вывод информации о размере фрагмента, алгоритме компрессии и количества выделенных байт на inode;
опции -c или -l нужны для указания того, выводить ли информацию в формате колонок или станз, соответственно;
опции -v или -u используются для указания необходимости вывода информации только об определенных файловых системах (в зависимости от типа или точки монтирования, соответственно).

Указание в команде lsfs имени определенной файловой системы выведет информацию только о требуемой файловой системе. Для получения этой же информации вы можете использовать команду smit fs.

Список смонтированных файловых систем

Команда mount используемая без параметров выводит список всех смонтрованных в текущий момент файловых систем.

С помощью SMIT можно получить эту информацию выбрав:

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

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

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

Add a File System on a Previously Defined Logical Volume

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
* LOGICAL VOLUME name
* MOUNT POINT [] +
Mount AUTOMATICALLY at system restart no +
PERMISSIONS read/write +
Mount OPTIONS [] +
Start Disk Accounting? no +
Fragment Size (bytes) 4096 +
Number of bytes per inode 4096 +
Compression algorithm no +

F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

Добавление журнальной файловой системы

Add a Journaled File System

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Volume group name rootvg
* SIZE of file system (in 512-byte blocks) [] #
* MOUNT POINT []
Mount AUTOMATICALLY at system restart no +
PERMISSIONS read/write +
Mount OPTIONS [] +
Start Disk Accounting? no +
Fragment Size (bytes) 4096
Number of bytes per inode 4096
Compression algorithm no

F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

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

Не путайте команду crfs с командой mkfs. В отличие от команды mkfs, команда crfs создаёт, если это необходимо, логический том используя команду mklv, затем строит на нём структуру файловой системы, используя команду mkfs и производит все необходимые изменения в базе ODM и файле /etc/filesytems для соответствующих логического тома и файловой системы.

При создании журнальной файловой системы с помощью команды crfs вы должны будете указать:

-g volgrp - имя группы томов, на которой будет создан логический том. Конечно, эта группа томов должна иметь необходимое свободное пространство для создания нового логического тома;
-a size=SIZE - размер файловой системы в 512-ти байтовых блоках;
-m mntpt - точка монтирования файловой системы (имя директории в существующей файловой системе). В основном точка монтирования не указывается;
-a yes|no - указание необходимости автомонтирования новой файловой системы при перезапуске системы. При указанной точке монтирования по умолчанию (см. выше) файловая система может быть помечена как автомонтируемая. Об этом делается запись mount=true в станзе файловой системы файла /etc/filesystems.
-p rw|ro - режим доступа. Все файловые системы могут быть смонтированы с режимом доступа чтение/запись (rw) или только для чтения (ro). Дополнительным выбором для монтирования файловой системы (Mount Options) может быть указание на запрещение выполнения setuid и setgid программ (выбор nosuid) или запрещение открывать системные вызовы устройств с файловых систем с этой точкой монтирования (выбор nodev).
-a fragment=size - указание размера фрагмента журнальной файловой системы в байтах. Размер фрагмента может принимать значения 512, 1024, 2048 или 4096. Значение по умолчанию - 4096 байт.
-a nbpl=value - указание количества байт на один inode. Влияет на общее количество inodes в файловой системе. Этот параметр может иметь значения 512, 1024, 2048, 4096, 8192 или 16384. Значение по умолчанию - 4096 байт.
-a compress={no|LZ} - указание алгоритма компрессии для файловой системы. Значение по умолчанию - no.

Монтирование/размонтирование файловой системы

Mount a File System

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
FILE SYSTEM name []
DIRECTORY over which to mount []
TYPE of file system
FORCE the mount? no
REMOTE NODE containing the file system
to mount []
Mount as a REMOVABLE file system? no
Mount as a READ-ONLY system? no
Disallow DEVICE access via this mount? no
Disallow execution of SUID and sgid programs
in this file system? no

F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

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

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

Пользователь root может монтировать файловые системы в любом месте иерархии директорий в независимости от установленных прав доступа.

Изменение/просмотр характеристик журнальной файловой системы

Change/Show Characteristics of a Journaled File System

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
File system name /home
NEW mount point [/home]
SIZE of file system (in 512-byte blocks)[8192]
Mount GROUP []
Mount AUTOMATICALLY at system restart yes +
PERMISSIONS read/write +
Mount OPTIONS [] +
Fragment Size (bytes) 4096
Number of bytes per inode 4096
Compression algorithm no

F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

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

При необходимости уменьшить размер файловой системы лучшим выходом является создание новой файловой системы нужного размера с удалением старой.

Удаление журнальной файловой системы

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

Управление файловыми системами

Задачи администратора по управлению дисковым пространством файловых систем следующие:

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

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

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

Для просмотра информации об общем и используемом дисковом пространстве используется команда df. Для показа размера дискового пространства в килобайтах эту команду необходимо запускать с ключом -k.

Контроль над быстрорастущими системными файлами

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

Прежде всего, необходимо контролировать следующие файлы:

ћ /var/adm/wtmp
ћ /var/spool/*.*
ћ /smit.log
ћ /smit.script
ћ /etc/security/failedlogin
ћ /var/adm/sulog

Файлы /var/adm/wtmp и /var/adm/failedlogin читаются командой who -a имя_файла. Остальные файлы редактируются с помощью любого текстового редактора.

Квоты для дискового пространства пользователей

Система квот (ограничений) дискового пространства базируется на Berkeley Disk Quota System и позволяет администратору контролировать количество файлов и блоков данных пользователей или их групп.

Эта система используется в следующих случаях:

Пределы квот устанавливаются тремя параметрами:

Soft limits - определяет количество блоков по 1KB или файлов, на которое пользователь может превысить на определенный период (grace period).

Hard limits - максимальное количество блоков по 1KB или файлов, которое пользователь не может превысить

Grace period - время на которое пользователь может превысить отпущенное ему по soft limits дисковое пространство или количество файлов. По умолчанию - 7 дней.

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

Установка квоты

1 шаг - Включение режима квот Для указания того, что для данной файловой системы установлен режим квот, необходимо вставить в её станзу файла /etc/filesystems следующую строку: для режима квот пользователей: quota=userquota для режима квот пользователей и групп: quota=userquota,groupquota

2 шаг - Установка квот Для создания и редактирования квот используется команда edquota. Эта команда создаёт временный файл, который содержит информацию обо всех текущих квотах каждого пользователя и группы.

где: опция -u используется для редактирования квоты пользователя username; опция -g используется для редактирования квот группы groupname; опция -p используется для указания прототипа квоты (пользователя или группы, имя которых необходимо указать), который используется для копирования ранее установленных квот.

Внимание: Для использования команды edquota должна быть установлена переменная EDITOR (для примера, export EDITOR=/usr/bin/vi).

3 шаг - Установка Grace Period Для установки Grace Period также используется команда edquota с параметрами: -t - для всех пользователей и групп; -tg - для всех групп; -tu - для всех пользователей.

Grace Period можно устанавливать в секундах, минутах, часах или днях. Установка Grace Period в размере 1-й секунды показывает, что Grace Period не предоставляется. Установка 0 определяет Grace Period по умолчанию.

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

Включение режима квот Для включения режима квот используется команда quotaon с параметрами: -u - установка режима квот только для пользователей; -g - установка режима квот только для групп; -a - установка режима квот для пользователей и групп. После параметра можно указать имя конкретной файловой системы, для которой необходимо включить механизм квот. По умолчанию режим квот выключен.

Выключение режима квот Для выключения режима квот используется команда quotaoff. Можно отключить режим квот для всех файловых систем (с параметром -a) или для конкретной файловой системы (указать её имя).

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

Дефрагментация файловой системы

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

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

Проверка файловой системы

Файловые системы могут быть проверены используя команду fsck. Ее синтаксис:

Опция -p указывает на проведение проверки и исправление файловой системы без информирования пользователя обо всех изменениях и без запросов на совершение таких изменений. При запуске проверки файловых систем из SMIT используется эта опция. Опции -y или -n используются для ответов yes или no на все вопросы выдаваемые командой.

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

Если явно не указана файловая система для проверки, то проверяются все файловые системы, для которых в файле /etc/filesystems установлен атрибут check в true. Команда выводит отчет о своей работе в директорию /lost+found.

Документирование установок файловых систем

ћ Запускайте команду lsfs.
ћ Отслеживайте содержимое файла /etc/filesystem.
ћ Запускайте команду df для проверки использования дискового пространства.
ћ Проверяйте все смонтированные файловые системы командой mount.

Пространство пейджинга

Определение пейджингового пространства

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

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

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

Так как оперативная память производства IBM может быть покажется вам довольно дорогой, то можно порекомендовать купить не такую дорогую оперативную память для систем RS/6000 производства компании Kingstone.

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

где РМ - размер пейджингового пространства; М - объем реальной памяти.

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

Использование пейджингового пространства нужно периодически проверять командой lsps -a и в случае превышения показателя использования пейджингового пространства более 70% необходимо добавить дополнительный объем пейджингового пространства.

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

В этом случае пейджинговое пространство paging01 нужно просто удалить (как это сделать смотри ниже), так как оно перегружено, а пейджинговое пространство на том же физическом томе paging00 недогружено.

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

Размещение пейджингового пространства на диске

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

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

Для просмотра состояния всех пейджинговых пространств используйте SMIT или команду lsps -a.

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

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

Размер пейджингового пространства может быть динамически увеличен (но не уменьшен).

Решение проблем с пейджинговым пространством

Проблема: Пейджинговое пространство очень мало.

Решение: Динамически увеличьте размер пейджингового пространства. или Активизируйте неактивные пейджинговые пространства на других физических томах (если оно и они есть в вашей системе).

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

Решение: 1. Создайте пейджинговое пространство меньшего размера с пометкой активации при перезапуске системы.
2. Пометьте большое пейджинговое пространство как неактивное при перезапуске системы (так как нельзя удалить активное пейджинговое пространство).
3. Перезагрузите систему.
4. Удалите неактивное большое пейджинговое пространство.

Примечание: Первое пейджинговое пространство (hd6) не может быть удалено.

Документирование установок пейджингового пространства

1. Периодически запускайте программу мониторинга пейджингового пространства lsps.
2. Распечатайте и храните копию файла /etc/swapspaces.

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

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

Наиболее дешевым вариантом защиты данных от утери в результате аварии является их архивирование на ленту.

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

Удобно архивы использовать для установки программного обеспечения на аналогичные компьютеры или для быстрой его переустановки (создав образ системы).

Типы архивирования

1. Системное архивирование - записывается архивный образ операционной системы (группа томов rootvg).
2. Полное архивирование - сохранение всех данных.
3. Нарастающее (инкрементальное) архивирование - записываются только изменения относительно последнего полного архивирования. Этот тип архивирования самый быстрый, но его необходимо проводить очень внимательно.

Нарастающее архивирование можно проводить двумя методами:

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

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

Стратегия архивирования

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

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

ћ ВСЕ данные пользователей;
ћ ВСЕ изменения системных файлов;
ћ ВСЕ изменения файлов приложений;
ћ ВСЕ данные не принадлежащие группе томов rootvg.

ћ НЕИЗМЕНЯЮЩИЕСЯ файлы приложений;
ћ Программное обеспечение, которое можно быстро переустановить.

Устройства архивирования

Дискеты

Дискета может рассматриваться как устройство, используемое для архивирования малого количества файлов. ОС AIX включает в себя поддержку дисководов 3 1/2" (ёмкостью 1.44МБ и 2.88МБ) и 5 1/4".

Встроенный диковод 3 1/2" обозначается как /dev/fd0. Второй дисковод 3 1/2" или 5 1/4" обозначается как /dev/fd1.

Для форматирования дискеты используется команды format или fdformat:

Команда format форматирует по умолчанию дискету в дисководе /dev/fd0 на максимальный поддерживаемый дисководом объём.

Вы можете определить необходимость форматировать дискету в другом дисководе (опция -d drive) или для дискеты с более низким объёмом (опция -l).

Команда fdformat используется для форматирования дискет только для дисковода /dev/fd0 и форматирует её на меньший объём. Для форматирования с большим объёмом используется опция -h.

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

Для работы с дискетами DOS используйте команды dosdir, dosread и doswrite.

Ленты

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

Поддерживаемыми ленточными устройствами являются:

ћ 1/4" ленточное устройство которое может читать и писать на ленты форматов QIC-120 (120МБ), QIC-150 (150МБ), QIC-525 (525МБ) и QIC-1000. Это устройство так-же может читать ленты в формате QIC-24 (44МБ);
ћ 4мм ленточные устройства (2ГБ или 4ГБ);
ћ 8мм ленточные устройства (2.3ГБ или 5ГБ);
ћ 1/2" 9-ти дорожечные устройства с поддержкой форматов 1600bpi и 6250bpi.

Ленточные устройства обозначаются как /dev/rmtX, где X - номер устройства.

Для управления ленточным устройством его подразделяют на подустройства с номерами от /dev/rmtX.1 до /dev/rmtX.7. Так сделано для того, чтобы была возможность:

ћ после завершения операции чтения или записи предохранить ленту от перематывания;
ћ удерживать ленту при первом доступе к ней. Причём 1/4" устройства имеют аппаратные установки, которые имеют больший приоритет для устройства, чем программные установки;
ћ использовать формат низкого объёма.

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

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

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

Агент ретрансляции BOOTP

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

Агент ретрансляции BOOTP стартует и останавливается подобно серверу DHCP.

Конфигурация завершатся внесением строки в файл /etc/dhcprd.cnffile. Агент ретрансляции пошлёт пакет всем серверам, определенным в этом файле.

Требования к дисковому пространству для сервера DHCP

Требования к дисковому пространству для сервера зависят от числа клиентов. Требуемое дисковое использование для поддержки одного клиента - 360 байт.

Решение проблем и настройка производительности в сети TCP/IP

Декомпозиция проблемы

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

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

Если сетевая конфигурация неизвестна, используйте команду ping -R hostname и/или команды traceroute. Опция - R команды ping допускает использование возможности записи маршрута IP. Отрицательный результат выполнения ping означает, что не работает или узел или сеть. Для того, чтобы узнать, что именно не работает, требуется воспользоваться другими средствами. Команда ping также не дает информации о состоянии узла-адресата. Команда traceroute, аналогично выводит маршрут, который пакеты IP берут на сетевом узле, но накапливает информацию немного по-другому.

Команда traceroute использует два способа прослеживая передачу информации до адресата: маленькое значение ttl (время жизни) и отказавший номер порта.

Traceroute запускает пакеты UDP с маленькими значениями ttl, чтобы обнаружить промежуточные маршрутизаторы. Команда traceroute была создана для сетевого тестирования, измерения и управления. Вы должны использовать её прежде всего для обнаружения неисправности вручную. Из-за нагрузки, которую она налагает на сеть, вы не должны использовать команду traceroute в течение нормальных операций или из автоматизированных сценариев.

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

Чтобы создания полного обзора эффективности и конфигурационной информации сети, используйте пакет PerfPMR. Чтобы получать наиболее полные данные о сети вы должны выполнить команду perfpmr 3600 в тот час, когда нагрузка на сеть является максимальной. Выходные файлы этой команды появятся в каталоге /var/perf/tmp.

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

Поймите проблему

Ограничивают производительность TCP/IP в AIX обычно следующие факторы:

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

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

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

Настройка эффективности работы CPU является предметом особого рассмотрения и в этой книге не приводится.

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

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

Выбор "правильного" инструмента

Для контроля и настройки современных гетерогенных сетей администраторы должны иметь соответствующие инструментальные средства.

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

Для физического уровня: тестер (TDR)

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

Для канального уровня: команда ifconfig

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

Для сетевого уровня: команда tokstat

Команда tokstat отображает статистику, определенного драйвера устройства Token-Ring.

Для сетевого уровня: команда ping

Команда Packet InterNet Groper (ping) посылает дейтаграмму ECHO_REQUEST протокола ICMP (не требует наличия серверных процессов на зондируемом узле) на конкретный узел, чтобы определить является ли этот узел доступным. Часть ответа, которую вы получаете от ping - это время передачи дейтаграммы туда и обратно.

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

Для сетевого уровня: команда traceroute

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

Для сетевого уровня: команда iptrace

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

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

Для транспортного уровня: команда tcpdump

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

Для канального, сетевого и транспортного уровней: команда netstat

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

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

Или, если команда netstat -s показывает, что существуют ошибки протокола, вы могли бы затем использовать команду iptrace для детализированного анализа.

Для канального, сетевого и транспортного уровней: команда netpmon

Этот инструмент контролирует и выдаёт статистику сетевого ввода-вывода и связанного с обслуживанием сети использования CPU.

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

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

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

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

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

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

Для уровней от канального до прикладного: Performance Reporter

Ранее было невозможно получить сводное представление обо всех системах и сетевой эффективности в сложной и распределенной среде. IBM SystemView for AIX Performance Reporter (Performance Reporter) устраняет эту проблему обеспечивая эффективные, информативные отчеты основанные на данных, сгенерированных из встроенной базы данных. Этот инструмент позволяет часто обнаруживать возможные проблемы до их возникновения.

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

Вы можете собрать информацию о производительности с узлов под управлением AIX, Sun Solaris, и HP-UX. Вы можете легко использовать данные из базы данных Performance Reporter в других прикладных программах. Модель данных хорошо зарегистрирована и просто изменяется.

Безопасность

Система безопасности AIX соответствует уровню безопасности С2. Этот стандарт предъявляет к системе основные шесть требований:

Свидетельство на соответствие уровню безопасности не гарантирует того, что система защиты совершенна. Наличие свидетельства просто говорит о том, что система прошла тесты на соответствие уровню безопасности.

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

Политика безопасности

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

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

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

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

От кого защищаемся?

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

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

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

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

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

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

Сколько нужно безопасности?

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

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

Компьютерные уровни защиты, определенные U.S. Department of Defence стали для большинства основными критериями при закупке систем. Этими уровнями по возрастанию, являются D, C1, C2, B1, B2, B3, и A.

Уровни "C" имеют контролируемые средства управления защиты. То есть, пользователь решает, какие его ресурсы защищать и управляет (до некоторой степени) тем, как эта защита применяется.

Уровни "B" имеют обязательные средства управления защитой (наряду с другими дополнительными функциями). Средства управления автоматически применяются системой.

Уровень "A" является столь необычным, что имеется только несколько примеров его практической реализации.

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

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

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

Общие дефекты защиты

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

3) недостаточные ограничения на доступ к директориям.

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

Однажды зарегистрировавшись в системе "злоумышленник" часто использует "программы устанавливающие userid" (обычно называемые suid), чтобы получить более широкий доступ к системе. Функция suid - не дефект (см.Биты доступа (Продвинутые)); она является необходимой частью UNIX. Нарушение безопасности вызывает неправильное употребление suid.

AIX не поддерживает suid для командных файлов оболочки (shell scripts). И это одно из основных отличий AIX от многих других UNIX систем, что является определенным расширением защиты.

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

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

Эти три дефекта (недостаточные пароли, программы suid, и установка разрешений на директории) объясняют многие общие проблемы защиты UNIX.

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

Физическая защита

Физическая защита имеет несколько аспектов, включая:

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

Концепция безопасности AIX

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

Предопределены следующие пользователи: root - супер пользователь с максимально широкими полномочиями adm, sys, bin, ... - идентификационные номера используемые системой и которые нельзя использовать для входа в систему пользователям.

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

Первоначально существуют две группы: system - для администраторов user - для обычных пользователей

Группы

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

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

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

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

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

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

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

system для основной конфигурации и поддержки стандартного аппаратного и программного обеспечения.

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

staff предопределенная группа для всех новых пользователей системы

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

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

Для изменения наименования группы, заданной по умолчанию для новых пользователей, отредактируйте станзу pgrp в файле /usr/lib/security/mkuser.default. В этом файле содержатся значения по умолчанию для команд mkuser и smit. Например, чтобы заданная по умолчанию группа имела имя office, отредактируйте файл /usr/lib/security/mkuser.default следующим образом:

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

Группа администрации определена в файле /etc/security/group станзой admin. В каждой группе может иметься свой администратор группы. Это определено в строфе файла /etc/security/group.

Не запутайтесь с указанием административных прав. Если значения admin=true находится в /etc/security/group (см.Файлы /etc/group и /etc/security/group), то это указывает административную группу. Но admin=true в файле /etc/security/user (см.Файл /etc/security/user) означает, что пользователь имеет административные права для той специфической группы, которая указана в станзе adms файла /etc/security/group. С admin=true, пользователь может управлять той группой.

Включение пользователя в административную группу не имеет большого эффекта в AIX. Для небольших систем рекомендуется игнорировать административные группы и пользователей. В этих системах для выполнения управления пользователями нужно использовать права root. Большие же системы (более чем с 30 или 40 пользователями) могли бы нуждаться в администраторах групп.

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

В AIX включена группа, именованная security. Любой член этой группы может читать все файлы администрирования пользователями в каталоге /etc/security (см. Теневые файлы), и может выполнять многие из команд управления системой. С небольшим усилием, член группы security может получить полномочия root. Следовательно, только самые доверенные сотрудники должны быть в этой группе.

Стандартные userids

AIX имеет userid и группы, которые необходимы системе. Не изменяйте параметры этих пользователей и групп, если, конечно, Вы не очень уверенны в том, что Вы делаете :-). Никогда не входите в систему с любым из этих userid (за исключением root).

Идентификаторы пользователя, которые включены в систему (в форме, в которой они описаны в /etc/passwd) перечислены ниже. Эти идентификаторы используются для различных целей, типа монопольного использования файла и функций NFS. Все они, за исключением root, являются заблокированными для входа в систему в распределенной системе. (Они заблокированы паролем = * в /etc/security/passwd):

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

groupids, которые включены в систему - (в форме, в которой они появляются в /etc/group):

Настоятельно не советуется назначать пользователей в любую из перечисленных выше групп (за исключением staff), если, конечно, вы не уверенны относительно последствий таких действий. Некоторые из этих групп (типа system, bin, security, cron) - владельцы совокупности многих важных файлов и директорий. Включение пользователя в любую из этих групп, с небольшим усилием, может скомпрометировать любые средства информационной безопасности в системе.

Пользователи

Все пользователи в системе, в соответствии с их правами, разделены на три категории:

2. пользователи с административными правами (группы security, system, printq, cron, adm, audit). Особого внимания заслуживают пользователи включенные в группу security, так как они могут добавлять/удалять/изменять других пользователей или группы;

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

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

Набрать команду: # cat /etc/security/user и в станзе описания пользователя внести следующее:

Переменная PATH

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

Одна из целей защиты состоит в том, чтобы защитить root (или любого другого пользователя) от выполнения поддельной программы. Например, если /tmp (незащищенный каталог) - первый элемент в PATH и если злоумышленник поместит программу под именем su в /tmp, эта программа su будет выполнена вместо правильной программы su системы.

Дефект PATH - простое понятие и вы, как администратор системы, должны понять это. PATH пользователя обычно устанавливается (используя профиль системы и профиль пользователя (если они существует)), когда он регистрируется в системе. Домашней директорией пользователя root обычно является директория root и файл /.profile (если он существует) будет выполнен, когда root регистрирует в систему. Если же мы получаем полномочия root используя команду su профиль root (это верно и для получения полномочий любого другого пользователя командой su) автоматически не выполняется. (Использование флажка "-" с командой su заставит профиль целевого пользователя быть выполненным, но это может иметь последствия на текущем пользователе. Обычно, флажок "-" не используется с su.)

Например, если вы регистрируетесь в системе как обычный пользователь и затем даёте команду su root, вы продолжаете использовать профиль (и PATH), установленный первоначальным профилем пользователя. Это может быть источником серьезных нарушений защиты, подобных этой:

1. Пользователь (желающий получить пароль root) пишет маленькую программу на C, выводящую сообщения, аналогичные сообщениям команды su. То есть, эта программа попросит вас ввести пароль root.

2. Пользователь компилирует и линкует эту программу и помещает её в свою библиотеку.

3. Пользователь изменяет свой PATH таким образом, чтобы первой директорией в поиске была его личная (home) директория.

4. Пользователь просит администратора решить какую-нибудь проблему, решение которой, вероятно, требует прав доступа root.

5. Администратор приходит к терминалу пользователя и использует команду su, чтобы получить полномочия root. Когда администратор вводит команду su, система ищет программу с именем su сначала в личной директории пользователя (как установлено в PATH пользователя) и находит подделанную программу su и выполняет её.

6. Программа su пользователя запрашивает ввод администратором пароля root, сохраняет пароль в невидимом файле, посылает сообщение об ошибке о вводе неправильного пароля и стирает саму себя.

7. Администратор думает, что он ввел неправильный пароль и пытается снова выполнить команду su root. Сейчас всё функционирует нормально, так как подделанная программа уже удалена и сеанс продолжается как обычно.

8. Пользователь позже читает пароль root из невидимого файла и может войти в систему как root.

Это - классическое нападение "Троянского коня", и оно сработало, потому что администратор выполнил команду su используя неправильный PATH.

Для защиты от таких нападений на систему безопасности, рекомендуется следующее:

1. Администратор, при получении полномочий root, если он работает в среде другого пользователя, должен всегда вводить полное имя пути команд. Это позволит избежать использования PATH пользователя.

2. В PATH для обычного пользователя первыми в пути поиска должны быть стандартные директории системы, перед текущей директорией или специфической директории $HOME. Заданный по умолчанию путь (установлен значением по умолчанию) для AIX: PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:. Поддиректории внутри /usr содержат большинство команд AIX, используемых обычными пользователями. Директория /etc содержит символьные ссылки на команды в более удаленных директориях. Обратите внимание, что сначала ищутся библиотеки системы. И только после этого поиска просматриваются программы в $HOME/bin. "Точка" в последней позиции PATH указывает на поиск в текущей директории.

Игнорируя малые элементы (X11 и /sbin), порядок поиска PATH следующий: директории системы, директория программ пользователя(/$HOME/bin) и текущая директория. Это - безопасный порядок поиска, хотя можно спорить о том, должна ли текущая директория ("точка") быть в пути поиска.

Блокировки по времени

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

По умолчанию блокировка по времени не включена. Для установки блокировки по времени Korn shell использует переменную TMOUT, а Borne shell использует переменную TIMEOUT. Вы, как администратор, должны установить одну или обе из этих переменных, если Вы хотите автоматически блокировать оболочку после чрезмерного неактивного состояния.

Настоятельно рекомендуется использовать эту функцию, потому что терминалы без присмотра - серьезное нарушение защиты. Например, добавьте строки в файлы /etc/profile или к /etc/security/.profile:

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

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

Подсказки (Prompts)

Вы можете устанавливать подсказку оболочки, чтобы показать на экране информацию о текущей директории. Для пользователей оболочки Korn, это выполняется путём добавления следующих двух строк в профиль $HOME/.profile:

Это изменение обеспечивает выведение пути и имени текущей директории, сопровождаемых традиционным символом "$". К сожалению, эта простая методика вводит в заблуждение, если пользователь выполняет команду su root. "$" будет всё еще появляться вместо символа "#" который является традиционным для su root.

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

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

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

Отключение userid root

Редко имеется необходимость для регистрации в системе пользователем root. Большинство "несчастных случаев" в системах UNIX часто вызваны использованием root, как стандартного userid. Поэтому, после того, как ваша система сконфигурирована, вы можете отключить возможность входа в систему как root. Уполномоченные пользователи (те, кто знают пароль для root) могут пользоваться командой su root после того, как они вошли в систему под их обычными userids.

Отключение root легко выполняется с помощью SMIT:

Не отключайте пользователя root, напрямую редактируя файл /etc/passwd и изменяя поле пароля. Такое действие запретит вам использование полномочий root с помощью команд su или telnet.

Аудит безопасности

Файл /var/adm/sulog содержит информацию в ASCII формате о дате, времени, имени системы и имени пользователя, которые входили в систему. Этот файл можно просмотреть командами pg, more или cat. Этот файл также фиксирует тот факт, была ли попытка входа в систему удачной или нет.

Файл /etc/utmp содержит информацию о текущих пользователях системы.

А файл /var/adm/wtmp содержит информацию о времени нахождения пользователей в системе (фиксирует время входа и выхода из системы). Для просмотра этой информации используйте команду who file_name. Команда who без параметров показывает содержимое файла /etc/utmp.

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

Существует также еще один важный файл, просматриваемый командой who. Это файл /etc/security/failedlogin, из названия которого следует, что в него заноситься информация каждый раз при неправильном вводе имени и/или пароля при входе в систему. Нераспознанные имена пользователей записываются как UNKNOWN.

Проверка пользовательского окружения

Для поддержки системы безопасности вы можете воспользоваться некоторыми "проверяющими" командами (grpck, usrck, pwdch, sysck, tcbck) и "списочными" командами (lsuser и lsgroup) доступными для использования пользователю root (или любому пользователю из группы security).

Команда grpck

Команда grpck проверяет для всех пользователи, поскольку члены группы определены как пользователи, что их gid уникальны, и что имя группы правильно сформировано. Также выполняются другие небольшие проверки. Флажок -t заставляет команду сообщать об ошибках и спрашивать относительно разрешения об их устранении: grpck -t ALL

Эта команда проверяет среду группы, и, если Вы отвечаете Yes на запрос, будут стёрты userids, которые не существуют или для которых станзы в файле /etc/security/user имеют противоречивые данные.

Команда usrck

Команда usrck проверяет много параметров области определения userid. Флажок -t заставляет команду сообщать об ошибках и спрашивать относительно разрешения об их устранении. В некоторых случаях команда отключит userid, добавляя дату окончания в область определения пользователя. На данные пользователя эта команда не воздействует. Пользователя можно допустить в систему снова, удаляя добавленную дату окончания (используя SMIT или непосредственно редактируя файл /etc/security/user).

usrck -t ALL Никогда не пробуйте исправлять userid root, используя эту команду. Если Вы хотите попробовать это сделать, пожалуйста сначала прочитайте о восстановлении root userid (см.Восстановление root userid).

Команда pwdck

Команда pwdck проверяет опознавательные станзы в файлах /etc/passwd и /etc/security/passwd. Если что-то неправильно, стандартным действием этой команды является удаление станзы или создание станзы /etc/security/passwd с * (звездочкой) в поле пароля. Запустив эту команду нижеуказанным синтаксисом вы получите сообщение о проблемах и отчет об их фиксации: pwdck -t ALL Команда pwdck не проверяет определенные правила задания пароля, типа minalpha, minother, и lastupdate.

Команды lsgroup и lsuser

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

В форме, показанной выше, эти команды создают файл /tmp/check и пишут в него свой вывод.

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

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

Команда tcbck

Эта команда описана подробно в Trusted Computing Base (см.Trusted Computing Base).

Функции Ревизии (Аудита)

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

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

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

Когда запущена контрольная подсистема, она ревизует (то есть генерирует запись вывода) для событий и объектов.

Могут быть определены два различных режима записи: BIN и STREAM.

Контрольные События

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

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

Ревизия События ВСЕГДА связывается с userid (или userids). Например, вы можете отслеживать создание директорий пользователем joe.

Имеются приблизительно 130 различных контрольных событий, встроенных в AIX. Контрольные события сгруппированы в классы. Имена классов произвольны.

Контрольные Объекты

В дополнение к отслеживанию событий, вы можете ревизовать объекты. Практически, - следить за файлами.

Вы можете контролировать три файловые операции: чтение, запись и выполнение. Объекты не связаны с пользователями.

Механизм для ревизии объекта генерирует псевдособытия, и этот процесс работает очень подобно ревизии событий. Вы можете легко добавлять дополнительные файлы, включая ваши файлы прикладных программ, в список контрольных объектов, расширяя файл /etc/security/audit/objects.

Команды аудита

ћ Audit start - используется для активизирования подсистемы контроля. Это - единственно правильный способ начать ревизию.

ћ Audit shutdown - прекращает работу подсистемы контроля, производится обработка заключительных записей BIN (если необходимо) и удаляется файл /audit/auditb, который используется как "активный" индикатор контрольных моду-лей.

ћ Audit off - временное приостановление ревизии. Например, при контрольном закрытии системы нет необходимости использовать ревизию.

ћ Audit on - включение подсистемы контроля после временного ее выключения командой audit off.

ћ Audit query - отображение состояния подсистемы ревизии.

Ограничения доступа к файлам/директориям

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

Стандартные ограничения r (read), w (write) и x (execute) определяют три уровня доступа для пользователя (владельца), группы (group) и остальных (others). В добавление к этим трем ограничениям существуют три бита доступа известные как SUID (set UID), SGID (set GID) и SVTX (sticky bit).

Бит SUID, установленный на исполняемом файле, означает, что при выполнении этого файла процесс выполняется с эффективным идентификатором пользователя (UID) владельца файла. SUID не поддерживается для командных файлов оболочки (shell scripts). Бит SUID никак не относится к директориям.

Бит SGID, установленный на исполняемом файле, означает, что при выполнении исполняемого файла процесс выполняется с эффективным групповым идентификатором (GID) группы владельца файла. Бит SGID, установленный для директории означает что каждый файл или директория создаваемые в этой директории имеют те же групповые разрешения что и первичная группа пользователя, создающего новый файл/директорию.

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

Файловая защита AIX

Файловая защита - наиболее очевидный элемент защиты для большинства пользователей AIX. Базисными элементами, управляющими защитой файла в локальной системе являются:

ћ Биты разрешения, связанные с файлом.
ћ Биты разрешения, связанные с директорией, содержащей имя файла.
ћ Биты разрешения во всех директориях в пути к файлу.
ћ Списки разрешений ACL.
ћ Владелец файла.
ћ Группа-владелец файла.
ћ Владелец и группа-владелец директории, в которой размещен файл.
ћ Владельцы и группы-владельцы всех директорий высшего уровня в пути к файлу.
ћ Программы, выполняющиеся с эффективным userid пользователя root.

Частные файловые системы

Если вы создаете дополнительные файловые системы, рекомендуется, чтобы точки монтирования директорий имели биты разрешения -rwx ------- (восьмеричный 700).

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

Пользователь мог бы взять свою переносимую файловую систему, добавить suid-программы root. Когда эта файловая система установлена на вашей системе, все эти suid-программы root могли бы быть агрессивными.

Администратор имет некоторый контроль над установкой частных файловых систем (Одна из опций mount - nosuid. Рекомендуется всегда использовать эту опцию при установке переносимых файловых систем (включая CD-ROM), и (возможно) при установке любой частной файловой системы).

Inodes и Links

Нормальные файловые системы UNIX (включая JFS AIX) используют уровень косвенного управления файлами, который обычно скрывается от пользователя.

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

Доступ к данным файла в UNIX - обычно подобен такой процедуре:

То есть запись для файла в директории не указывает на данные файла. Она указывает на inode, который, в свою очередь, указывает на данные.

Биты разрешения защиты относятся к inode, а не к записи для файла в директории. Запись в директории содержит "имя" для файла, типа /u/trial/data.

inode имеет номер идентификации, но не "имя" файла.

В этом примере, одиночный файл (основанный на inode 317 внутри некоторой файловой системы) имеет три директории "связи". Тот же самый файл имеет три очень различных "имени". Биты Разрешения (и UID и GID) сохранены в inode. Вызов к файлу через любое из имен будет обеспечивать те же самые разрешения и средства управления владельца. Эти имена дополнительного пространства обеспечиваются символическими связями. (Символическая связь может функционировать между различными файловыми системами, и не удаляется, если адресат inode удален.

Жесткая связь работает только внутри конкретной файловой системы и может быть элементом управления в удалении данных файла и inode.)

Подобные связи могут существовать и на уровне директории (т.к. директория - частный случай файла). Например, директория /xxx могла бы быть символически связана с директорией /etc. Это означает, что файл /xxx/my/data - на самом деле является файлом /etc/my/data. К одному и тому же самому файлу обращаются в обоих случаях, хотя используются различные структуры директорий. Значение защиты связей директорий обсуждены позже.

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

Каждый файл (включая директории) имеет владельца и группу. Владелец и идентификаторы группы владельца (UID и GID) сохранены в inode. Изначально владелец это пользователь, который создал файл. Группа - текущая группа владельца, когда он создаёт файл. Пользователь root может изменять владельца файла, используя команду chown, и может изменять группу владельца с командой chgrp.

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

Обратите внимание, что монопольное использование соответствует UID (владельца) и GID (группы владельца), а не его userid и groupid. Если userid (и его соответствующий UID) удален из системы, файлы, принадлежащие этому UID остаются в системе. Удаление userid не удаляет его файлы. Однако, в этом случае файлы, как кажется "не имеют" владельца. Но как только другой, позже назначенный userid, получит тот же самый UID, то он станет владельцем всех файлов, связанных с этим UID.

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

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

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

Биты доступа (Базовые)

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

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

Биты доступа часто отображаются как девять битов (три старших системных бита отображаются специальными способами).

Разрешения - не являются иерархическими; то есть разрешение на запись или на выполнение не включают в себя разрешения на чтение.

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

Команда ls

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

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

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

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

Вторая форма, ls -ld, отображает информацию относительно текущей директории.

Третья форма, ls -l /some/file/name, отображает информацию относительно специфического файла.

Последняя форма, ls -ld /some/directory, отображает информацию относительно определенной директории.

Биты установки UID, установки GID, и sticky ("липкие") биты описаны далее.

Userid владельца показывается всеми длинными формами команды li.

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

Inode содержит UID и GID владельца, не имена. Если UID (или GID) больше не зарегистрирован в файлах /etc/passwd (или /etc/group), вместо имени отображается номер (UID или GID).

Биты доступа (Продвинутые)

UNIX использует 12 битов доступа. Из них, девять - базисные r/w/x разрешения для владельца/группы/остальных. Три остающихся бита несколько более сложны. Это:

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

Suid бит отображается, изменяя бит "x" для владельца "rwx" на "s", и т.д. Suid бит означает, что программа выполнится с полномочием UID владельца файла. (Исполняемые файлы обычно выполняются с полномочиями UID того пользователя, который зарегистрировался в системе и имеет права на выполнение данного файла.)

Файл myprog имеет набор битов suid. Если я (зарегистрированный в системе как пользователь alex) выполняю myprog, то эта программа выполнится с полномочием root. Так как root может обходить почти все средства управления защиты, такое средство могло бы быть опасно.

Например, в приведенном примере, myprog могла бы быть копией оболочки (или чем-то подобным). Выполняя myprog (с suid root), я действительно стал бы root. Я мог бы вводить любую команду системы, использующую эту оболочку, и эти все команды выполнятся с полномочиями root.

Такая ситуация (оболочка с suid root) является мечтой "злоумышленников". Вот почему в AIX сделано так, что suid-бит не может быть установлен для оболочки и ее командных файлов.

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

Suid бит может быть установлен (использование команды chmod) только владельцем файла или root. Он автоматически удаляется при копировании командой cp.

Не имеется никакой прямой возможности для обычного пользователя, чтобы создать файл suid root.

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

В данном примере любому пользователю разрешено запускать программу myprog. Но только userid alex может обращаться к mydata. Так как любой может выполнять myprog, и так как myprog использует suid, чтобы выполниться как alex, любой пользователь может обращаться к mydata только, выполняя myprog.

Типичная система AIX имеет несколько сотен программ suid root. Администратор многопользовательской системы должен гарантировать, что любые добавления (новые программы, которые suid root) получены из доверенного источника, - доверенные про-граммы.

В AIX имеются средства, который может помочь управлять доверенными программами (см.Trusted Computing Base).

Бит установки GID (sgid) работает точно так же как функция suid, используя тождество группы файла вместо тождества владельца. Sgid бит имеет специальное значение, когда используется с директорией, где он определяет, как назначено групповое монопольное использование для новых файлов.

AIX игнорирует suid и sgid биты при выполнении сценариев оболочки. То есть только компилируемые "программы" объектного кода могут быть suid к другому UID для выполнения. Некоторые системы UNIX разрешают сценарии оболочки к suid.

В принципе, это полезно. Практически, это очень опасно и было удалено из AIX.

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

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

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

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

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

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

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

Переменная umask

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

По причинам, возвращающимся к ранним дням UNIX, значение umask используется нечетным способом. То есть заданные по умолчанию разрешения устанавливаются, принимая разрешения ("rwxrwxrwx" (или восьмеричный 777) для директорий, или "rw-rw-rw-" (или восьме-ричный 666) для обычных файлов) и удаляя биты разрешения, определенные в umask (которая всегда выражается в восьмеричном формате).

Значение по умолчанию umask - 022. Следовательно, заданные по умолчанию разрешения: 666 удаляя 022 = 644 = rw-r--r-- (для файла) 777 удаляя 022 = 755 = rwxr-xr-x (для директории)

Для большей безопасности рекомендуется вместо значения 022 использовать значения 027 или 077: 666 удаляя 027=640=rw-r----- (для файла) 777 удаляя 027=750=rwxr-x--- (для директории)

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

Не имеется никакого способа предписать стандартное значение для пользователей. Различное значение по умолчанию может быть установлено размещая команду umask в файле $HOME/.profile пользователя. Однако, пользователь может изменить это значение в любое время.

Начальное значение umask пользователя может быть установлено через SMIT. Вы можете проверять ваше значение по умолчанию с командой umask (без операнда).

Файловые временные штампы (Timestamps)

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

1. atime. Это - время последнего обращения к файлу. В действительности, это - время последнего открытия файла.

2. ctime. Это - время последнего изменения inode для файла. (Это - не время создания, если, конечно, создание файла не было последним событием для него) inode изменяется, всегда, когда изменены разрешения, изменен владелец, изменен размер файла (число кластеров), и т.д.

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

Длинные формы команды ls обычно вносят в список mtime. Флажок -c может исполь-оваться, чтобы взамен внести в список ctime. Флажок -u может использоваться, чтобы внести в список atime. Команда может ссылаться все три timestamps.

Команды ACL

AIX имеет дополнительную функцию защиты для файлов. Это - так называемый список управления доступа (ACL). Эта функция - не стандартная часть "традиционного" UNIX. Современные системы UNIX обычно имеют функцию ACL-типа, но команды и функциональные возможности отличаются в различных системах.

ACL в AIX может обеспечивать намного более детальное управление доступом, чем с использованием битов доступа. Обычно, явное управление с помощью ACL не используется для АРМ. Это может использоваться внутри специфических прикладных программ на серверах.

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

Базовые разрешения

Основные разрешения показываются acl-касающимися командами в следующем формате:

атрибуты: SUID, or SGID or SVTX в любой комбинации базовых разрешений:
владелец (имя): rw
группа (группа): r-x
остальные: -wx

Где: SUID означает setuid SGID означает setgid SVTX означает Savetext (липкий бит)

Расширенные разрешения

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

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

Ключевые слова определены следующим образом:

permit предоставляет пользователю или группе доступ.

deny запрещает пользователю или группе доступ.

Когда и пользователь и группа определены в расширенном разрешении только комбинация конкретного пользователя и группы получает доступ. Имеется отношение "и" между элементами в списке. Значение по умолчанию - заблокированное ключевое слово. Использование chmod с восьмеричным операндом - один из способов установить заблокированное состояние.

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

Первая строка расширенных разрешений описывает состояние: допускаемое или заблокированное.

Если заблокировано, расширенная ACL информация не имеет никакого эффекта; только основные разрешения эффективны.

Вторая строка явно допускает, что dhs имеют для файла разрешения на чтение (r) и запись (w).

Третья строка определенно запрещает разрешение на чтение (r) только пользователю chas, когда он - член группы system.

Четвертая строка допускает, что lena имеет доступ на чтение (r), если она - член групп gateway и mail.

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

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

Например, пользователь может принадлежать GROUP1 и GROUP2. Данный ACL может обеспечивать доступ для чтения для GROUP1 и для выполнения для GROUP2.

1. Если SPECIFY операнд существует для любой из групп пользователя (или для его собственного userid), SPECIFY установит максимальный уровень доступа. Если множитель SPECIFY, существуют (для различных групп и-или userid), используется знаменатель SPECIFY.

2. Все PERMIT (положительные) разрешения доступа (для пользователя и всех его групп) суммируются.

3. Все DENY (отрицательные) ограничения (для пользователя и любой его группы) вычитаются.

Результат при наличии ограничений SPECIFY ограничиваются ими.

Функция DENY является более мощной чем функции PERMIT, так как один DENY может отменять любой PERMIT. Этот результат может удивлять пользователей и администраторов, но это - логический результат. Если пользователю не удается получить доступ к файлу и вы не можете понять, почему, то вы должны проверить список доступа ACL на наличие операндов DENY связанный с groupids пользователя.

Тот же самый эффект может быть вызван операндом SPECIFY.

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

Команда acledit позволяет владельцу управлять доступом к файлу (используя редактор, определенный системной переменной EDITOR). Поэтому системная переменная EDITOR должна определить полный путь к редактору.

Команда chmod

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

Операнды сhmod могут быть восьмеричными (иногда называемыми "абсолютными") или символическими. Использование восьмеричного операнда отключит связанные с файлом расширенные параметры ACL (если они установлены). Если вы использует расширенный списки доступа ACL, вы должны использовать команду chmod с символическими операндами при работе файлами, содержащими расширенные списки доступа ACL.

Например, администратор должен использовать chmod + rw myfile, а не chmod 644 myfile. Это может быть непривычное требование, и очень трудно не забыть не использовать восьмеричную запись. Почти возможно предписать использование только символического операнда.

Команда tcbck может размещать файлы с заблокированным расширенным ACL (см.стр.139).

Регистрация ошибок в AIX VERSION 4

Дефекты Защиты иногда случаются из-за ошибок. AIX имеет хорошую систему регистрации ошибок.

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

SMIT -Problem Determination --Error Log ---Generate Error Report Change / Show Characteristics of Error Log Clean Error Log

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

Рекомендуется, чтобы регистрация ошибок всегда была активна (запуск демона errdemon при старте системы).

Для работы с системой регистрации ошибок используйте меню SMIT:

Вы можете ограничивать размер файла регистрации ошибок.

Другие комментарии

В AIX как и другие системы UNIX использование символических связей тяжело. Команда ls -l обозначает их со стрелкой в поле имени и "l" как первый символ поля разрешений.

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

В вышеупомянутом примере, любой работающий с u должен работать под набором разрешений home (в этом примере, u и home- директории, но то же самое понятие применяется и к директориям и к файлам).

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

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

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

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

Обратите внимание, что имеется команда AIX, с именем test, так что пользователи должны избежать создавать файлы, с именем "test".

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

Файлы unowned

Ненаходящиеся в собственности файлы (unowned files) обычно появляются, когда пользователи удаляются из системы. Когда пользователь удален (через SMIT, например), все его файлы (и его исходная директория) остаются. Эти файлы перечислены системой (с ls или командами li) с числовым UID. Пользователь может также иметь файлы в других местах: например, на архивной ленте или файлы mailbox.

Команда find может использоваться, чтобы внести в список все файлы, принадлежащие специфическому пользователю. Использование команды find / -user username -print формирует список всех файлов принадлежащих username. Эти файлы могут затем быть проверены, и нужные распределенны другим пользователям (используя команду chown). Остальные могут быть удалены. Чтобы проверять систему для ненаходящихся в собственности файлов используйте команду find / -nouser -print.

Будьте внимательны - некоторые системные файлы будут включены в этот список, особенно /dev/console. НЕ удалите их!!

Сетевая безопасность

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

3. Сетевые операции Uucp. (Теоретически, это - подмножество dial-in соединений, но на практике соединения uucp должны рассматриваться отдельно).

Физическая защита связи

Сетевая защита включает, и физическую защиту и логическую защиту. Физическая сетевая защита не будет обсуждена.

Сетевые цели защиты

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

2. Установление подлинности и управление доступом (для входа в систему, передачи файла, выполнения удаленных команд) для вашей системы.

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

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

Новые технологии могут устранять некоторые из самых серьезных изъянов сетевой защиты.

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

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

Команда securetcpip

Некоторые команды TCP/IP относительно обеспечивают опознавательную среду в течение их действия. Эти команды - ftp, rexec, и telnet. Эти команды обеспечивают функции защиты только в рамках их собственного действия. Они не обеспечивают безопасную среду для других команд.

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

Команда securetcpip отключает слабозащищенные "стандартные" команды TCP/IP. Рекомендуется использовать команду securetcpip на всех системах в вашей сети, если, конечно не имеется сильной необходимости использовать эти "стандартные" команды.

securetcpip - сценарий оболочки, который отключает команды и демоны, редактируя внешне связанные станзы в файле /etc/inetd.conf и использует команду chmod, чтобы установить разрешения для выполнимых команд в 000 (---------).

Перед выполнением команды securetcpip вы должны отключить исполняющиеся программы работы с сетью. Если различные сетевые демоны запущены с помощью SRC, то они останавливаются следующим образом: STOPSRC -G TCPIP Эта команда останавливает все демоны, связанные с TCP/IP. Затем вы можете ввести команду: SECURETCPIP

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

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

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

Команда securetcpip создает файл /etc/security/config, который содержит станзы, которые ограничивают использование $HOME/.netrc, ftp и rexec. После выполнения этого, ваши пользователи должны использовать команду telnet вместо rlogin или rsh, ftp вместо tftp и rcp, и rexec вместо rsh.

Обратите внимание: вашим X-станциям может быть необходим tftp, чтобы загружать код X-сервера из AIX. Вы должны проверить, что ваши X-станции могут функционировать без tftp, перед выполнением securetcpip.

Важные файлы TCP/IP

Файл /etc/hosts

Файл /etc/hosts описывает сетевые узлы, которые локальная система идентифицирует именами. В файле описывается соответствие имени узла его IP адресу. Типичный пример файла /etc/hosts:

Файл /etc/hosts используется только тогда, когда неактивен сервер имен (сервер DNS), или если сервер имен неспособен предоставить соответствие имени узла его IP адресу. Поэтому, даже если используется сервер имен, файл /etc/hosts должен быть защищен. Только администратор должен иметь доступ на запись в этот файл. Доступ для чтения разрешается всем.

Файл /etc/inetd.conf

Этот файл допускает и отключает услуги TCP/IP. Демон inetd запускает другие демоны TCP/IP, когда требуются специфические сервисы. Например, если пользователь использует команду telnet, чтобы обработать этот запрос демон inetd запускает демон telnetd. Доступные сервисы могут быть убраны из среды TCP/IP, путем удаления соответствующей станзы в этом файле. Этот файл обеспечивает первичный контрольный пункт управления сервисами TCP/IP, которые являются доступными на вашей системе.

Сервер имен

Если ваша система - сервер имен (DNS), вы должны защитить файлы данных сервера имен. Файл /etc/resolv.conf должен быть защищен на всех системах. Неправильное содержимое этого файла может направить запросы несанкционированному серверу имен. Также должны быть надежно защищены файлы /etc/named.boot, /etc/named.ca, /etc/named.local и /etc/named.data.

Команда netstat

Команда netstat обычно используется для получения информации о состоянии сети и диагностирования сетевых проблем. Но она же может использоваться для получения информации полезной при проверке сетевой защиты. Например, команда: netstat -p tcp обеспечивает информацию относительно протокола TCP/IP начиная с загрузки системы. Ищите сообщения типа неудачных попыток соединения. Эти сообщения могут означать, что кто-то пытается войти в ваш узел. Имеются другие опции для команды netstat, и некоторые могут быть полезны для целей защиты.

Trusted Computing Base

Многие путаются, когда идет речь о AIX Доверенной Вычислительной основе (Trusted Computing Base (TCB)). Ведь под TCB понимают следующее:

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

Сохранение целостности может быть наиболее важно для администратора системы; средства TCB могут помогать обнаруживать или предотвращать случайные и "не случайные" изменения системы.

Установить TCB можно только при установке ОС. Рекомендуется всегда установливать TCB, на каждой системе, даже если вы не имеете никаких непосредственных планов её использования. Почему? Об этом ниже…

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

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

Функции TCB позволяют запускать несанкционированные suid программы root, но они не могут проверять внутреннюю логику любой программы.

Описание TCB

Доверенная вычислительная основа (Trusted Computing Base (TCB)) - набор программ и файлов, которые обеспечивают проверку на "правильность" ("доверяемость") частям системы. В TCB включаются программы типа ядра AIX, программа входа в систему(ы), программа passwd, и т.д Аналогично, файл /etc/passwd, и другие ключевые файлы управления должны быть доверяемыми. Кроме того, должен иметься метод для пользователя, чтобы войти в систему и гарантировать ему, что он общается с соответствующей программой входа в систему, а не с подделкой. Соответственно пользователь должен быть уверен и в оболочке.

Любые средства обеспечения целостности системы считают, что базисной системе, поставленной продавцом можно доверять. То есть AIX TCB считает, что IBM поставил систему, в которой ключевые компоненты обеспечивают соответствующую защиту и целостность.

Вы можете добавлять любые программы или файлы к TCB (не все компоненты AIX находятся в TCB; только относительно маленький процент от всех программ и файлов).

Наиболее полезной функцией TCB, из точки зрения администратора, является процесс проверки, связанным с ней. Список атрибутов различных файлов (разрешения, владелец, контрольная сумма, связи, и т.д.) заносится в файл /etc/security/sysck. Командой tcbck можно проверить, что ключевые файлы на момент проверки всё еще имеют эти атрибуты (и, факультативно, исправляют их в соответствии с шаблоном, если некоторые из них изменены.

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

Администратор должен исследовать файл /etc/security/sysck.cfg (используя команды pg) чтобы лучше разобраться с атрибутами, которые контролируются. AIX определяет TCB-бит в inodes. Этот бит указывает, что файл является частью TCB и его единственной целью является указание на то, что данная программа может быть выполнена доверенной оболочкой.

Доверенная оболочка (Trusted Shell) также является частью TCB и она позволяет выполнять только те программы, которые являются частью TCB на основе информации занесенной в inode.

TCB-бит может быть установлен (пользователем root) используя команду chtcb.

Использование команды tcbck

Если AIX устанавливается согласно рекомендации с опцией TCB, то вы должны найти файл /etc/security/sysck.cfg, который соответствует установленной системе и является эталоном для TCB. Для проверки целостности системы используется команда

которая проверяет соответствие атрибутов файлов эталону.

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

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

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

Использование доверенного входа в систему и доверенной оболочки

Процесс входа в систему, для любой системы UNIX, может являться главным дефектом безопасности. Проблема проста: является ли "реальной" программа входа в систему или кто-то подменил её на программу моделирующую программу входа в систему? Пользователь, обладающий только скромными умениями программирования, может написать программу, которая очищает экран, показывает приглашение входа в систему, и ждет ввода имени и пароля пользователя. Если эта программа запущена на оставленном работающем терминале, другой ничего не подозревающий пользователь, может подумать, что терминал свободен и попытается зарегистрироваться в системе. Поддельная программа фиксирует userid и пароль и завершает сеанс. Завершение сеанса вызывает новую подсказку входа в систему (из "реальной" программы входа в систему). Пользователь думает, что он ошибся при вводе своего имени или пароля и вторично повторяет процедуру входа в систему. Опытные или немного параноидальные пользователи обычно сразу же в таких ситуациях меняют свой пароль. Это - классический тип нападения на UNIX, который может быть эффективным даже на современных системах UNIX.

ОС AIX обеспечивает защиту против таких нападений с помощью SAK и доверенного пути для входа в систему. Этот процесс не автоматический. Администратор должен запустить SAK-процесс для пользователей и для портов.

1. Если пользователь не зарегистрирован в системе гарантируется путь входа в систе-му. Если tpath определен для пользователя, то SAK соединит его с доверенной оболочкой (tsh), в ином случае для пользователя запускается обычная оболочка.

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

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

Чтобы использовать для портов SAK, вставляется строка методом прямого редактирования (с помощью SMIT не устанавливается) sak_enable=true в файле /etc/security/login.cfg. Этот параметр может быть установлен в заданной по умолчанию строфе (относится ко всем портам), или установлен в строфах для каждого порта.

SAK вызывается с терминала нажатием комбинации клавиш Ctrl-x Ctrl-r.

Если порт - основной графический терминал для запуска SAK, необходимо добавить две дополнительные строки в файл /etc/security/login.cfg:

Для допуска пользователей к доверенному пути и доверенной оболочке, устанавливается параметр tpath в соответствующей станзе файла /etc/security/user. Для индивидуальных пользователей это может быть установлено используя SMIT.

Параметр может принимать одно из следующих значений:

1. tpath=nosak. Это - значение по умолчанию и означает, что доверенный путь не доступен для этого пользователя. SAK игнорируется, если этот пользователь уже зарегистрирован в системе. SAK перед входом в систему запустит обычную оболочку пользователя.

2. tpath=on. Это допускает факультативное использование SAK и доверенного пути для этого пользователя. SAK после входа в систему запустит доверенную оболочку.

3. tpath=always. Это разрешает пользователю регистрироваться в системе только через доверенный путь (произведенный с SAK) и ограничивает пользователя только доверенной оболочкой. Если вы тщательно не оценили сначала эти ограничения, не рекомендуется использовать это значение.

4. tpath=notsh. Это значение, если введен SAK, в то время как пользователь регистрируется в системе, вынудит к непосредственному выходу из системы.

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

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

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

Отдельно, SAK используется для защиты от нападения "Троянский конь" при входе в систему. Пользователям сообщается о возможности доверенного входа в систему и объясняется, что для того, чтобы войти в систему они должны:

1. При приглашении входа в систему, нажать Ctrl-x Ctrl-r (SAK-последовательность). Должно появиться новое приглашение входа в систему (ниже первого приглашения). Это - сигнал, что SAK был эффективен. Если ниже не появляется новое приглашение входа в систему, то SAK не сработал, и безопасный путь не установлен.

3. Если появляется обычная подсказка оболочки, продолжать как обычно.

4. Если появляется подсказка доверенной оболочки tsh, введите команду sh. Инициализируется сеанс пользователя с обычной оболочкой.

Рекомендации для аудита

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

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

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

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

Ограничения аудита

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

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

3. На многих серверах используются такие программы, как, например, программы базы данных (например, DB2) или интерактивные мониторы диалоговой обработки запросов (типа CICS). Эти программы имеют собственные средства безопасности и аудита и не всегда хорошо взаимодействуют с контрольной подсистемой операционной системы.

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

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

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

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

2. Записывать много событий и объектов доступа для использования в "послефактическом" исследовании проблем. Такая процедура подразумевает накопление и управление значительными количествами данных и требует планирования и приложения усилий для управления этими данными.

Восстановление root userid

Если не доступен userid пользователя root, вы имеете серьезную проблему. Наиболее общим случаем такой проблемы является администратор, который забыл пароль root. Также бывает так, что новые администраторы системы, при экспериментировании с различными опциями защиты, могут делать систему настолько безопасной, что никто не может использовать её.

Для восстановления root userid необходимо сделать следующее:

1. Найти вашу установочную системную ленту (или CD-ROM).

2. Если это возможно, дать команду shutdown -F (только root может использовать эту команду).

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

5. Выбрать из отображаемого меню режим "System Maintenance".

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

9. Используя SMIT или другие команды восстановите вашу систему.

11. Выполнить дважды команду sync для обновления информации на диске.

14. Перезагрузить систему (не забудьте вынуть ленту). Не забудьте задать пароль пользователю root.

Пожалуйста обратите внимание, что этот метод "вторжения" в систему требует (1) физического доступа к RS/6000, и (2) "ленты начальной загрузки" (или CD-ROM), которая поставляется с программным обеспечением AIX.

Другие темы

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

Firewall

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

Наиболее общим подходом является создание "оболочки", которая прерывает программы, выполненные через inetd.

X Window

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

Терминология для X Window

Сервер - модуль с дисплеем; это - сервер дисплея. Клиент - система с вычислительной программой, которая посылает вывод (или читает ввод) сервера. Базисная защита начинается с сервера дисплея. Управляет этим то, какие системы клиента могут использовать сервер дисплея.

Имеются два метода для защиты сервера дисплея:

1. Может использоваться команда xhost, чтобы добавлять или удалить системы из списка разрешенных систем клиентов. Эта команда, в действительности, делает временный список (который не переживет перезагрузку).

2. Вы можете создавать файлы, под именами /etc/Xn.hosts, где n 0, 1, 2, ... (номер логического дисплея) содержащий списки систем клиентов, разрешенных, чтобы соединиться с этим сервером дисплея. Вы можете найти и управлять файлами /etc/X?.hosts на вашей системе.

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

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

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

1. Определите различные типы пользователей и данные, к которым они должны иметь доступ.

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

3. Организуйте доступ к данным в соответствии со структурой групп.

4. Установите SVTX для разделяемых директорий.

5. Помните, что UNIX и AIX, в частности, не имеет концепции владения приложениями.

Управление пользователями

Счета Пользователя

Управление счетами пользователя - наиболее стандартная функция администратора системы.

"Традиционная" система UNIX для добавления или удаления пользователя требует, чтобы администратор редактировал несколько файлов (типа /etc/passwd и /etc/group). Более поздние поколения UNIX обеспечивают команды (или сценарии оболочки), типа mkuser, для общих действий управления пользователями.

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

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

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

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

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

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

Обратите внимание: Эта глава игнорирует эффект использования NIS.

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

Процесс инициализации пользователя

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

ћ /etc/profile командный сценарий оболочки, который контролирует общесистемные переменные по умолчанию. Например, TERM, MAILMSG, MAIL.

ћ /etc/environment В этом файле определяется базовое окружение для всех процессов. Для примера: HOME, LANG, TZ, NLSPATH.

ћ $HOME/.profile Собственный профиль пользователя в его директории. Пользователь лично может указать свои собственные предпочтения отменяя команды и значения переменных заданных в файле /etc/profile.

Порядок входа в систему

Когда пользователь выходит из системы оболочка прекращает работу и процесс init создает новый процесс getty для данного порта.

Параметры Пользователя в SMIT

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

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

Введите userid (строка 1, User NAME) для нового пользователя. Userid должен быть уникален на данной системе. Идентификатор пользователя (строка 2) - UID. Процесс SMIT автоматически назначит следующий UID; без явной необходимости администратор не должен отменить предложенное значение этого поля. Оставьте значение этого поля пустым.

Административные поля (строки 3 и 6) описаны позже. Оставьте эти поля неизменяемыми (то есть "false" и пробел) для обычных пользователей.

Пользователь может поле входа в систему (строка 14) определяет, может ли этот пользователь входить в систему непосредственно (косвенный вход в систему частично управляется строками 7,8 и 15). Обычному пользователю нужно позволять регистрироваться в системе. Стандартные счета системы, типа bin, являются специальными случаями, которым не нужно разрешать никакого входа в систему. Другой специальный случай - пользователь root, который обсужден позже. Этот параметр устанавливает флажок в станзе файла /etc/security/user в отношении этого пользователя. Это не устанавливает звездочку в поле пароля в /etc/passwd, чтобы запретить вход в систему.

ГРУППЫ SU (строка 8), SU ПОЛЬЗОВАТЕЛЮ (строка 7), и ВХОД В СИСТЕМУ ДИСТАНЦИОННО (строка 15) средствами управления могут использоваться, чтобы ограничить доступ к этому счету. Показываются нормальные (и значение по умолчанию) значения. Эти значения по умолчанию разрешают доступ к счету несколькими способами.

SU ПОЛЬЗОВАТЕЛЮ определяет, может ли любой другой пользователь использовать этот счет, используя команду su. Только root может su к счету, если этот флажок установлен в false. Если SU ПОЛЬЗОВАТЕЛЮ установлен в true, поле ГРУППЫ SU обеспечивает некоторый контроль над тем, какие пользователи могут su к этому счету. Только членам групп пользователей, перечисленных в этом поле разрешено su к этому счету. Это поле не эффективно для root, так как root может su к счету независимо от ограничений группы. Значение по умолчанию all - ключевое слово, означающее все группы (знак восклицания, предшествующий группе служит символом отрицания, то есть членов именованной группы не разрешено su к этому userid.)

Поле ВХОДА В СИСТЕМУ ДИСТАНЦИОННО управляет доступом через rlogin и telnet средства TCP/IP. Если значение установлено в true (значение по умолчанию), любой может регистрировать под этим счетом, используются telnet, если он знает пароль счета. Этот параметр не управляет доступом через функцию ftp TCP/IP.

НАЧАЛЬНАЯ ПРОГРАММА (строка 10) - имя (с полным путем) программы, которой будет дано управление, когда этот пользователь зарегистрируется в системе. Это - обычно имя оболочки, типа /usr/ksh. Если это поле пусто (нормальный случай), начальное имя программы берется из файла /etc/security/mkuser.default.

В поле ДАТА ОКОНЧАНИЯ (строка 12) обычно ставят значение 0 (означающий никакую дату окончания). Формат даты показывается в меню. Типичным значением могло бы быть число "0330000099" (MMDDhhmmyy). Этот параметр полезен для временных счетов, типа счетов для посетителей или подрядчиков. Счет будет заблокирован после определенной даты.

Поле БЛОКИРОВКА СЧЕТА (строка 13) обычно установлено в false, и может использоваться как средство управления, чтобы отключить userid. (Это не будет вынуждать пользователя выйти из системы, если он в настоящее время зарегистрирован в ней.)

Вы можете ограничивать время регистрации пользователя определенными часами, используя ВРЕМЯ ВХОДА В СИСТЕМУ (строка 16). Имеются несколько форматов для этого параметра, и они объяснены в комментариях для файла /etc/security/user (см.Файл /etc/security/user). Это время относится только к допустимому времени регистрации в системе и не относится к допустимому времени работы в системе.

ДОПУСТИМЫЕ TTYs (строка 19) определяет терминалы, которые этот счет может использовать (эта строка не управляет псевдо-терминалами, какие используется telnet и другими удаленными соединениями). Полные имена пути терминалов должны быть заданы явно, например /dev/tty1. Символ "!" перед именем терминала означает, что терминал не может использоваться. Ключевое слово ALL означает, что могут использоваться все терминалы. Способность ограничивать конкретных пользователей конкретными терминалами может быть сильным инструментом защиты, но должна использоваться с осторожностью. Например, пользователь root мог бы быть ограничен локальным пультом, хотя это может стать проблемой в случае аппаратной проблемы.

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

Поле ОПОЗНАВАТЕЛЬНАЯ ГРАММАТИКА (строка 18) должен быть оставлен со значением по умолчанию "compat". Это поле будет использоваться с будущими расширениями для распределенных систем.

Различные средства управления паролем (строки 21 - 31) обсуждены позже. Предлагается, чтобы вы оставили эти линии неизменными. Не введите что-нибудь в поле РЕГИСТРАЦИИ ПАРОЛЯ (строка 32). Это поле введено для будущего использования с DCE или другими удаленными функциями регистрации.

Ограничения процесса (строки с 33 по 37) обеспечивают некоторую защиту против программ выходящих из-под контроля.

Максимальный размер ФАЙЛА (строка 33) оп-ределяет верхний ограничение для параметра ulimit. Ulimit - максимальный размер (в модулях 512 байтов) файла, созданного этим пользователем. Пользователь может изменять значение с командой ulimit, но не может превышать набор значений в поле, указанное администратором в SMIT. Минимальное значение, предлагаемое SMIT - 8192. Обратите внимание, что этот максимальный размер файла - для одного файла; это значение не ограничивает общее количество дискового пространства, использованного этим пользователем.

Параметр ВРЕМЯ ЦЕНТРАЛЬНОГО ПРОЦЕССОРА (строка 34) ограничивает максимальную продолжительность течения любой одиночной программы. Значение указывается в секундах. Когда процесс превышает это ограничение времени, он прерывается AIX. Пользователь видит сообщение об ошибке и новую подсказку оболочки.

UMASK (строка 38) - значение по умолчанию переменной umask для пользователя. Пользователь может изменить это значение во время одиночного сеанса командой umask.

Не измените строки 39-42 (КЛАССЫ АУДИТА, ДОВЕРЕННЫЙ ПУТЬ, ПЕРВИЧНЫЙ МЕТОД АУТЕНТИФИКАЦИИ, ВТОРИЧНАЯ АУТЕНТИФИКАЦИЯ) если вы не имеете специфических требований.

В результате определения нового пользователя (используя панель SMIT, показанную выше) будут внесены следующие добавления к следующим файлам:

1. Файл /etc/passwd будет содержать новую строку, определяющую пользователя.

2. Файл /etc/security/passwd будет содержать новую станзу для шифрованного пароля пользователя и нескольких флажков.

3. Файл /etc/security/user будет содержать новую станзу, содержащую некоторые из ограничений пользователя.

4. Файл /etc/group будет изменен, чтобы добавить нового пользователя в одну или большее количество групп.

5. Файл /etc/security/limits будет содержать новую станзу, содержащую некоторые из относящихся к окружению ограничений пользователя.

6. Файл /etc/security/.ids будет модифицирован, чтобы содержать следующий доступный UID.

7. Директория /home будет содержать новую директорию, которая является исходной директорией для нового пользователя.

Системные значения по умолчанию

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

Большинство параметров пользователя хранится в файле /etc/security/user. В нем имеется станза для каждого определяемого пользователя в системе и станза для значений по умолчанию. Как root, администратор может редактировать заданную по умолчанию станзу (используя vi или другой ваш любимый редактор) и изменить значения по умолчанию.

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

Из 42 строк меню, отображаемых SMIT при добавлении или изменении параметров пользователя, 30 строк хранятся в файле /etc/security/user.

Файл /etc/security/limits организован таким же образом, и значения по умолчанию для шести ограничений пользователя (максимальный размер файла и т.д) могут быть установлены в этом файле.

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

Файлы /etc/security/user и /etc/security/limits используются всякий раз, когда пользователь регистрируется в системе; на тех пользователей, которые в момент изменений зарегистрированы в системе изменения не будут воздействовать.

Теневые файлы

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

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

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

Решение было найдено: требуется чтобы (факультативно) переместить шифрованные пароли в другой файл. Этот "другой" файл называется теневым файлом.

Для AIX теневым файлом является файл /etc/security/passwd. Строка в файле /etc/passwd может иметь четыре значения в поле пароля (второе поле в строке):

1. Поле пароля имеет нулевое (пустое) значение. Нулевое (пустое) поле пароля означает, что не требуется пароля для этого userid.

2. Звездочка. Это означает, что userid отключен. (AIX обычно использует другое поле в /etc/security/user, чтобы отключить пользователя, но использует метод звездочки, когда пользователь уже определен.)

3. Символ восклицания. Это означает, что шифрованный пароль находится в теневом файле /etc/security/passwd. Это - стандартный вариант для AIX.

4. Шифрованный пароль (длина шифрованного пароля всегда 13 символов).

Некоторые счета могут помещать зашифрованные пароли в файл /etc/passwd, и другие счета могут иметь их зашифрованные пароли в теневом файле /etc/security/passwd. AIX будет работать правильно в обоих случаях, но настоятельно рекомендуется не размещать шифрованные пароли в файле /etc/passwd.

SMIT и команда passwd автоматически поместит символ восклицания в файл /etc/passwd и поместит зашифрованный пароль в файл /etc/security/passwd.

Имеются некоторые другие файлы в директории /etc/security. Они все связаны со средствами управления безопасности и иногда называются "файлами теневой защиты''.

Пароли

Когда новый пользователь добавляется с помощью SMIT, счет автоматически блокируется, помещая звездочку во втором поле (поле пароля) строки файла /etc/passwd для нового пользователя. Администратор (работающий как root) должен использовать SMIT или команду passwd и задать начальный пароль для пользователя.

Так как пароль был установлен административным пользователем (root), нового пользователя при первой попытке регистрации в системе попросят его изменить (флажок ADMCHG во входе пользователя в файле /etc/security/passwd указывает, что требуется изменение пароля). Установка начального пароля дает возможность новому пользователю с новым счетом зарегистрироваться в системе.

Команда passwd - обычная команда UNIX для изменения паролей. Команда может использоваться любым пользователем, чтобы изменить его собственный пароль, или использоваться root для изменения пароль любого пользователя.

Не имеется никакого специфического преимущества для использования SMIT для изменения паролей; команда passwd делает то же самое дело.

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

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

Например, новая группа студенческих userid могла бы быть создана в удобное для администратора время, но не быть допущенной для регистрации в систему, пока не начнется учебный период. В этом случае, использование команды passwd может быть более удобно, чем установка паролей через SMIT.

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

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

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

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

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

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

1. Не используйте ваше имя пользователя или любой его вариант.

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

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

5. Не используйте пароли короче чем пять или шесть символов.

6. Не используйте ругательные или непристойные слова; они - среди первых слов, которые пробуют при вскрытии паролей.

7. Используйте пароли, которые вы можете помнить. Не записывайте ваш пароль.

8. Используйте по возможности пароли, которые состоят из букв и чисел.

9. Используйте пароли, которые вы можете быстро набрать на клавиатуре.

10. Два слова, с числом между ними, обычно являются "хорошим" паролем.

11. Слово (длиной по крайней мере в шесть символов), с цифрой, вставленной в слово, является превосходным паролем (но не формируйте цифру, заменяя букву "l" на "1" или букву "o" на цифру "0'').

12. Слово с цифрой внутри - лучший пароль чем слово с первой или последней цифрой.

13. Удобопроизносимый пароль проще для запоминания.

14. AIX проверяет только первые восемь символов пароля. Однако слово может быть более длинное чем восемь символов.

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

Индивидуальные установки по управлению могут быть установлены, используя меню SMIT. Средства управления:

Значения по умолчанию не обеспечивают никаких средства управления качеством паролей. Это сделано намеренно, поскольку это соответствует ожидаемой характеристике "стандартного" UNIX.

Maxage/minage определяет максимальный/минимальный возраст пароля (в неделях). Значение по умолчанию - 0 на обеих строках, что указывает, что пароль не имеет никакого минимального или максимального возраста. Рекомендуется, чтобы вы не использовали параметр minage. Это может вызвать конфликтные ситуации.

Рассмотрите возможность использования меньших значений параметра maxage для привилегированных пользователей типа root и членов группы system. Ранее существовал спор о том необходимо ли пользователю время после окончания времени действия пароля на обдумывание нового пароля или нет. Если пользователя жестко потребуют срочно поменять его пароль, он может выбрать новый пароль тривиальным или недостаточно "стойким". Так как пользователь регистрируется в системе для своей цели, он не мог серьезно ранее подумать о своем новом пароле.

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

Параметры maxrepeat, mindiff, minlen, minalpha, и minother обеспечивают базисные средства управления качеством паролей. Они управляют максимальном числом повторения символов, минимальным числом символов, указывают на то, что новый пароль должен отличиться от предыдущего, минимальной длиной, минимальным числом буквенных символов, и минимальным числом небуквенных символов, которые должны появиться в пароле.

AIX имеет опцию, чтобы помнить старые пароли (используются файлы /etc/security/pwdhist.dir и /etc/security/pwdhist.pag). Параметр histexpire определяет число недель, которые должны протечь до того, как пароль может вторично использоваться.

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

AIX обеспечивает еще две функции управления качеством пароля. Может быть определен файл недопустимых паролей (с параметром dictionlist=) и может быть определен список программ пользователя (с параметром pwdchecks=) чтобы выполнить любую настроенную проверку пароля.

Файлом недопустимых паролей мог бы быть файл /usr/share/dict/words (если он присутствует в вашей системе) или любой другой файл со списком слов. Эти параметры могут быть установлены для индивидуальных пользователей через SMIT или установлены как значения по умолчанию в файле /etc/security/user.

Файлы, связанные со счетами пользователей

Файлы, которые связаны с управлением пользователями, перечислены ниже с краткими комментариями. Почти все файлы, непосредственно связанные с управлением пользователями и группами находятся в директории /etc/security.

1. Файл /etc/security/.ids Не редактируйте этот файл. Он содержит последовательность чисел для использования командой mkuser так, чтобы новая группа или пользователь всегда получила уникальный uid/gid. Файл модифицируется автоматически различными командами, вызываемыми (внутренне) SMIT.

Где: 6 = следующий административный номер uid
221 = следующий номер uid
12 = следующий административный номер gid
206 = следующий номер gid

2. Файл /etc/group содержит базисные области определения группы.

3. Файл /etc/security/group содержит дополнительную информацию группы, типа флажков admin и adms.

4. Файл /etc/security/login.cfg содержит станзы для ряда средств управления для всей системы. Не имеется никаких станз конкретных пользователей или групп. Эти средства управления вообще связаны использованием порта и терминалов. Комментарии в файле описывают его функции и форматы очень ясно. Станзы включают:

5. Файл /etc/passwd содержит базисные области определения пользователя.

6. Файл /etc/security/passwd содержит зашифрованные пароли, штамп времени последней модификации, и флажок, указывающего на то, модифицировался ли пароль администратором (если да, то пользователю при следующей попытке зарегистрироваться в системе будет выдан запрос на изменение его пароля).

7. Файлы /etc/passwd.dir и /etc/passwd.pag созданы командой mkpasswd и содержат маленькие структуры базы данных, чтобы ускорить доступ к userid файлам управления. Не редактируйте эти файлы.

8. Файл /etc/security/user содержит большинство параметров управления пользователями.

9. Файл /etc/security/environ может содержать относящиеся к окружению атрибуты для пользователей.

10. Файл /etc/security/limits содержит параметры ресурсов.

11. Файл /usr/lib/security/mkuser.default содержит несколько значений по умолчанию, используемые при создании нового пользователя. Вы можете редактировать этот файл непосредственно. Он содержит заданную по умолчанию группу, заданную по умолчанию начальную программу (оболочку), и заданное по умолчанию имя исходной директории для нового пользователя.

12. Файл /etc/security/failedlogin содержит записи о каждом сбое входа в систему. Файл может отображаться командой who:

Этот пример переназначит вывод в файл /tmp/check. Не редактируйте этот файл. Однако, периодически вы могли бы удалять его. Этот файл не так полезен, как могло бы показаться, потому что в нем не записываются недопустимые userid (любой userid, который не присутствует в вашем файле /etc/passwd). Недопустимые userid регистрируются как UNKNOWN.

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

14. Файл /etc/security/.profile - прототип для файла $HOME/.profile для новых пользователей. Вы можете редактировать этот файл когда требуется. Некоторые из этих файлов имеют вторую, более старую, копию в директории /etc/security, которая создается автоматически при изменении этих файлов. "Старая" копия имеет символ "o" как первый символ имени файла. Например, существуют файлы /etc/security/limits и /etc/security/olimits.

Управление заданиями

Поиск системных процессов

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

Остановка процессов

ћ Для остановки foreground процессов используйте комбинацию клавиш прерывания (обычно Ctrl+C).
ћ Для остановки background процессов используйте команду kill.
ћ Для остановки заданий crontab закомментируйте соответствующую строку задания в crontab файле.
ћ Для остановки демона cron закомментируйте строку запуска этого демона в файле /etc/inittab используя команду chitab.

Командный файл (сценарий) skulker

AIX поставляется с файлом /usr/sbin/skulker, обычно известным как skulker. Это - сценарий оболочки, который удаляет ряд нежелательных файлов.

Вы можете выполнять skulker из командной строки (если Вы - root), или Вы можете выполнять его автоматически (используя cron). Эта команда автоматически не выполняется cron в базовой системе AIX.

Имеется строка в файле /var/spool/cron/crontabs/root для включения этой команды в сценарий cron, но, по умолчанию, эта строка закомментирована.

ћ Записанные в буферный файл выходные файлы находящиеся там более чем четыре дня;
ћ Файлы, находящиеся в очереди почты больше чем два дня;
ћ Обычные файлы в /tmp, которые находятся там больше чем один день;
ћ Обычные файлы в /var/tmp, которые находятся там больше чем один день;
ћ Файлы *.bak, .*.bak, a.out, core, proof, galley, ...*, ed.hup (с некоторыми ограничениями), которые находятся там больше чем один день;
ћ Директории .putdir, которые находятся там больше чем один день.

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

Контролирование использования функций cron и at

Системным процессом, который позволяет запускать работы, которые должны быть выполнены в определенное время, является демон cron. Этот демон стартует при старте системы согласно записи в файле /etc/inittab.

ћ для выполнения регулярных команд по расписанию - при наступлении событий команды crontab;
ћ для выполнения команд, которые должны быть выполнены один раз - при наступлении событий команды at;
ћ для выполнения команд, которые должны выполнится в тот момент, когда система менее всего загружена - при наступлении событий команды batch.

Хронологические события конфигурируются в файле /var/adm/cron/queuedefs. Вы должны читать документацию AIX для команды crontab перед использованием функций cron. В то время как возможно редактирование некоторые cron файлов непосредственно, команда crontab обеспечивает нормальный метод добавления, изменения, и удаления cron работ.

Система AIX cron (через команду crontab) формирует отдельные файлы для работ от различных пользователей, и в ней удалены многие дефекты root, которые были хорошо известны на более старых UNIX системах.

Работы пользователя (user) определены в crontab файле пользователя /var/spool/cron/crontabs/user. Формат crontab файла пользователя:

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

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

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

Два отвергающих файла "deny" существуют, но пусты.

Два позволяющих файла "allow", не существуют в распределенной системе. Если они созданы, то отвергающие файлы игнорируются.

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

Особенно для больших серверов, рекомендуется создание файлов /var/adm/cron/cron.allow и /var/adm/cron/at.allow, содержащие имена root и имена тех пользователей, которым разрешается запускать планируемые промышленные работы.

Команда cronadm полезна для проверки текущего состояния cron:

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

Подключение ПК к серверу AIX

AIX Connections

Отдельно заказываемый программный продукт AIX Connections обеспечивает решение проблемы подключения ПК с популярными операционными системами, включая OS/2, Windows, Windows 95, Windows NT Workstation и MacOS к серверу с AIX.

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

Краткое описание AIX Connections

AIX Connections Version 1.1 для AIX, основана на технологии TotalNet Advanced Server компании Syntax и позволяет использовать систему с AIX как файл- и принт-сервер в сетях Ethernet или Token-Ring. Этот пакет поддерживает клиентов с почти со всеми основными операционными системами:

ћ DOS 5.0 и выше;
ћ IBM OS/2 2.1 и IBM LAN Server 3.0 и выше;
ћ MacOS 6.03 или выше;
ћ Novell Netware 3.1;
ћ Microsoft LANMAN 2.0 и выше;
ћ Windows для Workgroups, Windows 95/98 и Windows NT 3.51 или выше.

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

ћ Поддержка графических рабочих станций.
ћ Файловый сервер и сервер печати.
ћ Серверы данных Network File System (NFS)/Distributed File System (DFS).
ћ Поддержка асинхронного Point-to-Point Protocol (PPP).
ћ Поддержка DHCP.
ћ Поддержка программ клиент/сервер, таких как OLTP и прикладных программ баз данных.
ћ Серверы имен.
ћ Маршрутизация.
ћ Поддержка HACMP (кластеризации).
ћ Поддержка Windows Internet Naming Service (WINS).

ћ Совместимость с функциями файлового сервера и сервера печати - IBM Version LAN Server 4, Microsoft LAN Manager, Novell Netware и Apple.
ћ Поддержка всех функций AIX для работы с файлами, в том числе и функций защиты.
ћ Поддержка SMIT - обеспечено интегрированное администрирование системы.
ћ Поддержка кластеров HACMP позволяет обеспечить файловых сервис и сервис печати высокой степенью доступности.
ћ Встроенные функции маршрутизации позволяют пользователям присоединиться к большинству внешних сетей без необходимости изменения программного обеспечения со стороны клиента или покупки дополнительного программного обеспечения.
ћ Исключена необходимость в использовании отдельного сервера с Windows NT для поддержки WINS.

Все файлы и прикладные программы, помещаемые в RS/6000 пользователями и администраторами AIX Connections сохраняются как файлы AIX. Это означает, что эти файлы будут обрабатываться как часть файловой системы AIX. Преимущества Journal File System и Logical Volume Manager, типа зеркального отражения дисков, больших размеров файлов и расширяемых логических томов, теперь относятся и к этим файлам.

Весь диапазон средств системного управления AIX может теперь использоваться, чтобы обеспечить надежность и доступность для пользователей AIX Connections. Сервер может также сохранять эти файлы на других серверах UNIX через Network File System или Distributed File System.

Доступ к файлам и защита

Так как все файлы сохранены в файловой системе AIX, доступ к ним управляется AIX. Каждому подсоединенному пользователю ПК будут предоставлены разрешения, основанные на userid AIX этого пользователя. В то же время сетевым клиентам не требуются регистрация в AIX, чтобы обращаться к ресурсам, доступным AIX Connections. Доступ для этих пользователей управляется AIX Connections. Процедура входа в любой сервер AIX Connections сравнима с процедурой входа на эмулируемом сервере. Вход в систему пользователя может иметь силу для любого или всех серверов. Утилита tnpasswd используется клиентами для изменения пароля AIX Connections.

Сервера AIX Connections

AIX Connections может выполнять роль трех различных серверов для различных клиентов:

Установка и конфигурация различных серверов выполняется через SMIT. Пакеты, включенные в AIX CONNECTIONS перечислены ниже:

На одном и том же сервере AIX могут быть активными один или большее количество серверов. AIX Connections включает в себя несколько файлов, которые разделяются среди всех трех серверов. Цель этих файлов состоит в том чтобы координировать услуги между LSserver, NWserver и MACserver.

Установка AIX Connections выполняется в директорию /usr/tn. В этой же директории устанавливаются разделяемые между всеми тремя серверами файлы. Разделяемые файлы выполняют следующие функции:

ћ Проверка базы данных контуров;
ћ Проверка блокировки файла;
ћ Регистрация выполняемых действий;
ћ Административные программы.

База данных контуров

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

Файл блокировки

Файл блокировки, lock.smb, используется для контроля над параллельным доступом к файлам на сервере. Когда пользователь открывает файл, прикладная программа определяет, какой параллельный доступ нужно разрешить другим клиентам.

Административные программы

Для управления базой данных контуров используется набор административных инструментальных средств. tnwho показывает список текущих клиентов. tninfo производит поиск информации о текущих клиентах. tnck проверяет и дополнительно корректирует базу данных контуров. Эти функции могут также быть выполнены через SMIT.

Регистрация выполняемых действий

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

ћ Имя пользователя AIX;
ћ Имя машины клиента;
ћ Сетевой адрес клиента;
ћ Сетевое имя сервера;
ћ Общее количество прочитанных килобайтов;
ћ Общее количество записанных килобайтов;
ћ Общее количество напечатанных килобайтов;
ћ Общее количество обслуженных запросов;
ћ Общее время соединения;
ћ Тип сервера - LSserver, NWserver или MACserver.

Novell Network Services (NNS) 4.1 on AIX

Включенный в bonus-pack, поставляемый со стандартной ОС AIX, программный продукт Novell Network Services 4.1 (NNS) on AIX привносит мощные сетевые услуги Novell NetWare 4 в систему RS/6000. NNS on AIX обеспечивает полнофункциональную совместимую реализацию Novell Directory Services (NDS) на неограниченное количество пользователей, распределенные сервисы файл и принт-сервера Novell (в bonus-pack на 2-х пользователей), сетевую защиту и административные сервисы для всего семейства систем RS/6000.

Это дает возможность RS/6000 действовать как сервер Internet и как сервер прикладных программ пользователя ПК, использующих операционные системы DOS 5.0, OS/2 2.1, Windows 3.11, Windows 95 и Windows NT 3.51 или их более поздние версии. NNS on AIX обеспечивает одно, глобальное представление всех сетевых ресурсов с помощью NDS.

ћ Обеспечение мощной, масштабируемой и надежной службы каталогов Novell Directory Services (NDS) для клиентов PC.
ћ Расширение NDS поддержкой сервиса каталога LDAP для Internet/intranet.
ћ Обеспечение сетевой защиты.
ћ Обеспечение распределенных файл и принт сервисов Novell для ПК клиентов.
ћ Поддержка способности RS/6000 к сетевому взаимодействию с системами с сетевой операционной системой Netware и NDS серверами.
ћ Доступно для AIX Версий 4.2. и 4.3

Кластеризация

High Availability Cluster Multi-Processing (HACMP)

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

Архитектура IBM HACMP дает возможность соединить в кластер восемь одно- или многопроцессорных систем RS/6000 (до 16 компьютеров IBM RS/6000 SP). Программный пакет HACMP включает в себя графические инструменты администратора, которые помогают установить, сконфигурировать и управлять вашими кластерами высокопроизводительным способом.

High Availability Geographic Cluster (HAGEO)

Программный пакет High Availability Geographic Cluster (HAGEO) помогает построить ещё более отказоустойчивую систему за счёт географического удаления компонентов кластерной системы.

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

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

Требования HAGEO к программному обеспечению

Каждая система в кластере HAGEO требует наличия HACMP версии 4.1.1, установленный в обеих узлах и AIX 4.1.4 for Servers. Для организации режима защиты "параллельный доступ" необходимо наличие AIX CLVM и Oracle Parallel Edition.

Коммуникационные линии

Могут быть использованы линии типа "точка-точка" или сеть на основе коммутации пакетов, поддерживаемые набором AIX TCP/IP. Рекомендуется использовать как минимум две линии, расположенных физически отдельно друг на друга, чтобы не превратить связь в ещё одну точку отказа. Производительность HAGEO зависит от скорости линии связи и типов сетевых услуг.

Распределенная среда обработки данных DCE

Distributed Computing Environment (DCE) - технология распределенной обработки данных, предложенная фондом открытого программного обеспечения (OSF). Многие считают ее единственным реально существующим стандартом для связующего программного обеспечения.

Среда DCE, разработанная в 1990 г., представляет собой набор сетевых служб, предназначенный для выполнения прикладных процессов, рассредоточенных по группе абонентских систем гетерогенной сети. Наряду с файловой службой, реализованной в виде распределенной файловой системы (DFS), DCE специфицирует следующий базовый набор распределенных служб и технологий:

Достоинства DCE

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

Интегрированные службы безопасности, справочников и единого времени означают, что соответствующим спецификации DCE прикладным программам не надо самим создавать эти службы или средства работы с несколькими нестандартными (фирменными) системами различных производителей (скажем, службой справочника NetWare (NDS) или службой Banyan StreetTalk).

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

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

Основное преимущество стандартизованного в DCE механизма RPC перед нестандартизованными разработками различных производителей - его интеграция с другими службами.

Недостатки DCE

Механизм RPC является единственным механизмом межпроцессного взаимодействия. И это плохо. Такой механизм требует установления соединения между клиентом и сервером.

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

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

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

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

Ахиллесова пята DCE - сам механизм RPC. Эта устаревшая технология просто не поспевает за новейшими технологиями межпроцессного взаимодействия. Поэтому совершенно естественно, что при разработках многих продуктов связующего ПО применялся совсем иной подход.

Механизм RPC не стал универсальным средством для создания распределенных прикладных систем.

В DCE нет функциональных возможностей, связанных с организацией очередей, и столь обычных в ориентированном на передачу сообщений связующем ПО. Несмотря на отсутствие стандартов на рынке такого ПО, существует по крайней мере один продукт с организацией очередей сообщений - Encina Recoverable Queuing System фирмы Transarc, совместимый со средой DCE.

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

Может изменить ситуацию компания Microsoft, если она решит более полно поддерживать стандарты DCE в своих продуктах. Но она этого не делает. И Windows NT, и Windows 95 включают в себя реализацию механизма RPC в соответствии со спецификацией DCE, однако другие службы DCE этими системами не поддерживаются.

Network OLE, новая технология Microsoft, разработанная в соответствии со стратегией Common Object Model для распределенных приложений, также поддерживает согласуемый с DCE механизм RPC, но совершенно неясно, будут ли здесь реализованы базовые службы безопасности DCE.

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

Так же как интерфейс ODBC позволил стандартизировать доступ к базам данных SQL разных производителей, разработка Microsoft могла бы сильно облегчить труд создателей приложений, позволив им использовать готовые службы, а не создавать свои собственные.

Основы DCE

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

Логическая структура среды CDE представлена на рисунке:

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

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

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

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

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

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

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

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

Как создать среду DCE

Планирование

Прежде чем определять размещение DCE, следует проанализировать сетевую среду и прикладные программы, чтобы ответить на вопросы: сколько приложений предполагается выполнить? Как они будут общаться между собой? Сколько пользователей окажется в каждом узле? Намерены ли пользователи одновременно работать с несколькими приложениями? Как часто пользователям придется обращаться к службе защиты? Когда они будут регистрироваться в ячейке? Как часто пользователям нужно будет вызывать приложения?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизация ячейки

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

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

Например, если в среде возникает 11 запросов на 10 серверов, попробуйте установить один, два и даже больше дополнительных серверов, пока в реальных условиях не будет достигнута приемлемая производительность.

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

Исследование, проведенное Центром информационных технологий Мичиганского университета, показало, что хотя среднее время регистрации составляет всего 2 с даже при работе с 50200 бюджетами, иногда оно достигает трех минут и более.

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

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

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

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

Часть процессов DCE работает в каждом узле, например программа-демон dced, которая в версии 1.1 связывает клиента с сервером и обслуживает каталоги. При этом в отдельном узле может выполняться только одна копия процесса. Хорошо что сбой процесса влечет за собой отказ не всей ячейки, а лишь того узла, на котором он работал.

Для восстановления нужно с помощью сетевого или системного ПО определить состояние этого процесса и запустить его снова.

Размещение серверов защиты

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

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

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

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

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

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

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

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

При повышенных требованиях к конфиденциальности серверы защиты DCE рекомендуется размещать в охраняемых помещениях информационного центра.

Размещение серверов каталогов

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

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

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

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

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

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

Синхронизация часов

О значении службы времени и соответствующих рекомендациях OSF можно прочитать в руководстве "OSF DCE Administration Guide, Core Components", которое входит в комплект поставки DCE. В нем подробно описано, какие службы времени нужны для ячеек при той или иной конфигурации сети. Поскольку небольшая ошибка в системных часах может нарушить совместимость защищенных приложений DCE, лучше всего обратиться в службу точного времени.

Серверы лицензий

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

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

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

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

Подготовка персонала

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

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

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

Обзор лицензирования

Общая концепция

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

Для лицензирования в AIX применяется программный продукт iFOR/LS (Information For Operation and Retrieval License System). Это программное обеспечение управления лицензиями использует стандартную промышленную распределенную технологию Network Computing System (NCS) для вызова удаленных процедур в модели клиент/сервер.

Цена на LPP для AIX и их поставка осуществляется используя две модели лицензирования: лицензия на пользователя лицензия на сервер/неограниченное количество пользователей

Используя зашифрованные ключи iFOR/LS осуществляет мониторинг типов и количества лицензий используемых в системе.

iFOR/LS

Пакет iFOR/LS является расширением системы NetLS и его команды на 100% совместимы с системой команд NetLS. Компания Hewlett-Packard приобрела права на NetLS вместе с приобретением компании Apollo Computers. В 1987 году компания Gradient Technologies согласно соглашению с HP перенесла этот продукт на AIX под новой тор-говой маркой iFOR/LS.

ћ NCS 1.5.1.
ћ ARK
ћ ADK iFOR/LS требует применения NCS 1.5.1.

NCS является отдельно устанавливаемым пакетом bos.net.ncs.obj, содержащим комплект инструментов для распределенных вычислений.

iFOR/LS поставляется разделенным на две части: ориентированной на поддержку разработчиков программ и ориентированной на поддержку администраторов.

Разработчикам программ понадобится Application Developer's Kit (ADK). Для системных администраторов предназначен пакет Administrator Runtime Kit (ARK), предназначенный для установки и управления сервером лицензирования, вместе с инструментами создания отчётов.

Типы лицензий

Программный продукт iFOR/LS использует несколько различных типов лицензий:

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

Concurrent use Конкурентное использование лицензионного программного обеспечения предоставляет возможность лицензиям на использование программ "плавать" по сети и при запросе любого пользователя, если есть свободная лицензия, ему будет разрешено запустить программу.

Use once Этот механизм использует счетчик количества запусков лицензионного программного продукта. И при установке счетчика в 0 программу запустить больше нельзя. Используется для целей ознакомления пользователей с программой (try and buy).

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

Сервер лицензирования

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

Каждый сервер лицензирования действует независимо друг от друга.

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

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

Политика лицензирования

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

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

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

Wait Перейти в режим ожидания. Когда лицензия освободиться другим пользователем, требуемая программа запустится.

List Показать список систем использующих лицензии в настоящее время.

Queue Показывает вашу позицию в очереди ожидания доступности лицензии.

Различные прикладные программы используют различное время удержания лицензий (время повторного опроса сервера лицензий на предмет наличия свободных лицензий). Длинные интервалы удержания минимизируют сетевой трафик. Короткие периоды позволяют быстрее предоставлять свободные лицензии нуждающимся в них пользователям. Можно изменять одноминутными интервалами. Рекомендуется: 5-10 минут. Для программы входа в систему AIX BOS login это время составляет 15 минут.

Установка сервера "плавающих" лицензий

Установка сервера "плавающих" лицензий состоит из трех процедур:

3. Запуск серверных демонов (фоновые процессы) llbd dlbd netlsd

В директории /usr/lib/netls/conf содержится командный файл netls_config, который автоматизирует процедуру установки.

Common Desktop Environment (CDE)

Что такое CDE?

Common Desktop Environment (CDE) desktop - интерактивный графический интерфейс пользователя, совместно разработанный компаниями IBM, HP, Sun, и Novell для открытых систем. Desktop - богатый и интуитивный интерфейс пользователя, основанный на X11 release 5 и OSF/Motif 1.2. Этот интерфейс разработан для применения в информационных системах масштаба предприятия и на различных платформах и обращен к широкому диапазону пользователей от новичка до эксперта.

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

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

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

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

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

Рабочий стол также поддерживает существующие прикладные программы X Window, OSF/MOTIF и OPENLOOK.

Почему CDE?

Преимущества CDE

Широкое применение в индустрии

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

Обширная система интерактивной справки

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

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

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

Множественные рабочие области

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

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

Основан на стандартах

CDE основан на промышленных стандартах X-OPEN, X11 release 5, OSF/MOTIF 1.2 и Spec 1170.

Интуитивность

CDE основан на непротиворечивом интерфейсе пользователя для представления и поведения настольных компонентов.

Краткое описание рабочего стола AIX CDE

Управление окнами / лицевая панель

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

Администратор окон основан на стандартах OSF/MOTIF 1.2 и включает в себя расширения для поддержки множественных рабочих областей (дополнительные области экранного пространства).

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

Администратор файлов

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

Администратор файлов позволяет создавать, перемещать, копировать и удалять объекты, а также изменять их свойства. Большинство этих действий может быть выполнено или через прямое манипулирование (методом drag and drop) или через меню.

Администратор стиля

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

Интерактивная справка CDE

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

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

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

Инструменты разработок программ

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

Dtscript - графический интерфейс создания диалогов и сценариев, основанный на технологии Windowing Korn Shell.

Application Builder - дополнительный простой инструмент разработки, который поддерживает новые widgets CDE.

Оба из этих инструмента позволяют пользователю создавать графический интерфейс, используя технику drag and drop.

Интернационализация

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

Приложения

Планирование безопасности

ОС AIX - полностью "открытая система". Эта ОС сама по себе не имеет никакой эффективной защиты, но она обеспечивает администратора инструментальными средствами для создания безопасной системы.

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

При начальной установке

3. Установите следующие ограничения пароля в заданной по умолчанию станзе файла /etc/security/user:

4. Определите значение блокировки по времени. Поместите его в файл /etc/profile, если значение блокировки по времени должно быть единым для всех пользователей:

Значение блокировки по времени выражено в секундах. Например, значение 1800 означает, что оболочка должна блокировка по времени, если не производится никакого действия в течение 30 минут. Установите, и TMOUT и TIMEOUT, если ваши пользователи могут использовать любую оболочку.

6. Переназначьте вывод skulker и подобных ему отчетов в один файл, например, /tmp/dailyreport - это сделает проще ежедневный контроль действий системы и её состояния.

7. Команда securetcpip отключает некоторые сетевые сервисные демоны. Если не требуется применение команды rlogin и связанных с нею, то используйте эту команду.

8. В директории /var/adm/cron, используйте файлы cron.allow, cron.deny, at.allow, и at.deny для управления доступом к функциям cron.

9. Измените сообщение при входе в систему, которое идентифицирует вашу ОС.

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

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

13. Рассмотрите необходимость отключения всех удаленных и dial-in терминалов в конце рабочего дня. Разрешите им доступ утром.

14. Тщательно проверьте все в заданных по умолчанию параметрах станзы файла /etc/security/user. Установите соответствующие значения по умолчанию прежде созда-ния пользователей. Это позволит не определять большиноство параметров для вновь создаваемых пользователей.

15. Рассмотрите необходимость отключения возможности входа в систему под именем root на любой системе, на которой более чем один человек знает пароль root. Такое отключение вынудит пользователей входить в систему под их собственным userid и затем выполнять команду su root. Средства аудита и/или записи в файле/var/adm/sulog будут контролировать этих пользователей.

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

Продолжение действий

1. Делайте копии. Храните архивы. Убедитесь, что ещё кто-то кроме вас знает, как восстановить файлы с самой свежей копии.

2. Остерегайтесь "свободно распространяемого программного обеспечения", "ПО общего пользования" или файлов, полученных с анонимного ftp-сервера. Никогда не запускайте общий файл при работе в системе с полномочиями root, если вы не исследовали этот файл и полностью не доверяете ему.

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

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

5. Не позволите пользователям совместно использовать userid (совместно используя пароль) или UID (устанавливая несколько счетов с тем же самым UID).

6. При оказании помощи пользователю, не делайте su root из его сеанса. Если вы делаете это, вы используете его среду (с его PATH) и это открывает большое количество дефектов безопасности. Если вы всё же делаете su root из сеанса пользователя, то используйте полные имена пути для всех команд, которые вы используете при выполнении их как root.

7. Остерегайтесь пользователей, которые изменяют IFS (входной разделитель полей) в своих профилях. Не позволяйте им изменять файл /etc/profile. Хорошо осведомленный пользователь может проигрывать много умных приемов терминала с IFS и вызывать бесконечные проблемы.

8. Не поместите текущую директорию в PATH для root. Для отмены заданного по умолчанию PATH в заданном по умолчанию профиле (в файле /etc/profile) вы должны создать файл a.profile для root. a.profile находится в исходном каталоге пользователя.

9. Значение umask должно быть установлено для пользователей. Значение umask по умолчанию - 022, хотя значение 027 (отключает любой доступ "остальным") может быть лучше. Специфические значения umask могут быть помещены в индивидуальные файлы настроек пользователей $HOME/.profile (не забудьте, что пользователь может изменять его собственное значение umask в любое время).

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

11. Используйте tcbck ежедневно или по крайней мере еженедельно.

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

13. Проверяйте файл /tmp/dailyreport ежедневно, если он существует.

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

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

Вход в систему с двумя паролями

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

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

SMIT Security and Users Users Change/Show Characteristics of a User *User NAME [alex] ... PRIMARY Authentication Method [SYSTEM,SYSTEM;serg]

Когда alex регистрируется в системе, в этом примере, его запросят ввести его пароль. Если он отвечает правильно, система запросит затем ввести пароль пользователя serg (конечно, alex мог бы знать оба пароля, но тогда теряется смысл входа в систему с двумя паролями).

Вы должны установить ПЕРВИЧНЫЙ Опознавательный Метод точно как показано выше. Параметр SYSTEM определяет, что должна использоваться обычная программа установления подлинности пароля. По умолчанию, она проверяет пароль регистрирующегося пользователя.

Второй параметр SYSTEM определяет вторую проверку. В этом случае имеется операнд ;serg, и проверяется пароль счета, определенного в этом операнде.

Файлы безопасности

Нижеследующие ASCII файлы содержат атрибуты пользователей и контроля доступа:

ћ /etc/passwd допустимые пользователи
ћ /etc/group допустимые группы
ћ /etc/security директория не доступная обычным пользователям
ћ /etc/security/passwd пароли пользователей
ћ /etc/security/user атрибуты пользователей, ограничения на пароли
ћ /etc/security/limits ограничения пользователей
ћ /etc/security/environ установки окружения пользователей
ћ /etc/security/login.cfg установки входа в систему
ћ /etc/security/group атрибуты групп

Файл /etc/passwd

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

Поля этого файла, разделяемые символом ":", следующие:

ћ имя пользователя - до 8-ми алфавитно-цифровых символов.
ћ пароль - в старых системах UNIX здесь содержался зашифрованный пароль. В AIX это поле содержит символ "!" как ссылка на файл /etc/security/passwd. Другими общими значениями этого поля может быть символ "*", который означает, что идентификатор пользователя неверный и это поле может быть пустым, что означает, что пароля нет.
ћ идентификатор пользователя - номер идентификатора пользователя.
ћ индетификатор группы - номер идентификатора группы вышеуказанного пользователя.
ћ полное имя - любой описательный текст для пользователя.
ћ директория -директория пользователя при входе в систему и инициирующее значение для переменной $HOME.
ћ login программа - оболочка пользователя при входе в систему и инициирующее значение для переменной $SHELL.

Файл /etc/security/passwd

Доступ к этому файлу есть только у пользователя root. Изменяется этот файл с помощью команд login, passwd, pwdadm и pwdck, исполняющихся с полномочиями root.

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

ћ password зашифрованный пароль или символ "*" для заблокированных счетов или пустой пароль.
ћ lastupdate дата и время последнего обновления пароля в секундах начиная с 1 января 1970 года.
ћ flags ADMCHG - пароль может быть изменен только администратором или пользователем root. ADMIN - пароль пользователя может быть изменен только root. NOCHECK - ограничения пароля не имеют силы для этого пользователя.

Файл /etc/security/user

admin Определяется административный статус пользователя. Возможные значения true и false.
login Определяется то, может ли пользователь входить в систему. Возможные значения true и false.
su Определяется то, могут ли другие пользователи переключатся на этот счет командой su или нет. Возможные значения true и false.
daemon Определяется то, может ли пользователь исполнять программы пользуясь демоном cron или системным контроллером ресурсов (SRC). Возможные значения true и false.
rlogin Определяется то, можно ли получить доступ к счету пользователя используя удаленный вход в систему. Используется командами telnet и rlogin. Возможные значения true и false.
sugroups Определяются группы которые могут переключатся на этот счет пользователя. Если вы вставите символ "!" перед именем группы, ее пользователи наоборот будет исключены из возможности переключатся на этот счет. Возможные значения: список допустимых групп, разделенных запятыми, значение ALL или символ "*".
admgroups Список групп, которыми управляет пользователь. Значение: список доступных групп, разделенных запятыми.
ttys Определяются терминалы, с которых пользователю возможен доступ. Используя символ "!" перед именем терминала вы запретите использовать его для доступа пользователю. Возможные значения: список полных путей к устройствам, разделенный запятыми, значение ALL или символ "*".
auth1 Определяется первичный метод аутентификации для пользователя, который по умолчанию устанавливается для программы пароля. Этот метод аутентификации будут использовать программы login, telnet, rlogin и su. Для удвоенного входа в систему значением этого поля будет SYSTEM;NAME1,SYSTEM;NAME2.
auth2 Определяет для пользователя вторичный метод аутентификации.
tpath Определяет для пользователя характеристики доверенного пути. Возможные значения: nosak, notsh, always или on.
umask Определяет для пользователя значение переменной umask по умолчанию. Рекомендуется установить в 027.
expires Определяется время действительности счета пользователя. Возможные значения: дата допуска в формате MMDDHHMMYY или 0, если счет не имеет определенного времени допустимости. При значении 0101000070 счет отменен.
SYSTEM Определяются требования к аутентификации версии 4. Это поле используется для определения множественных или альтернативных методов аутентификации которые пользователь должен успешно пройти перед получением доступа к системе. Возможные значения:

logintimes Определяет время, когда пользователь может входить в систему. Значением является список времен, разделенный запятыми, в следующем формате: [!] [MMdd[-MMdd]]:hhmm-hhmm или [!] [MMdd[-MMdd][:hhmm-hhmm] или [!] [w[-w]]:hhmm-hhmm или [!] w[-w][:hhmm-hhmm] где, MM - номер месяца (00=январь, 11=декабрь), dd - день месяца, hh - часы дня (00-23), mm - минуты часа и w - день недели (0=воскресенье, 6=суббота).
pwdwarntime Количество дней перед сменой пароля когда появляется предупреждение пользователю с информацией о необходимости скорой смены пароля. Возможные значения: положительное целое число или 0 для выключения этой функции.
account_disable Устанавливается в true, если счет по умолчанию заблокирован и не может быть ис-пользован для входа в систему. В обратном случае устанавливается в false.
logintries Количество попыток неправильных входов в систему, после чего пользователь не имеет возможности войти в систему. Возможные значения: положительное целое число или 0 для выключения этой функции.
histexpire Определяет период в неделях в течении которого пользователь не может применить снова свой старый пароль. Возможные значения: целое число от 0 до 260. Рекомендованное значение - 26 (около 6-ти месяцев).
histsize Определяется количество старых паролей, которые не могут быть повторены. Возможные значения: целые числа от 0 до 50.
minage Определяется минимальное количество недель между сменами паролей. По умолчанию=0. Диапазон от 0 до 52. Рекомендуется оставить значение по умолчанию.
maxage Работает совместно с переменной pwdwarntime (см.выше). Определяет максимальное количество недель когда пароль является действующим. По умолчанию=0, что означает неограниченное время использования. Допустимый диапазон значений от 0 до 52.
maxexpired Определяется максимальное количество недель после истечения периода, указанного в переменной maxage, в течении которого пользователю дается возможность изменить свой пароль. По умолчанию=-1, что эквивалентно неограниченному сроку. Допустимый диапазон от -1 до 52.
minalpha Определяется минимальное количество алфавитных символов в пароле. По умолчанию=0. Диапазон - от 0 до 8.
minother Определяется минимальное количество неалфавитных символов в пароле. По умолчанию=0. Диапазон - от 0 до 8. Сумма значений параметров minalpha и minother должна не превышать 8. Если эта сумма больше 8 то значение параметра minother вычисляется как разница между 8 и значением параметра minalpha.
minlen Определяется минимальная длина пароля. По умолчанию=0. Диапазон - от 0 до 8. Минимальная длина пароля берется из значения этого параметра или из суммы значений параметров minalpha+minother, в зависимости от того, какая величина больше.
mindiff Определяется минимальное количество символов в новом пароле, которые не должны совпадать с символами в старом при его смене. По умолчанию=0. Возможные значения - от 0 до 8.
maxrepeats Определяется максимальное количество повторений одного символа в пароле. По умолчанию=8, что эквивалентно неограниченному количеству повторений. Возможные значения - от 0 до 8.
dictionlist Определяет словарь паролей используемый для проверки на "стойкость" нового пароля. Возможные значения: разделенный запятыми список абсолютных путей к файлам словарей. Файл словаря должен содержать по одному слову на строку, причем каждое слово не должно иметь пробелов ни впереди ни сзади. Слова могут содержать только 7-ми битные символы ASCII. Все словари и директории должны быть защищены от за-писи от всех пользователей, кроме root. По умолчанию не используется никакого файла словарей.
pwdchecks Определяется внешний ограничивающий метод используемый для проверки качества пароля. Возможные значения: разделенный запятыми список абсолютных путей методов проверки и/или путь к методу относительно директории /usr/lib. По умолчанию внешний ограничивающий метод проверки пароля не используется.

Файлы /etc/group и /etc/security/group

ћ группа до 8 алфавитно-цифровых символов.
ћ пароль не используется AIX 4-й версии и должен содержать "!" ћ групповой идентификатор
ћ члены разделенный запятыми список пользователей, членов группы.

Файл /etc/security/group построен в формате станз для каждой группы. Возможные параметры:
ћ admin true или false, в зависимости от того административная группа или нет.
ћ adms разделенный запятыми список пользователей, которые являются администраторами группы. Если параметр admin=true, то этот параметр игнорируется, так как только root может управлять административной группой.

Файл /etc/security/login.cfg

default:
:
herald="\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThis is the console. Restricted use only.\nlogin:
logintimes=
logindisable=0
logininterval=0
loginreenable=0
logindelay=0

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

logintimes Определяет период в течение которого пользователь может использовать порт для входа в систему.

logindisable Количество неуспешных попыток входа в систему после которых порт будет заблокирован. Используется совместно с параметром logininterval (см.ниже).

logininterval Число секунд в течении которых порт будет заблокирован при достижении количества неуспешных попыток входа в систему согласно значения, установленного в параметре logindisable.

loginreenable Количество минут после прошествия которых заблокированный порт автоматически разблокируется.

logindelay Время задержки в секундах между попытками неудачного входа в систему. Задержка увеличивается с каждой попыткой на эту величину. То есть если значение у этого параметра - 2, то первая задерка будет 2 секунды, вторая - 4, третья - 6 секунд и так далее.

Об авторе

Быков Алексей Геннадиевич - менеджер информационной системы ЗАО "Комтек", г.Кривой Рог, Украина.

В 1990 году после окончания 2-го курса на кафедре "Физика полупроводниковых материалов и приборов" МИСиС работал в научно-исследовательском и проектном институте "Механобрчермет", где прошел путь от техника технического отдела до начальника рекламного отдела. Затем руководил рекламной фирмой "Софт-Пресс", после чего перешел в 1992 году работать в ПКФ "Комтек" (в дальнейшем преобразованное в закрытое акционерное общество), где и работает в настоящее время.

Выполняет задачи по развитию и управлению корпоративной информационной системой ЗАО "Комтек", построенной на серверах с операционными системами Microsoft Windows NT Server, IBM AIX, персональных компьютерах и сетевом оборудовании IBM, Hewlett-Packard, Cisco, 3Com. Участвует в техническом руководстве информационной системой Криворожского процессингового центра ЗАО "Комтек" по обслуживанию системы безналичных расчетов с использованием смарт-карт (система построена на использовании AIX, Oracle, системы SmartCity, маршрутизаторов и серверов доступа фирмы Cisco).

ИМЯ ПРИЛОЖЕНИЯ	КОМАНДА
Управление пользователями/группами	xuserm
Управление дисковыми подсистемами	xlvm
Управление печатью	xprintm
Управление устройствами	xdevicem
Управление установкой программ	xinstallm
Управление обслуживанием и обновлением	xmaintm

	По определению	Иначе
access	write	both (используется для модемов или выходных программ требующих возможности чтения)
header	never	always, group
trailer	never	always, group
feed	never	Integer
aling	FALSE	TRUE

Состояние	Описание
DEV_BUSY	Принтер занят обслуживанием других запросов на печать. Это состояние возникает в том случае, если с одним принтером связано несколько очередей и иная очередь использует принтер в настоящий момент. Такое состояние возникает также в тот момент, когда приложение, отличное от qdaemon использует данный принтер. Ваши действия: подождите, пока принтер не освободится или kill (убейте) процесс или работу, которые используют порт принтера.
DEV_WAIT	Очередь ожидает принтер. Такое состояние возникает в такие моменты, когда принтер находится в состоянии offline (нет бумаги, замята бумага, проблема с кабелем и т.п.)
DOWN	Ожидание.Это состояние возникает в ситуации, когда истекает время ожидания попыток драйвера принтера установить связь с ним. Оператор может ввести очередь в это состояние на время системного обслуживания.
OPR_WAIT	Очередь ожидает изменения производимые оператором. Это состояние устанавливается тогда, когда оператор заменяет бумагу (размер, ориентацию) и т.п. Обычно программным путем.
QUEUED	Работа в очереди и ожидает.
READY	Очередь готова для получения заданий на печать.
RUNNING	Файл печатается.
UNKNOWN	Проблема с очередью. Это состояние возникает в такие моменты, когда пользователь создает очередь для файла устройства, которое используется другой очередью и ее состояние DEV_WAIT.

Наименование	Количество
Группа томов	до 255 на систему
Физический том	до 32 на группу томов
Физический раздел	до 1016 на физический том, каждый размером до 256МБ
Логический том	до 256 на группу томов
Логический раздел	до 32512 на логический том

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

Name	Nodename	Mount Pt	VFS	Size	Options	Auto
/dev/hd4	-	/	jfs	8192	-	yes
/dev/hd1	-	/home	jfs	90112	-	yes
/dev/hd2	-	/usr	jfs	507904	-	yes
/dev/hd9var	-	/var	jfs	8192	-	yes
/dev/hd3	-	/tmp	jfs	16384	-	yes
/dev/cd0	-	/infocd	cdrfs		ro	yes
/dev/lv00	-	/home/john	jfs	8192	rw	yes

node	mounted	mounted over	vfs	date	options
	/dev/hd4	/	jfs	Jul 11 20:14	rw,log=/dev/hd8
	/dev/hd2	/usr	jfs	Jul 11 20:15	rw,log=/dev/hd8
	/dev/hd9var	/var	jfs	Jul 11 20:15	rw,log=/dev/hd8
	/dev/hd3	/tmp	jfs	Jul 11 20:15	rw,log=/dev/hd8
	/dev/hd1	/home	jfs	Jul 11 20:16	rw,log=/dev/hd8
	/dev/lv00	/home/john	jfs	Jul 11 20:16	rw,log=/dev/hd8

Page Space	Physical Volume	Volume Group	Size	%Used	Active	Auto	Type
hd6	hdisk0	rootvg	64MB	44%	yes	yes	lv
paging00	hdisk1	uservg	64MB	9%	yes	yes	lv
paging01	hdisk1	uservg	16MB	86%	yes	yes	lv

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

Тип аппаратуры	Аппаратный адрес	IP адрес	Результат
0	0	<IP адрес>	<IP адрес> должен быть удален из диапазона
0	<строка>	<IP адрес>	Клиенту, который идентифицирован <строкой> должен быть присвоен <IP адрес>
<type>	<address>	<IP адрес>	Конкретному устройству <type> с адресом <address> должен быть присвоен адрес IP <IP адрес>
<type>	<address>	none	Не давать IP адрес для конкретной аппаратуры с конкретным адресом
0	<строка>	none	Не отвечать для конкретного клиента идентифицированного <строкой>
<type>	<address>	any	Предоставить любой свободный адрес IP для конкретной аппаратуры с конкретным аппаратным адресом. Используется в комбинации с выставленным параметром supportunlistedclients=no.
0	<строка>	any	Предоставить любой свободный адрес IP для клиента идентифицированного <строкой>. Используется в комбинации с выставленным параметромsupportunlistedclients=no.

Бит доступа	Файл	Директория
r	пользователь может читать содержимое файла	пользователь может просматривать содержимое директории
w	пользователь может изменять содержимое файла	пользователь может создавать файлы и перемещать файлы в директорию
x	пользователь может использовать имя файла как команду	пользователь может входить (cd) в директорию и помещать её в PATH
SUID	программа выполняется с эффективным UID владельца	-
SGID	программа выполняется с эффективным GID владельца	файлы, созданные в директории наследуют принадлежность к той же группе, что и директория
SVTX	-	для удаления файла в директории пользователь должен быть владельцем файла или директории

процесс getty	стартуется процессом initпараметры портов в ODM
login	Файл /etc/security/login.cfg
Пользователь вводит свое имя входа
Пользователь вводит свой пароль
Проверка имени и пароля пользователя	Файлы /etc/password и/etc/security/password	В случае ошибки делается запись в файл /etc/security/failedlogin
Установка окружения	Файлы /etc/security/environ,/etc/security/limits, /etc/security/user
Сообщение дня	Файл /etc/motd	Если в директории пользователя существует файл $HOME/.hushlogin то сообщение дня ему не показывается
shell	Запуск оболочки
Установка окружения пользователя	Файлы /etc/environment, /etc/profile и $HOME/.profile

Служба	Выполняемые функции
Имена	База Данных (БД) имен пользователей и средств, предназначенных для доступа пользователей к сетевым службам.
Удаленный доступ	Технология, обеспечивающая взаимодействие двух прикладных программ, расположенных в различных абонентских системах.
Защита данных	Программное Обеспечение (ПО) разрешения на доступ к ресурсам системы или сети, включающее схему Kerberos на базе RPC
Многопоточность	ONT>OCT Программы, обеспечивающие одновременное выполнение нескольких задач. Позволяет одновременно выполнять множество вызовов RPC в асинхронном режиме