Войти
 
 
   
 
  
Новости Notes.ру Библиотека Биржа труда Вопрос - ответ Форум Регистрация Поиск О проекте
Разделы
О Notes
Советы
Шаблоны и примеры
Литература
Презентации
 
Всё о задаче AdminP. Часть вторая   Во второй части мы завершаем рассмотрение AdminP. В ней рассмотрены запросы междоменного администрирования и способы управления функциями AdminP с помощью настроек документа сервера, команд консоли сервера, файла Notes.ini и интервалов очистки базы данных. В этой статье предполагается, что вы опытный администратор Domino и прочитали первую часть
О Notes Читать статью
 
Всё о задаче AdminP. Proxy-действия в R5 и Domino 6   Приложение к статье об административном процессе
О Notes Читать статью
 
Всё о задаче AdminP. Часть первая   Перевод классической статьи 2003-его года о задаче административного процесса (AdminP). Очень полезна для понимания работы механизма этой задачи. В первой части статьи описаны компоненты задачи AdminP, как они работают, и как их использование помогает сделать работу администратора Domino проще. Задача AdminP (сакращённо от Administration Process, Административный процесс) работает с базой административных запросов (Administration Requests, admin4.nsf)
О Notes Читать статью
 


О Notes

Главная   Библиотека   О Notes

Всё о задаче AdminP. Часть первая

Тимоти Спид (Timothy Speed) и Пол Реймонд (Paul Raymond)

Об авторах

Тимоти Спид (Timothy Speed), Infrastructure and Security Architect, IBM, Software Group

Тим работает в направлении безопасности Internet и почтовых систем с 1992 года. Тогда он принимал участие в поддержке инфраструктуры серверов Domino во время Олимпийских Мгр в Нагано, позже обслуживал систему на Lotus Notes на Сиднейской Олимпиаде. Он имеет сертификаты MCSE©, VCA (VeriSign Certified Administrator), CISSP, Lotus Domino CLP Principal Administrator и Lotus Domino CLP Principal Developer. Также Тим является соавтором шести книг

  • The Internet Security Guidebook,ISBN: 0122374711, February, 2001
  • The Personal Internet Security Guidebook,ISBN: 0126565619
  • Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization,ISBN:0121604527
  • Internet Security: A Jumpstart for Systems Administrators and IT Managers, ISBN 1555582982
  • SSL Vpn: Understanding, Evaluating And Planning Secure, Web-based Remote Access ISBN: 1904811078
  • Upgrading to Lotus Notes and Domino 7, ISBN:1904811639

Пол Реймонд (Paul Raymond), Development Relations Manager, Lotus

Пол принимал участие в программе разработки бета-версии Notes/Domino 6.0 и продолжил руководить разработкой бета-версии Notes/Domino 6.5. Пол пришёл в команду Lotus в 1992 году и работал над различными проектами внутри неё

Всё о задаче AdminP. Часть первая

В первой части статьи описаны компоненты задачи AdminP, как они работают, и как их использование помогает сделать работу администратора Domino проще. Задача AdminP (сакращённо от Administration Process, Административный процесс) работает с базой административных запросов (Administration Requests, admin4.nsf)

Понедельник, 10 часов утра. Планёрка в IT-отделе. Новый начальник открывает совещание и спрашивает каждого из присутствующих о его деятельности на прошедшей неделе. Наконец, очередь доходит до Вас. "На прошедшей неделе мы переименовали 1000 пользователей, выпустили 800 web-сертификатов, создали 200 реплик и перенесли 650 пользователей для работы на новом сервере. Мы сделали это с одним администратором и одним оператором". Начальник смотрит на Вас с явным недоверием и переспрашивает: "Вы выполнили всё это всего с двумя сотрудниками?" Вы киваете: "На самом деле, бОльшую часть работы выполнил оператор". Вконец озадаченный начальник спрашивает: "Что же такое сверхъестественное вы использовали, чтобы провернуть гору работы" - Улыбаясь, Вы отвечаете одним словом: "AdminP"

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

  • почтовыми файлами (перемещение и удаление пользовательских почтовых баз, делегирование работы с календарями - без наличия доступа Управляющего базой данных, - и включение агента Out of Office без наличия доступа Разработчика)
  • репликами (создание, перемещение и удаление реплик)
  • системными именами пользователей (переименование пользователей и групп, удаление серверов, управление сертификатами, перемещение пользователей с одного уровня иерархии на другой и автоматическое обновление информации для восстановления учётных записей)

В этой статье, первой из двух, описаны все компоненты задачи AdminP. Мы расскажем, как работает каждый компонент, и каким образом вы можете использовать его функции для того, чтобы сделать вашу работу как можно более простой (и произвести впечатление на босса). В этой статье предполагается, что Вы - опытный администратор Domino, знакомый с терминологией Notes и Domino

Составные части AdminP

В этой статье мы рассматриваем AdminP как набор компонентов, а не как цельный элемент. Эти компоненты включают:

  • серверную задачу Adminp
  • административного клиента (Domino Afministrator или Web Administrator)
  • каталог Domino (Domino Directory, names.nsf)
  • базу Certification Log (certlog.nsf)
  • базу административных запросов (Administration Requests, admin4.nsf)
  • административный сервер (назначаемый каждой базе в домене)

В следующих разделах кратко описаны эти компоненты

Серверная задача AdminP

Серверная задача AdminP выполняется на всех серверах Domino. Эта задача загружается при запуске сервера Domino и управляется переменной notes.ini ServerTasks. Задача сервера AdminP просыпается через периодические интервалы времени (указанные в разделе «Administration Process» документа «Сервер») и обрабатывает запросы, ожидающие в базе данных Administration Requests. Каждому типу запросов, помещенных в базу данных Administration Requests, назначено прокси-действие. Эти прокси-действия по сути являются операционным кодом, который запускает процесс администрирования

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

Запросы AdminP не ограничиваются только одним доменом Notes. Вы можете настроить междоменные документы для совместного выполнения некоторых запросов между доменами

Domino Adminictrator

В клиенте Domino Administrator наличествуют все возможности для создания и управления запросами к AdminP

Клиент Notes

В Notes / Domino 6 клиент Notes стал активным участником процесса администрирования. Теперь клиент может выполнять и запускать множество различных процессов администрирования. Например, клиент может принимать изменения имени пользователя и сертификаты x509v3 в файл Notes.id. Клиент может инициировать делегирование ACL календаря. Клиент участвует в процессе перемещения пользователя на другой сервер и может выдать запрос на изменение пароля пользователя и / или синхронизировать пароль к учётной записи Notes и веб-пароль. И теперь клиент автоматически принимает информацию для восстановления идентификатора без подсказок пользователя

Каталог Domino

Каталог Domino (Domino Directory) обеспечивает выполнение части инструкций, используемых с AdminP. Например, в процессе переименования пользователя, информация сертификата изменяется. Сертификат хранится в документе Person в Domino Directory. Когда процесс переименования выполняется, это указывается в документе «Person» в поле «Name change request:». Имя каждого пользователя хранится в различных полях документа Person. При переименовании пользователя сохраняется как старое, так и новое имя.

Кроме того, у каждого сервера есть документ Server, который определяет, как сервер управляется. В каждом документе Server есть раздел, посвященный параметрам AdminP.

Команды AdminP влияют на информацию Domino Directory, в том числе:

  • имена ресурсов
  • кластеры
  • документы Person, включая информацию о клиенте
  • синхронизацию Интернет-паролей
  • изменение и удаление групп
  • информацию о сервере (сетевой протокол и версия программного обеспечения)
  • политики
  • конфигурация Certificate Authority (CA)
  • контроль лицензий

База Certification Log

База Certification Log (certlog.nsf) создаётся при инсталяции первого сервера в организации. Журнал сертификации регистрирует связанные с сертификацией действия Domino, включая регистрацию нового пользователя и сервера, повторную сертификацию и переименование пользователей, а также переход пользователя от одного сертификатора организации к другому. В каждой записи журнала отражены данные, показанные на следующем рисунке

Рисунок 1. Документ базы Certification log
Certification log

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

База Adminstration Requests

База данных Administration Requests (admin4.nsf) содержит все административные запросы одного домена. Каждый запрос (через прокси-действие) помещается в базу Administration Requests и реплицируется на все серверы домена.Эта база детально описано ниже в этой статье

Административный сервер

Каждой базе Domino должен быть назначен административный сервер, который указывается в таблице управления доступом (ACL) базы данных. Это относится и к каталогу Domino (Domino Directory). Настройка административного сервера, установленная в ACL, сообщает задаче Adminp, на каком сервере обрабатывать каждую базу данных. Административный сервер базы отображается в ACL значком ключа рядом с его именем. В каждом домене есть один первичный административнй сервер. Первичеый административный сервер определяется значением в ACL Domino Directory (names.nsf). Чтобы настроить административный сервер базы (в том числе, и первичный административный сервер), выделите базу данных и в главном меню выберите Файл -> База данных -> Управление доступом..., перейдите к закладке Дополнительно

Рисунок 2. Диалоговое окно Таблицы управления доступом
Access Control List dialog box

Например, предположим, что вам нужно переименовать 1000 пользователей. Каждый пользователь может быть записан в полях типа Readers, Authors и Names ста тысяч документов базы данных. Это означает, что каждый документ может нуждаться в изменении. Рассмотрим следующую иллюстрацию:

Рисунок 3. Переименование 1000 пользователей
Renaming 1,000 users

В рассматриваемом примере четыре сервера и два приложения. Server A - это административный сервер Domino Directory. Это делает его основным административным сервером для этого домена. На Server B есть два приложения: App 1 и App 2. Сервер администрирования для приложения App 1 - это Server B, а сервер администрирования для приложения App 2 - это Server D. Сервер C имеет реплику каждого приложения. Запрос на изменение значений полей доступа к документу выдается на основном административном сервере (Server A), а затем отправляется на другие серверы для обработки. Каждый сервер получает запросы и обрабатывает их в зависимости от времени получения и настроек в документе Server.

Обратите внимание, что база данных приложения App 1 находится как на сервере B, так и на сервере C. Если запрос на изменение имени выполняется на обоих серверах, у вас будет 100 000 изменений в обеих репликах, что приведет к большому числу конфликтов репликации. .Для предотвращения этого AdminP просматривает ACL каждой базы данных на каждом сервере. Если запись административного сервера в ACL совпадает с именем этого сервера, он обрабатывает запрос. Если запись административного сервера в ACL базы данных не соответствует этому серверу, запрос игнорируется. В случае сервера Server B запись ACL для приложения App 1 идентифицирует Server B как административный сервер. Таким образом, запросы, поступающие на сервер Server B, выполняются в приложении App 1. Запросы администрирования также отправляются на сервер Server C. Но на этом сервере нет приложений, для которых сервер был указан как административный сервер. Таким образом, никакие запросы не обрабатываются на сервере Server C. Наконец, сервер Server D указан как административный сервер в ACL для приложения App 2. Таким образом, любые запросы, поступающие на сервер Server D, выполняются в приложении App 2

Как видите, эта архитектура позволяет только одному серверу обновлять любое отдельное приложение. Итак, теперь вы спрашиваете: «Нужно ли мне добавлять запись административного сервера для каждой базы данных в моей среде Domino?» Ответ - да, но не паникуйте; есть несколько способов сделать это:

  • Вручную. Откройте раздел «Дополнительно» диалогового окна ACL и отредактируйте поле «Административный сервер». Это отлично работает для одной или двух баз данных, но в больших средах это, очевидно, займет очень много времени.
  • Через клиент администратора (Domino или Web). Клиент администратора позволяет вам настроить отдельные базы данных или большую группу баз данных с помощью одной операции. Откройте клиент администратора и выберите базы данных, которые необходимо обновить. Щелкните правой кнопкой мыши и выберитеAccess Control - Manage... (Таблица управления доступом - Управление).Откроется стандартное диалоговое окно ACL. При необходимости отредактируйте списки ACL и сохраните запись. Это обновит настройки административного сервера для всех выбранных баз данных.
  • Через LotusScript. Класс NotesACLEntry имеет свойство чтения / записи, которое можно использовать в агенте LotusScript. Используя свойство isAdminServer, вы можете создать простой агент, который считывает и / или устанавливает административный сервер записи ACL.
  • Через API Lotus Notes. Вы можете создавать свои собственные инструменты для редактирования и управления именем административного сервера базы данных. Для этого обычно используются две функции: ACLGetAdminServer и ACLSetAdminServer.
  • Инструменты внешних поставщиков. Существует множество инструментов различных поставщиков, которые включают функции управления административным сервером. За подробностями обращайтесь к своему поставщику

Proxy-действия

Теперь посмотрим на команды AdminP. Каждая команда управляется отдельным документом, помещенным в базу данных Administration Requests. В каждом документе есть поле с именем ProxyAction. Эти proxy-действия можно увидеть в двух местах: в свойствах поля документа в базе данных Administration Requests или в форме документа запроса на администрирование. Для последнего откройте общее поле ProxyAction и посмотрите список вариантов, например:

Рисунок 4. Значения поля ProxyAction
ProxyAction field values

У каждого proxy-действия есть номер. В версии R5 имеется 82 различных proxy-действия, а в Domino 6 - 165. Номера proxy-действий обратно совместимы. Например, proxy-действие 1 (которое переименовывает пользователя в списке управления доступом) одинаково как в R5, так и в Domino 6, а proxy-действие 119 (переименование веб-пользователя в списке управления доступом) является новым для Domino 6. См. Proxy-действия R5 и Domino 6 для получения полного списка

Каждый запрос AdminP может создавать ответный документ, называемый журналом процесса. Документ ответа показывает, был ли запрос AdminP завершен успешно или завершился ошибкой с сообщением об ошибке. Большинство proxy-действий создаются на основном административном сервере. Некоторые из них могут быть инициированы на распределенном административном сервере. Например, если вы переименовываете пользователя, основной запрос отправляется AdminP на основной административный сервер. В этом примере proxy-действие 6 (move person's name in hierarchy, переместить пользователя в иерархии) создается на основном административном сервере. Вы утверждаете изменение имени, и основной сервер администрирования создает proxy-действие 8 (initiate a rename in the Domino Directory, инициировать переименование в Domino Directory). AdminP обновляет открытый ключ, а также обновляет поле Certificate Request в документе Person

На вкладке «Администрирование» документа Person есть поле «Запрос на изменение». Внутреннее имя этого поля - DisplaychangeRequest. Формула поля:



@If((ChangeRequest != "" | $AdminpOldWebNameExpires != ""); "Pending";"None")
Если в поле ChangeRequest есть значение, отображается значение Pending («Ожидание»)

Типы proxy-действий

Существует три основных типа proxy-действий AdminP:

  • Запросы, выполняемые на основном административном сервере
  • Операции, выполняемые на всех распределенных административных серверах
  • Операции, выполняемые на целевом сервере

В следующих разделах описаны эти типы proxy-действий

Запросы, выполняемые на основном административном сервере

Выполнение большинства запросов AdminP инициализируется на основном административном сервере. Однако фактически запрос (документ с прокси-действием) может быть создан практически на любом сервере. Рассмотрим запрос перемещения пользователя в иерархии организации. Это proxy-действие 6 (move person's name in hierarchy, переместить пользователя в иерархии). Вы инициируете этот процесс из Domino Directory. В базе данных запросов на администрирование (Administration Requests) создается документ, который требует одобрения администратора. После утверждения этого документа создается другой документ. Это proxy-действие 8 (инициировать переименование в адресной книге). Это proxy-действие может выполняться только на основном административном сервере

В Domino Directory после успешного выполнения proxy-действия 8 обновляется информация пользователя в Person документе. Документ реплицируется на распределённый сервер. Пользователь открывает базу данных на этом распределённом сервере, и создается proxy-действие 5 (rename person in Address book, переименовать пользователя в адресной книге). Затем база данных Administration Requests реплицируется с основным административным сервером, и этот запрос выполняется на нём. В этом примере все proxy-действия сервера 6, 8 и 5 выполнялись на основном сервере администрирования. Proxy-действие 5 было создано на распределенном сервере, но это действие было инициировано, когда документ пользователя Domino Directory был обновлен. В каждом случае фактическое выполнение proxy-действия происходило на основном административном сервере, а не на распределённом сервере.

В следующей таблице перечислены действия прокси AdminP, которые выполняются только на основном административном сервере (обратите внимание, что это не полный список):



Удалить из каталога Domino (Delete in Domino Directory)
Ускоренное создание реплики (Accelerate create replica)
Поместить информацию о версии программного обеспечения в серверный документ
(Place server's Notes build number into Server document)
Поместить тип каталога в серверный документ (Store directory type in Server document)
Переименовать сервер в каталоге Domino (Rename server in Domino Directory)
Изменить информацию в поле Roaming server в документе Person (Replace roaming server's field in Person document)
Переименовать пользователя (Rename person in Domino Directory)
Обновить информацию о пользователе в каталоге Domino (Modify user information stored in Domino Directory)
Переместить пользователя в иерархии организации (Move person's name in hierarchy)
(фактически это действие может быть одобрено на любом сервере)
Изменить конфигурацию Certificare Authority в каталоге Domino (Modify CA configuration in Domino Directory)
Удалить мониторы статистики из каталога Domino (Delete statistic monitors in Domino Directory)
Обновить информацию о лицензии в каталоге Domino (Update license tracking information in Domino Directory)
Инициировать переименование в каталоге Domino (Initiate rename in Domino Directory)
Повторно инициировать переименование в каталоге Domino (Re-initiate rename in Domino Directory)
Перезаверить сертификат сервера (Recertify server in Domino Directory)
Удалить документ политики (Delete Policy document in Domino Directory)
Перезаверить сертификат пользователя (Recertify person in Domino Directory)
Инициировать переименование web-пользователя (Initiate Web user rename in Domino Directory)
Удалить из документов Person (Delete in Person documents)
Переименовать web-пользователя (Rename Web user in Domino Directory)
Изменить пароль пользователя (Change user password in Domino Directory)
Переименовать web-пользователя в документах Person (Rename Web user in Person documents)
Добавить Internet-сертификат в документ Person (Add Internet certificate to Person document)
Удалить web-пользователя из каталога Domino (Delete Web user in Domino Directory)
Удалить пользователя из каталога Domino (Delete person in Domino Directory)
Изменить HTTP-пароль пользователя (Change HTTP password in Domino Directory)
Удалить сервер из каталога Domino (Delete server in Domino Directory)
Обновить статус перемещаемого пользователя в документе Person (Update roaming user state in Person document)
Удалить группу из каталога Domino (Delete group in Domino Directory)
Обновить информацию о перемещаемом пользователе в документе Person (Update roaming user information in Person document)
Подтвердить удаление пользователя (Approve delete person in Domino Directory)
Перезаверить перекрёстный сертификат (Recertify cross certificate in Domino Directory)
Подтвердить удаление сервера (Approve delete server in Domino Directory)
Перезаверить Certificate Authority (Recertify Certificate Authority in Domino Directory)
Подтвердить переименование пользователя (Approve rename person in Domino Directory)
Добавить или изменить группу (Add or modify group in Domino Directory)
Подтвердить переименование сервера (Approve rename server in Domino Directory)
Изменить информацию восстановления учётной записи (Modify ID recovery information in Domino Directory)
Внести изменения в документ помещения/ресурса (Modify room/resource in Domino Directory)
Вы можете спросить: «Как я узнаю, запросы какого типа будут работать на каком сервере?» Откройте базу данных Administration Requests и просмотрите документ запроса к AdminP. Вы видите поле под названием Сервер (ы) для выполнения действия (Server(s) to perform the action). В нашем примере это поле установлено на административный сервер Domino Directory

Операции, выполняемые на всех распределенных административных серверах

Продолжим наш пример. Пользователь принял запрос на изменение имени, и на одном из распределённых серверов было создано proxy-действие 8 (initiate rename in Address book, инициировать переименование в адресной книге). Этот запрос теперь реплицируется на основной сервер домена. После выполнения этого proxy-действия AdminP создает дополнительные запросы. Одним из них является proxy-действие для обновления списков ACL в каждой базе данных на каждом сервере в домене. Это proxy-действие 1. Опять же, это легко определить, просто взглянув на документ запроса в базе данных запросов на администрирование

Документ запроса включает поле Server(s) to perform the action: (Сервер (ы) для выполнения действия:). См. пример на рисунке ниже. Если в этом поле отображается звездочка, этот запрос пытается отработать на всех серверах в домене. Вот несколько примеров команд, где в поле указана звездочка:

  • Удалить пользователя из таблицы управления доступом (Delete user in Access Control List)
  • Переименовать в таблице управления доступом (Rename in Access Control List)
  • Переместить пользователя в иерархии (Move person's name in hierarchy)
  • Удалить из полей доступа документов (Delete in Reader/Author fields)
  • Переименовать пользователя в списках непрочтённых документов (Rename person in unread list)

Операции, выполняемые на целевом сервере

AdminP действительно очень умён. Именно здесь на помощь приходят целевые серверные команды. Давайте снова продолжим наш пример с переименованием пользователей. Пока вы запустили процесс переименования, пользователь принял запрос на изменение имени, и AdminP создал запрос на изменение имени в ACL. Теперь AdminP анализирует документ Person этого пользователя и определяет, нужно ли создавать какие-либо целевые команды. Если в документе Person пользователя есть указание почтового файла, AdminP создает два запроса

  • Переименовать пользователя в записях календаря и профайлах почтовой базы данных (Rename person in calendar entries and profiles in mail file)
  • Переименовать пользователя в базе данных планировщика ресурсов (Rename person in Free Time database:)

Запросы реплицируются на целевой сервер (почтовый сервер пользователя) и выполняются там. Вы можете определить, какие команды предназначены для целевого сервера, открыв документ запроса и посмотрев на поле Server(s) to perform the action: (Серверы для выполнения действия.). В нашем случае значение равно NTMain, что означает, что команда выполняется только на этом сервере.

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



ASDDList
:= "0":"2":"3":"4":"5":"7":"8":"9":"10":"11":"12":
"16":"19":"26":"28":"29":"30":"34":"35":"36":"37":
"40":"41":"44":"46":"47":"50":"52":"54":"55":"56":
"63":"64":"67":"70":"71":"73":"76":"77":"80":"83":
"85":"86":"89":"95":"96":"97":"98":"99":"103":"107":
"109":"110":"113":"118":"120":"121":"127":
"133":"134":"136":"141":"144"
:"146":"157":"159";

SELECT @IsMember (@LowerCase
(@Name ([CN] ; ProxyServer));"*":@LowerCase(@Name([CN]; @UserName)))
& Type != "AdminLog" & !@IsMember (ProxyAction;ASDDList)
Внимание: это только пример кода. Мы не предлагаем поддержку по этому поводу, поэтому используйте его на свой страх и риск. Используйте эту формулу только на распределенных серверах, а не на хабе или основном сервере администрирования. Кроме того, вам может потребоваться обновлять эту формулу с каждым новым релизом Domino

Время выполнения proxy-действий

Proxy-действия выполняются в разное время в зависимости от типа proxy-действия. Есть четыре разных интервала:

  • Немедленно. Эти запросы обычно выполняются в течение одной минуты. Примеры таких запросов: проверка доступа к почтовому серверу, предоставление доступа новому почтовому серверу, создание новой реплики почтовой базы, добавление информации в поля mail file документа Person, изменение поля mail file и отправка изменений на новый почтовый сервер.
  • Ежедневно. Эти запросы обрабатываются один раз в день, как определено настройкой в документе Server. Эти запросы включают все новые и изменённые ежедневные запросы на обновление документа Person в Domino Directory, переименование пользователя в списках непрочитанных документов и удаление устаревших запросов на изменение.
  • По расчётному времени. Они используются рекомендованным планом балансировки ресурсов. Этот процесс генерируется Tivoli Analyzer. Запросы по расчётному времени обычно применяются для действий перемещения базы данных или создания реплики. Обратите внимание, что запросы на выполнение по расчётному времени позволяют указать время выполнения запроса AdminP. Примеры синхронизированных запросов включают проверку доступа для создания новой реплики, проверку доступа для создания перемещаемой реплики, проверку доступа к почтовому серверу и проверку доступа для перемещаемой реплики вне кластера Domino
  • Отложенные. Отложенные запросы выполняются по времени, установленному в документе Server. Переименование в полях Reader / Author - отложенный запрос

База данных Administration Requests

Все дороги ведут в Рим, или, в нашем случае, все действия AdminP попадают в базу данных административных запросов. Эта база данных содержит все запросы для одного домена. (Мы обсудим междоменные функции во второй части этой серии статей). Каждый запрос (через proxy-действие), помещенный в базу данных Administration Requests, реплицируется на каждый сервер в домене [Прим. переводчика - выше авторами приведена формула выборочной репликации - при её наличии не все документы реплицируются на серверы]:

Рисунок 5. Диаграмма admin4.nsf
Admin4.nsf diagram

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

Например, предположим, что вы хотите повторно сертифицировать пользователя. Запрос на повторную сертификацию пользователя в Domino Directory (proxy-действие 10) может быть отправлен любому серверу в домене. Запрос реплицируется на основной административный сервер (Server A на предыдущей диаграмме), где он обрабатывается. Процесс запускается в клиенте администратора, когда вы запрашиваете повторную сертификацию пользователя. Proxy-действие создается в базе данных Administration Requests

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

  • Обновляет документ Person этого пользователя в Domino Directory. Открытый ключ для пользователя заменяется значением в документе запроса на администрирование
  • Создает ответный документ AdminLog с информацией о статусе

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

База данных Administration Requests имеет несколько представлений. Каждое представление предоставляет отчётную информацию или доступ для подтверждения определенных действий. (Многие действия требуют одобрения администратора). На следующем рисунке показаны основные представления в базе данных Administration Requests Domino 6.

Рисунок 6. Административные запросы в admin4.nsf

Administration requests in Admin4.nsf

В следующих разделах описываются эти представления.

Administrative Attention Required (Требуется административное внимание)

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

Individual Approval Required (Требуется индивидуальное одобрение)

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

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

Pending Administrator Approval\By Age, Pending Administrator Approval\By Server (Ожидает утверждения администратора \ по сроку, ожидает утверждения администратора \ по серверу)

Документы отображаются в этих представлениях (отсортированных по времени ожидания или серверу), если отсутствует поле ApprovalFlag и выдается один из следующих запросов:

  • Междоменные запросы, включая одобрение удаления пользователя в Domino Directory, одобрение удаления сервера в Domino Directory, одобрение переименования пользователя в Domino Directory и одобрение переименования сервера в Domino Directory
  • Подтвердить удаление ресурса
  • Подтвердить удаление приватных элементов дизайна
  • Подтвердить удаление реплики
  • Подтвердить отмену изменения имени
  • Утвердить запрос на сертификат
  • Утвердить запрос на изменение имени пользователя
  • Утвердить новый запрос открытого ключа

All Activity by Server (Вся активность по серверу)

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

All Errors by Date, All Errors by Server (Все ошибки по дате, все ошибки по серверу)

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

All Requests by Action, All Requests by Name, All Requests by Server (Все запросы по действию, все запросы по имени, все запросы по серверу)

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

All Requests by Originating Author (Все запросы по автору)

Это представление показывает, кто отправлял запросы AdminP. В развернутом виде это представление также показывает пользователя-объект обработки

All Requests by Time Initiated (Все запросы по времени инициирования)

В этом представлении отображаются все записи и ответные документы в зависимости от того, когда proxy-действия были инициированы в базе данных Administration Requests

Name Move Requests (Запросы на перемещение имен)

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

Cross Domain Configuration (Междоменная конфигурация)

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

Cross Domain Delivery Failures (Сбои междоменной доставки)

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

Certificate Requests (Запросы сертификатов)

В этом представлении отображаются запросы на создание сертификата Internet или Notes. Это представление контролируется лицом, назначенным центром сертификации (Certification Authority, CA) или центром регистрации (Registration Authority, RA).

Recovery Information Update (Обновление информации для восстановления)

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

Заключение

Эта статья познакомила вас с AdminP. Мы кратко ознакомились с его компонентами и объяснили, как работают proxy-действия и база данных Administration Requests. Во второй части этой серии статей мы подробнее рассмотрим AdminP, рассмотрим запросы междоменного администрирования и способы управления функциями AdminP с помощью настроек документа сервера, команд консоли сервера, файла Notes.ini и интервалов очистки базы данных

Ссылки

Всё о задаче AdminP. Proxy-действия в R5 и Domino 6

Всё о задаче AdminP. Часть 2
 
  Опубликовано — 03/30/2021 |    Источник: IBM Developer



Добавить комментарий
Имя * :
e-mail
Комментарий * :
Код подтверждения * :


Мероприятия
Пресс-релизы
Биржа труда
Последнее на форуме
 
А так же:
Как удалить профиль?
16.04.2016 00:08:51
Скопировать в буфер поле документа
24.05.2015 08:55:52
Импорт DXL-описания документов в Lotus Domino. Одноимённые поля
16.04.2015 16:49:58
 
© LOGOSPHERE.RU