uot;.

6. Выбрать "Access a Root Volume Group".

7. Выбрать "Continue".

8. Выбрать "Access the Volume Group and start a shell".

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

9. Используя SMIT или другие команды восстановите вашу систему.

11. Выполнить дважды команду sync для обновления информации на диске.

12. Выполнить команду shutdown -F.

13. Вернуть ключ в позицию NORMAL.

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.

Порядок входа в систему

процесс 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

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

Параметры Пользователя в SMIT

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

smit
Security and Users
Users
ADD a User

1 * User NAME [alex]
2 User ID [ ]
3 ADMINISTRATIVE User? false
4 Primary GROUP [staff]
5 Group SET [staff]
6 ADMINISTRATIVE GROUPS []
7 Another user can SU TO USER true
8 SU GROUPS [ALL]
9 HOME Directory [/usr/guest]
10 Initial PROGRAM []
11 User INFORMATION []
12 EXPIRATION date (MMDDhhmmyy) 0
13 Is this user ACCOUNT LOCKED? false
14 User can LOGIN? true
15 User can LOGIN REMOTELY? true
16 Allowed LOGIN TIMES
17 Number of FAILED LOGINS before [0] user account is locked
18 Login AUTHENTICATION GRAMMAR [compat]
19 Valid TTYs [ALL]
20 Days WARN USER before pw expires [0]
21 Password CHECK METHODS []
22 Password DICTIONARY FILES []
23 Number of PASSWORDS before reuse [0]
24 WEEKS before password reuse [0]
25 Weeks between pw expire & lockout[-1]
26 Password MAX. AGE [0]
27 Password MIN. AGE [0]
28 Password MIN. ALPHA characters [0]
29 Password MIN. OTHER characters [0]
30 Password MAX. REPEATED chars [0]
31 Password MIN. DIFFERENT chars [0]
32 Password REGISTRY []
33 MAX FILE Size [2097151]
34 MAX CPU Time [-1]
35 MAX DATA Segment [262144]
36 MAX STACK Size [65536]
37 MAX CORE File Size [2048]
38 File creation UMASK [22]
39 AUDIT classes []
40 Trusted path? nosak
41 PRIMARY Authentication Method [SYSTEM]
42 SECONDARY Authentication [NONE]

Номера строк (цифры с 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 на разных системах.

3. Не используйте имена людей.

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

5. Не используйте пароли короче чем пять или шесть символов.

6. Не используйте ругательные или непристойные слова; они - среди первых слов, которые пробуют при вскрытии паролей.

7. Используйте пароли, которые вы можете помнить. Не записывайте ваш пароль.

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

9. Используйте пароли, которые вы можете быстро набрать на клавиатуре.

10. Два слова, с числом между ними, обычно являются "хорошим" паролем.

11. Слово (длиной по крайней мере в шесть символов), с цифрой, вставленной в слово, является превосходным паролем (но не формируйте цифру, заменяя букву "l" на "1" или букву "o" на цифру "0'').

12. Слово с цифрой внутри - лучший пароль чем слово с первой или последней цифрой.

13. Удобопроизносимый пароль проще для запоминания.

14. AIX проверяет только первые восемь символов пароля. Однако слово может быть более длинное чем восемь символов.

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

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

            recommended default
minage      0            0 (weeks. Use 0)
maxage      12           0 (maximum age in weeks)
maxexpired  4            0 (weeks after expire)
minalpha    1            0 (alpha characters)
minother    1            0 (non-alpha characters)
minlen      6            0 (minimum length)
mindiff     3            0 (different from last pw)
maxrepeats  3            8 (repeated characters)
histexpire  26           0 (prohibit reuse, weeks)
histsize    8            0 (number of old passwords)
pwdwarntime 14           0 (warning time, days)

Значения по умолчанию не обеспечивают никаких средства управления качеством паролей. Это сделано намеренно, поскольку это соответствует ожидаемой характеристике "стандартного" 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 221 12 206

Где: 6 = следующий административный номер uid
221 = следующий номер uid
12 = следующий административный номер gid
206 = следующий номер gid

2. Файл /etc/group содержит базисные области определения группы.

3. Файл /etc/security/group содержит дополнительную информацию группы, типа флажков admin и adms.

4. Файл /etc/security/login.cfg содержит станзы для ряда средств управления для всей системы. Не имеется никаких станз конкретных пользователей или групп. Эти средства управления вообще связаны использованием порта и терминалов. Комментарии в файле описывают его функции и форматы очень ясно. Станзы включают:

а) группу параметров, связанных недопустимыми входами в систему. Эти параметры могут задерживать или запрещать (на определенный период или неопределенно) дополнительные попытки входа в систему после неудачного входа. Эти параметры могут обеспечивать ценную защиту для системы при нападении с попыткой взломать пароли. Если вы имеете dial-in порты или выставлены большой группе потенциальных "злоумышленников" вы должны отредактировать и использовать эти параметры.
б) sak_enabled - управление доступностью безопасной функции внимания для порта.
в) аuth_method (не определенный в заданном по умолчанию файле, отправленном с AIX) - определяет различные или дополнительные опознавательные методы.
г) параметры геральда (начального экранного сообщения перед регистрацией пользователя) находятся в этом файле. Администратор может отредактировать и перепроектировать геральд. Убедитесь, что ваш геральд содержит достаточно символов начала новой строки для очистки экрана.
д) usw - этот параметр используется только командой chsh и содержит список допус-тимых оболочек. Определяйте имена оболочек с полным путем.
е) maxlogins - этот параметр устанавливает максимальное число терминалов, с которых можно регистрироваться в одно время (этот параметр должен быть изменен командой chlicense, используется в соответствии с вашей лицензией на использование AIX).
ж) logintimeout - время за которое вход в систему должен завершиться.

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:

who -a /etc/security/failedlogin >> /tmp/check

Этот пример переназначит вывод в файл /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.

# ps -ef

USER PID  PPID C STIME TTY TIME CMD
root 1    0    0 02 Jan    -    1:30 /etc/init
root 1360 1    0 02 jan    -    0:00 /usr/sbin/srcmstr
root 3329 1    0 02 Jan    -    0:00 /usr/lib/errdaemon
root 2563 1360 0 02 Jan    -    0:00 /usr/lpp/info/bin/infod
root 4317 1    0 02 Jan    -    0:00 /usr/sbin/cron
root 7904 1360 0 02 Jan    -    0:00 /usr/sbin/qdaemon
root 8460 1360 0 02 Jan    -    0:00 /usr/sbin/writesrv

Остановка процессов

? Для остановки 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, но, по умолчанию, эта строка закомментирована.

Следующие файлы удаляются skulker:

? Записанные в буферный файл выходные файлы находящиеся там более чем четыре дня;
? Файлы, находящиеся в очереди почты больше чем два дня;
? Обычные файлы в /tmp, которые находятся там больше чем один день;
? Обычные файлы в /var/tmp, которые находятся там больше чем один день;
? Файлы *.bak, .*.bak, a.out, core, proof, galley, ...*, ed.hup (с некоторыми ограничениями), которые находятся там больше чем один день;
? Директории .putdir, которые находятся там больше чем один день.

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

Контролирование использования функций cron и at

Системным процессом, который позволяет запускать работы, которые должны быть выполнены в определенное время, является демон cron. Этот демон стартует при старте системы согласно записи в файле /etc/inittab.

Демон cron выполняет работу:

? для выполнения регулярных команд по расписанию - при наступлении событий команды 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 или при работах.

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

/var/adm/cron/cron.allow
/var/adm/cron/cron.deny
/var/adm/cron/at.allow
/var/adm/cron/at.deny

Два отвергающих файла "deny" существуют, но пусты.

Два позволяющих файла "allow", не существуют в распределенной системе. Если они созданы, то отвергающие файлы игнорируются.

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

Особенно для больших серверов, рекомендуется создание файлов /var/adm/cron/cron.allow и /var/adm/cron/at.allow, содержащие имена root и имена тех пользователей, которым разрешается запускать планируемые промышленные работы.

Команда cronadm полезна для проверки текущего состояния cron:

cronadm cron -l (list all cron files)
cronadm cron -l joe (list joe's cron files)
cronadm cron -v (list job submission status)
cronadm at -l (list existing at jobs)
cronadm at -l joe (list joe's at jobs)
cronadm at -v (list submission status)

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

К содержанию Вперед Назад

Подключение ПК к серверу 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 обеспечивает естественную интеграцию в этот каталог и структуру защиты.

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

LSserver
NWserver
MACserver

Установка и конфигурация различных серверов выполняется через SMIT. Пакеты, включенные в AIX CONNECTIONS перечислены ниже:

connect.client AIX Connections
connect.info.en_US AIX Connections
connect.msg.en_US AIX Connections
connect.protocols Protocol stacks
connect.server.com Common Server Files
connect.server.lsserve LS_Server
connect.server.macserve MAC_Server
connect.server.nwserve NW_Server
netbios.api Netbios
netbios.rte Netbios

На одном и том же сервере 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.

Основные свойства NNS on AIX:

? Обеспечение мощной, масштабируемой и надежной службы каталогов 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

К содержанию Вперед Назад

Распределенная среда обработки данных DCE

Distributed Computing Environment (DCE) - технология распределенной обработки данных, предложенная фондом открытого программного обеспечения (OSF). Многие считают ее единственным реально существующим стандартом для связующего программного обеспечения.

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

Служба	Выполняемые функции
Имена	База Данных (БД) имен пользователей и средств, предназначенных для доступа пользователей к сетевым службам.
Удаленный доступ	Технология, обеспечивающая взаимодействие двух прикладных программ, расположенных в различных абонентских системах.
Защита данных	Программное Обеспечение (ПО) разрешения на доступ к ресурсам системы или сети, включающее схему Kerberos на базе RPC
Многопоточность	ONT>OCT Программы, обеспечивающие одновременное выполнение нескольких задач. Позволяет одновременно выполнять множество вызовов RPC в асинхронном режиме

Достоинства 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.

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

Quit Выход.

List Показать список систем использующих лицензии в настоящее время.

Queue Показывает вашу позицию в очереди ожидания доступности лицензии.

Различные прикладные программы используют различное время удержания лицензий (время повторного опроса сервера лицензий на предмет наличия свободных лицензий). Длинные интервалы удержания минимизируют сетевой трафик. Короткие периоды позволяют быстрее предоставлять свободные лицензии нуждающимся в них пользователям. Можно изменять одноминутными интервалами. Рекомендуется: 5-10 минут. Для программы входа в систему AIX BOS login это время составляет 15 минут.

Установка сервера "плавающих" лицензий

Установка сервера "плавающих" лицензий состоит из трех процедур:

1. Установка программного обеспечения iFOR/LS

2. Конфигурирование NCS и iFOR/LS

3. Запуск серверных демонов (фоновые процессы) llbd dlbd netlsd

В директории /usr/lib/netls/conf содержится командный файл netls_config, который автоматизирует процедуру установки.

К содержанию Вперед Назад

Common Desktop Environment (CDE)

К содержанию Вперед Назад

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

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

1. ОС AIX;

2. Сетевая среда;

3. Среда NFS (и NIS, если используется).

При начальной установке

1. Установите TCB.

2. Установите пароль для root.

3. Установите следующие ограничения пароля в заданной по умолчанию станзе файла /etc/security/user:

pw_restrictions:
maxage = 12 (force change after 12 weeks)
maxrepeat = 3 (max three repeated characters)
minalpha = 1 (at least 1 alpha character)
mindiff = 3 (at least 3 different from last time)
minother = 1 (at least 1 nonalpha character)
maxexpired = 4 (allow logon 4 weeks after expired)
histexpire = 26 (prohibit reuse for 26 weeks)
histsize = 8 (prohibit reusing last 8 passwords)
pwdwarntime = 14 (start warning 14 days before expire)

4. Определите значение блокировки по времени. Поместите его в файл /etc/profile, если значение блокировки по времени должно быть единым для всех пользователей:

TMOUT=1800 (for Korn shell)
TIMEOUT=1800 (for Borne shell)
export TIMEOUT TMOUT

Значение блокировки по времени выражено в секундах. Например, значение 1800 означает, что оболочка должна блокировка по времени, если не производится никакого действия в течение 30 минут. Установите, и TMOUT и TIMEOUT, если ваши пользователи могут использовать любую оболочку.

5. Модифицируйте подсказку оболочки.

6. Переназначьте вывод skulker и подобных ему отчетов в один файл, например, /tmp/dailyreport - это сделает проще ежедневный контроль действий системы и е? состояния.

7. Команда securetcpip отключает некоторые сетевые сервисные демоны. Если не требуется применение команды rlogin и связанных с нею, то используйте эту команду.

8. В директории /var/adm/cron, используйте файлы cron.allow, cron.deny, at.allow, и at.deny для управления доступом к функциям cron.

9. Измените сообщение при входе в систему, которое идентифицирует вашу ОС.

10. Узнайте, как изменить сообщение дня.

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

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

13. Рассмотрите необходимость отключения всех удаленных и dial-in терминалов в конце рабочего дня. Разрешите им доступ утром.

14. Тщательно проверьте все в заданных по умолчанию параметрах станзы файла /etc/security/user. Установите соответствующие значения по умолчанию прежде созда-ния пользователей. Это позволит не определять большиноство параметров для вновь создаваемых пользователей.

15. Рассмотрите необходимость отключения возможности входа в систему под именем root на любой системе, на которой более чем один человек знает пароль root. Такое отключение вынудит пользователей входить в систему под их собственным userid и затем выполнять команду su root. Средства аудита и/или записи в файле/var/adm/sulog будут контролировать этих пользователей.

16. Отредактируйте файл mkuser.default.

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

Продолжение действий

1. Делайте копии. Храните архивы. Убедитесь, что ещ? кто-то кроме вас знает, как восстановить файлы с самой свежей копии.

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

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

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

4. При добавлении нового пользователя:

4.1. Убедитесь, что пользователь понимает, как задать приемлемый с точки зрения безопасности пароль, и как изменить его начальный пароль.
4.2. Объясните вашу стратегию относительно автоматических терминалов и операции блокировки по времени.
4.3. Дайте новому пользователю письменную копию стратегии безопасности вашей организации.
4.4. Попросите нового пользователя войти в систему. ОС попросит нового пользователя изменить пароль. Убедитесь, что он изменяет пароль.
4.5. Убедитесь, что пользователь знает где хранить его файлы (например, в директории /u/userid) - и где не хранить их (например в директории /tmp).
4.6. Проинструктируйте его по поводу опасности раскрытия (или дачи "взаймы") его пароля любому другому человеку.

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.)

Вход в систему с двумя паролями

Один общий метод у