Алгоритм маршрутизации
Задача Router периодически просматривает "свой" MAIL.BOX на предмет появления в нем сообщений. Для каждого поступившего сообщения выполняется следующее:
· Определение, принадлежит ли адрес получателя сообщения текущему домену или другому домену.
· Если адрес получателя принадлежит текущему домену:
· Поиск имени почтового сервера и имени файла почтового ящика получателя в базе "адресная книга" (по информации из документов Person или MailInDatabase).
· Если почтовый сервер получателя есть текущий сервер:
· Доставка сообщения в файл почтового ящика получателя.
· Если почтовый сервер получателя - другой сервер:
· Определение маршрута "наименьшей стоимости" от текущего сервера к серверу получателя.
· Передача сообщения с текущего сервера в MAIL.BOX на следующий сервер в этом маршруте.
· Если адрес получателя принадлежит другому домену:
· Определение маршрута "наименьшей стоимости" от текущего сервера до любого доступного сервера в домене получателя.
· Передача сообщения с текущего сервера в MAIL.BOX на следующий сервер в маршруте.
В алгоритме содержится два разных уровня:
маршрутизация между доменами и маршрутизация внутри домена. При передаче между доменами выбирается "маршрут наименьшей стоимости" от исходного сервера до любого доступного сервера или шлюза в домене назначения. Сообщение сначала передается между доменами, пока не достигнет домена получателя. Затем сообщение передается внутри домена. Поскольку Router "не знает" полную топологию сети в рамках нескольких доменов, общий маршрут от сервера-источника до сервера назначения в другом домене, вообще говоря, не является оптимальным.
Маршрутизация внутри домена в пределах одной поименованной сети выполняется "напрямую" от сервера к серверу. Router использует при этом информацию только из документов Server в адресной книге. Документы Connection в этой ситуации вообще не анализируются - потому и не нужно создавать в адресной книге документов Connection для передачи почты между серверами в одной поименованной сети.
Если внутри домена имеется несколько поименованных сетей, выбирается маршрут "наименьшей стоимости" от исходного сервера до сервера назначения, и сообщение отправляется на следующий сервер в этом маршруте.
Алгоритм репликации
Подробно алгоритм репликации включает следующие шаги.
· Установление соединения с сервером. В соответствии с имеющимся в адресной книге расписанием, составленным администратором, или по введенной вне расписания команде консоли, используя Randomized exponential backoff algoritm, инициирующий репликацию сервер соединяется с вызываемым сервером. Выполняется процедура аутентификации серверов и дополнительные процедуры, выбранные в секциях Security и Restrictions документа Server на вызванном сервере.
· Построение списка реплицируемых баз. Каждый сервер поддерживает в своей виртуальной памяти упорядоченную по идентификатору реплики базы таблицу с информацией обо всех имеющихся на нем базах - т.н. "кэш идентификаторов реплик". В нем содержатся сведения о базах и шаблонах, находящихся в каталоге данных Notes и рекурсивно его подкаталогах, а также во всех Directory Links
и рекурсивно их подкаталогах. В общем случае репликатор, сравнивая кэш идентификаторов реплик "своего" сервера и кэш идентификаторов реплик на вызванном сервере, создает список имеющих одинаковый идентификатор реплики баз на обоих серверах. Однако из команды консоли или документа Connection может следовать, что в репликации должны участвовать только базы соответствующих приоритетов или только базы в указанных каталогах или явно перечисленные базы на вызывающем сервере. Если это так, то репликатор, сравнивая кэши идентификаторов реплик, учитывает не все, а только необходимые базы из кэша идентификаторов реплик "своего" сервера.
· Далее для каждой базы из списка реплицируемых выполняется следующее.
· Не запрещены ли репликации базы? Если в установках одной из реплик выбрана опция Temporary disable replication, все заканчивается появлением на консоли сервера сообщения Replication is disabled for <сервер база>.
· Может ли каждый из серверов открыть реплику на другом сервере? Если один из серверов имеет в ACL реплики на другом сервере уровень доступа No Access, все заканчивается появлением сообщения Access control is set in <сервер база> to not allow replication from <сервер база>. Аналогично происходит, если реплика находится в Directory Link, а сервер не имеет доступа к этой Directory Link. Если же оба сервера имеют доступ к обеим репликам, репликатор открывает реплику на вызванном сервере.
· Репликация ACL. Это происходит, если вызванный сервер имеет в ACL вызвавшего сервера доступ менеджера и в установках реплики на вызвавшем сервере выбрана опция Replicate incoming: Access Control List. Репликатор проверяет, не изменилась ли ACL в реплике на вызванном сервере после последнего изменения ACL "своей" реплики. Если изменилась, репликатор получает ACL с вызванного сервера и заменяет ACL "своей" реплики, после чего снова проверяет, может ли каждый из серверов открыть реплику на другом сервере. Если репликация выполняется по схеме Pull-Push, зеркально-аналогичные проверки и действия выполняются этим репликатором по отношению ACL на вызванном сервере. При репликации по схеме Pull-Pull их выполнит репликатор вызванного сервера на второй фазе репликации.
· Репликация элементов дизайна. Это происходит, если вызванный сервер имеет в ACL вызвавшего сервера доступ не ниже дизайнера, а в установках реплики на вызвавшем сервере выбраны опции Replicate incoming: Forms, Views, еtс., Agents, Replication formula.
Элемент дизайна хранится в базе данных подобно документу. И, подобно документу, каждый элемент дизайна имеет свой идентификатор. Универсальный идентификатор, являющийся частью идентификатора, одинаков во всех репликах базы. Но имеющаяся в составе идентификатора дата-время последней модификации элемента дизайна (SD) может быть разной в каждой реплике.
Репликатор создает список идентификаторов всех элементов дизайна в реплике на вызванном сервере, которые были изменены со времени последней репликации, а если история репликаций очищена, то с Cutoff Date. Затем для каждого идентификатора из этого списка предпринимается попытка определить идентификатор элемента дизайна из "своей" реплики, имеющего такой же универсальный идентификатор.
Если это удалось (т.е. в репликах есть элементы дизайна с одинаковым универсальным идентификатором), остается сравнить времена последней модификации этих элементов. Если в реплике на вызванном сервере "более свежий" элемент дизайна, репликатор получает его и заменяет им имеющийся в "своей" реплике. Но если только этого не запрещают делать опции Replicate incoming: Forms, Views, еtс., Agents, Replication formula "своей" реплики. Удаление элементов дизайна тоже происходит подобно удалению документов - посредством передачи "окурков" с более поздним временем модификации. А репликационных конфликтов для элементов дизайна не бывает.
Если же в реплике на "своем" сервере нет элемента дизайна с таким же универсальным идентификатором, как в реплике на вызванном сервере, остается добавить в "свою" реплику новый элемент дизайна.
Если репликация выполняется по схеме Pull-Push, зеркально-аналогичные проверки и действия выполняются этим репликатором и по отношению элементов дизайна на вызванном сервере. При репликации по схеме Pull-Pull их выполнит репликатор вызванного сервера на второй фазе репликации.
· Репликация документов. Это происходит, если вызванный сервер имеет в ACL вызвавшего сервера возможность создавать или изменять документы.
Вначале репликатор, используя формулу отбора селективной репликации "своей" реплики (или по умолчанию SELECT @All), создает по документам на вызванном сервере вид, содержащий "потенциально допустимые" для приема в "свою" реплику документы. Затем репликатор "просматривает" этот вид и создает список идентификаторов документов в реплике на вызванном сервере, которые были изменены со времени последней репликации, а если история репликаций очищена, то с Cutoff Date. Если документ в реплике на вызванном сервере был в последний раз модифицирован раньше, чем текущее время минус интервал удаления для реплики на "своем" сервере, его идентификатор исключается из списка.
Для каждого идентификатора из этого списка предпринимается попытка определить идентификатор документа из "своей" реплики, имеющего такой же универсальный идентификатор.
Если это удалось (т.е. в обеих репликах есть документы с одинаковым универсальным идентификатором), остается сравнить времена последней модификации (SD) и последовательные номера (SN) этих документов.
Если документ с предшествующей репликации изменился в реплике на вызванном сервере, но не изменился в реплике на "своем" сервере, репликатор копирует измененный документ и замещает им документ в "своей" реплике. То же произойдет, если документ в реплике на вызванном сервере был удален. Вместо удаленного документа остается "окурок" с большим последовательным номером и датой модификации. "Окурок" должен копироваться репликатором в "свою" реплику и заместить имевшийся в ней документ, вызывая тем самым его удаление. Но если только этого не запрещает делать опция Replicate incoming: Deletions "своей" реплики.
Если же документ изменился на обеих сторонах, происходит репликационный конфликт (рассматривается в 6.2.14).
Если же в реплике на "своем" сервере нет документа с таким же универсальным идентификатором, как в реплике на вызванном сервере, его остается добавить в "свою" реплику как новый документ.
Если репликация выполняется по схеме Pull-Push, зеркально-аналогичные проверки и действия выполняются этим репликатором и по отношению документов
на вызванном сервере. При репликации по схеме Pull-Pull их выполнит репликатор вызванного сервера на второй фазе репликации.
Если документ был модифицирован в одной реплике позже, чем было произведено его удаление в другой реплике, модифицированный документ должен "перекрыть окурок". То же произойдет, если в результате ряда модификаций последовательный номер документа в одной реплике оказался больше, чем последовательный номер "окурка".
Наконец, в версиях 4.х при копировании документа происходит не полное копирование всех полей, как это было в версиях 3.х. Копируются только поля, у которых неодинаковые Seq Num. Поля же с одинаковым Seq Num нет смысла копировать - они одинаковы в обеих репликах. Это существенным образом сокращает объем информации, передаваемой при репликации. Именно это и называют "репликацией на уровне полей" - а более строго, пунктов.
Обновление записи в истории репликаций. Только когда репликация успешно завершилась, репликатор вызывавшего сервера обновляет записи в истории репликаций "своей" реплики: когда с вызванного сервера были приняты документы (Received) и когда с вызывавшего сервера были отправлены документы на вызванный (Send). При неуспешной репликации записи в истории репликаций не обновляются. Если репликация выполняется по схеме Pull-Push, репликатор обновляет и историю репликаций на вызванном сервере. При репликации по схеме Pull-Pull это выполнит репликатор вызванного сервера на второй фазе репликации.
· Завершение репликационной сессии. Когда список реплицируемых баз "исчерпан", репликатор или разрывает соединение (схема Pull-Push), или передает запрос "на обратную репликацию" в очередь репликатора на вызванном сервере (схема Pull-Pull).
Алгоритм выбора следующего сервера в маршруте (NextHop)
Алгоритм использует информацию из документов Person, MailInDatabase, Server, Connections и Domain общей адресной книги. Однако необходимая информация не выбирается всякий раз из адресной книги. При старте сервера она загружается в так называемые таблицы маршрутизации, находящиеся в виртуальной памяти сервера. Таблицы маршрутизации обновляются всякий раз, когда в адресную книгу внесено любое изменение. Кроме того, по умолчанию такие обновления выполняются каждые 60 минут. В версиях 4.х в файле NOTES.INI может применяться переменная MailDynamicCostReset, задающая интервал времени (в минутах), с которым Router должен восстановить в таблицах информацию из адресной книги.
Именно по таблицам маршрутизации и выполняется выбор маршрута. С позиций теории графов при этом решается задача выбора пути минимальной длины на графе от заданной вершины-источника до заданной вершины-назначения. В качестве следующего сервера в маршруте выбирается тот, к которому ведет первая дуга в пути минимальной длины.
Практически же дело осложняется следующими моментами.
· Ввиду целочисленности и ограниченности диапазона стоимостей соединений возможно существование нескольких маршрутов наименьшей стоимости. Router выбирает один из них. Известно, что Router с версии 4.11 из нескольких маршрутов наименьшей стоимости выбирает тот, в котором наименьшее количество дуг.
· Учитывается "история" отказов связи по соединению (дуге графа). Если попытка установления соединения терпит неудачу (нет ответа, таймаут и т.п.), Router добавляет единицу к стоимости этого соединения в своей таблице маршрутизации. При попытке повторить передачу сообщения в следующий раз вновь решается задача выбора маршрута наименьшей стоимости, но увеличение стоимости "плохого" соединения, вообще говоря, способствует получению другого оптимального маршрута, чем при предыдущей попытке. Очевидно, такое возможно только при наличии альтернативных путей от сервера-источника к серверу назначения. Логично было бы ожидать, что увеличение стоимости соединения происходит после каждой неудачи установления соединения. Но увеличение стоимости соединения на единицу выполняется только один раз, а не при каждой последующей неудачной попытке (документ 138604 от 26.06.96 из Lotus Notes Knowledge Base). В результате стоимость "плохого" соединения может не возрасти должным образом, чтобы от него отказались при очередной попытке. Например, пусть с сервера A на сервер B для доставки почты имеется два документа Connection, один со стоимостью 5 (дуга AB1), а другой со стоимостью 8 (дуга AB2). В этом случае второй документ Connection
(дуга AB2)
никогда не будет использоваться при доставке почты, поскольку в таблицах маршрутизации сервера A стоимость дуги AB1 может возрасти только до 6. Если вы измените второй документ Connection, уменьшив стоимость дуги AB2 до 6, то после неудачной попытки соединения по дуге AB1, когда ее стоимость в таблицах достигает 6, возникает неопределенность: будет выбираться одна из двух возможных дуг, но непонятно, какая именно. Если вы уменьшите стоимость дуги AB2 до 5, непонятно, какая из двух дуг выбирается при первой попытке установить соединение, зато при повторных попытках установления соединения будет выбираться уже другая дуга. В результате становится понятно, почему большинство попыток администраторов вводить несколько "резервных" маршрутов доставки почты и "глубоко продуманно" управлять стоимостями соединений оканчиваются провалом. К сожалению, рациональная политика на сегодняшний момент (версия 4.51) состоит в том, чтобы вводить "резервные" маршруты с разными приоритетами соединений, но использовать для них стоимости соединений, выбираемые по умолчанию.
· Используется еще одна особенность, называемая "оппортунистической маршрутизацией" (opportunistic routing). Если сервер успешно принимает входящий вызов (типа Dialup Modem или X.25) от другого сервера, Router принявшего вызов сервера восстанавливает в первоначальное значение стоимость соединения с вызывавшим сервером в своих таблицах маршрутизации. Это, вообще говоря, будет способствовать более активному использованию данного соединения в дальнейших попытках передачи почты.
· При передаче сообщений с сервера на сервер возможно появление "петель". Чтобы отследить соединения (дуги графа), по которым сообщение уже передавалось, в сообщении "поддерживается" поле RouteServers. Оно содержит список серверов, "через которые" сообщение "уже прошло". Как только Router обнаруживает петлю, он немедленно восстанавливает первоначальную стоимость соединения в таблицах маршрутизации. Поскольку наличие петли отражено в сообщении в поле RouteServers, впоследствии ни один из Router-ов уже не станет вновь передавать сообщение по этой петле. Однако петля может включать много соединений... Для предотвращения "длинных" петель в сообщении "поддерживается" счетчик пересылок с сервера на сервер (Hop Counter - поле $Hops), начальное значение которого устанавливается равным 25. При каждой передаче сообщения с сервера на сервер Hop Counter уменьшается на единицу. Когда его значение уменьшится до нуля, доставка сообщения прекращается, а отправителю возвращается уведомление о недоставке.
· Адаптивные изменения стоимости соединений производятся только в таблицах маршрутизации, находящихся в виртуальной памяти сервера. Эти изменения не вносятся из таблиц в адресную книгу и, очевидно, не реплицируются на другие серверы домена. Адаптивные изменения в таблицах будут утеряны при перезапуске сервера, при модификации адресной книги или через 60 (или MailDynamicCostReset) минут, и Router "в очередной раз забудет старый опыт и вновь начнет учиться на своих ошибках".
Архивное копирование и восстановление СПЯ
Архивное копирование СПЯ должно производиться по крайней мере один раз в день. В дополнение к этому вы можете создавать новый СПЯ на сервере каждую неделю и делать его активным, т.е. используемым задачей Router
для доставки новой почты.
Если произойдет сбой, для восстановления СПЯ рекомендуется такой путь.
· Выгрузить "самую свежую" резервную копию СПЯ в каталог, не являющийся каталогом сервера. Каталоги сервера включают каталог данных Notes и рекурсивно его подкаталоги, а так же все каталоги Directory Links (файлы с расширением .DIR в каталоге данных) и рекурсивно в их подкаталогах. Этот каталог может быть и на "сетевом" дисководе, если не имеется достаточно памяти на локальных дисках сервера.
· С консоли сервера дать команду Push, чтобы "затолкнуть" изменения из резервной копии СПЯ в активный СПЯ. Например, если резервная копия находится в каталоге h:\backup, команда может иметь вид:
Push Manufacturing h:\backup\SHARE1.NSF ,
Где Manufacturing
- имя сервера, и SHARE1.NSF - имя файла резервной копии СПЯ.
После завершения команды резервная копия больше не нужна и может быть удалена. Насколько это было возможно, вы уже восстановили данные в активном СПЯ.
Однако и после этого в активном СПЯ могли "восстановиться" не все тела сообщений - а в ПЯ соответственно остаться "повисшие" заголовки сообщений. Поскольку других вариантов уже нет, остается удалить такие "повисшие" заголовки из всех ПЯ. Для этого для каждого файла почты введите команду
Load Object Collect USERMAIL.NSF .
Эта команда "исследует" каждое сообщение в файле почты USERMAIL.NSF. Если заголовок сообщения найден в ПЯ пользователя, но соответствующее тело сообщения не найдено в СПЯ, заголовок сообщения удаляется из ПЯ. Однако учтите, что если на другом сервере имеется реплика этого ПЯ, то удаленные сообщения при репликации могут восстановиться вновь, поскольку функция Collect производит удаление "начисто", без создания "окурка".
Балансировка рабочей нагрузки членов кластера
Материал данного и последующих разделов предполагает знакомство с серверными задачами и компонентами, входящими в состав программного обеспечения сервера-члена кластера, что было рассмотрено в 3.2.19. Поэтому рекомендуем обратиться по этой ссылке, прежде чем продолжать чтение.
Администратор имеет возможность осуществлять балансировку рабочей нагрузки членов кластера. Для этого в файле NOTES.INI предусмотрены следующие переменные.
Server_Availability_Threshold = значение
Каждый член кластера регулярно вычисляет текущее значение "своего" индекса доступности
(availability index). Это целое число в диапазоне от 0 до 100, при вычислении которого использована информация о степени загрузки сервера на "последних" пяти 15-секундных интервалах времени. Значение 100 трактуется как "полная доступность" сервера, значение 0 - как "полная недоступность".
Узнать текущее значение индекса доступности сервера можно командой консоли Show Cluster.
> show cluster
Cluster name: IntTrustCluster, Server name: NotesSrv400/InterTrustCorp/SU
Server cluster probe timeout: 1 minute(s)
Server cluster probe count: 186
Server availability threshold: 0
Server availability index: 100 (state: AVAILABLE)
Cluster members (2)...
server: NotesSrv400/InterTrustCorp/SU, availability index: 100
server: InterTrust/InterTrustCorp/SU, availability index: 96
Переменная Server_Availability_Threshold задает пороговое значение индекса доступности сервера. Когда текущее значение индекса доступности становится ниже заданного переменной Server_Availability_Threshold значения, некоторые из очередных запросов пользователей Notes версий 4.х к этому члену кластера станут переназначаться другим членам кластера, имеющим в данное время более высокий индекс доступности. Для этого задача Cluster Manager модифицирует в своем кэше состояние сервера как BUSY ("занят"), а через короткое время это состояние становится известным другим членам кластера. В то же время маршрутизация почты и репликации (как внутрикластерные, так и "обычные") продолжают осуществляться этим сервером независимо его индекса доступности. Сервер, находящийся в состоянии BUSY, продолжает вычислять текущее значение индекса доступности. Как только оно становится выше порогового значения, сервер возвращается в нормальное состояние (AVAILABLE), а через короткое время это состояние становится известным другим членам кластера.
Допустимые значения для Server_Availability_Threshold лежат в диапазоне от 0 до 100. Значение по умолчанию - 0. Выбор Server_Availabililty_Threshold=100 "переводит" сервер в состояние BUSY, при этом любые запросы пользователей к этому серверу будут переназначаться "более доступному" члену кластера, если только это возможно. Если же перенаправление запроса невозможно, доступ будет предоставляться. Выбор Server_Availabililty_Threshold=0 "переводит" сервер "в полностью доступное состояние", при этом функция Load balancing заблокирована (событие load balance не возникает).
Итак, ваша первая задача по балансировке рабочей нагрузки членов кластера состоит в том, чтобы экспериментально подобрать для каждого сервера-члена кластера приемлемое значение порога индекса доступности, которое позволяет эффективно использовать ресурсы кластера и обеспечивает быстрое время ответа для пользователя.
Server_Restricted = значение
Позволяет ограничивать доступ к серверу:
сервер переходит в состояние RESTRICTED ("использование ограничено") и не принимает новых запросов на открытие баз данных, но продолжает обслуживать пользователей, которые уже открыли базы данных на этом сервере.
Значение по умолчанию - 0. Чтобы ограничивать доступ к серверу, обычно используют команду консоли Set Config "Server_Restricted=1". В результате в файл NOTES.INI сервера будет внесено Server_Restricted=1. Задача Cluster Manager, обнаружив это изменение, изменяет состояние данного сервера на RESTRICTED в "своем" кэше кластера. Когда сервер находится в состоянии RESTRICTED, новые запросы на обращение к его базам данных по возможности перенаправляются в реплики на других серверах-членах кластера. Информация о текущем состоянии этого сервера через очень непродолжительное время становится известна другим членам кластера, и они перестают перенаправлять запросы на этот сервер. Сервер находится в состоянии RESTRICTED до перезапуска или "сброса" состояния, что обычно выполняется командой консоли Set Config "Server_Restricted=0". Для того чтобы сервер после перезапуска сразу же входил в состояние RESTRICTED, следует использовать значение Server_Restricted=2.
Обратите внимание, что переменная Server_Restricted подобным образом интерпретируется и серверами, не являющимися членами кластера. Следовательно, этим можно пользоваться при остановке сервера: сначала ограничить доступ к серверу командой Set Config "Server_Restricted=1", не прерывая "разрушительным" образом работу пользователей с открытыми базами данных, а по завершении текущей работы пользователей остановить сервер.
Server_MaxUsers = значение
Позволяет ограничивать количество активных пользователей, одновременно имеющих доступ к серверу. Если текущее количество активных пользователей на сервере достигло этого порогового значения, сервер переходит в состояние MAXUSERS и перестает принимать новые запросы на открытие баз, но продолжает обслуживать пользователей, которые уже открыли базы данных на этом сервере.
Активный пользователь рассматривается как пользователь, имеющий активную сессию с сервером и открывший на сервере одну или более баз данных. Когда количество активных пользователей на сервере достигает значения, указанного в Server_MaxUsers, сервер переходит в состояние MAXUSERS. В этом состоянии сервер не будет создавать дополнительные сессий для пользователей. Пользователи Notes версий 4.х, пытающиеся обращаться к серверу в состоянии MAXUSERS, будут или перенаправлены к реплике запрошенной базы на другом сервере-члене кластера, или получат сообщение "Access to the server is restricted due to maximum number of users" или "Access to this server has been restricted by the administrator". Пользователи Notes версий 3.х получат немного обескураживающее сообщение "You are not authorized to use the server".
Внутрикластерный репликатор на сервере в состоянии MAXUSERS будет продолжать свою работу, и внутрикластерные репликаторы других серверов тоже будут продолжать "заталкивать изменения" на данный сервер.
Очевидно, ваша вторая задача по балансировке рабочей нагрузки членов кластера состоит в том, чтобы экспериментально подобрать для каждого сервера-члена приемлемое значение порога количества активных пользователей на сервере, которое позволяло бы эффективно использовать ресурсы кластера и обеспечивало быстрое время ответа для пользователя.
Обратите внимание, что переменная Server_MaxUsers подобным образом интерпретируется и серверами, не являющимися членами кластера.
База "Каталог баз на сервере"
Создание базы
В версиях 4.х база создается автоматически по шаблону Database Catalog (CATALOG.NTF) при первом запуске задачи CATALOG.
Обновление документов в базе
Содержимое базы обновляется серверной задачей CATALOG, которая по умолчанию стартует на сервере ежедневно в час ночи. Администратор также может выполнить оперативное обновление базы с консоли сервера командой LOAD CATALOG. Если требуется более частое регулярное обновление базы, можно создать в общей адресной книге документ Program для запуска задачи CATALOG по расписанию.
Виды
· Databases by Category - содержит названия серверов, пути и имена файлов баз и названия баз, категоризированные по "категориям баз" ("категории базы" задаются в поле Categories на закладке Design окна свойств базы).
· Databases by Manager - содержит названия серверов, пути и имена файлов баз, категоризированные по именам менеджеров баз.
· Databases by Replica ID - содержит названия серверов, пути и имена файлов и названия баз, категоризированные по ID реплики.
· Databases by Server - содержит пути и имена файлов баз и их названия, категоризированные по названиям серверов.
· Databases by Title - содержит названия серверов, ID реплик, пути и имена файлов баз, категоризированные по названиям баз.
· Network Connections - показывает соединения сервер-сервер, категоризированные по вызывающим серверам.
Реплики и ACL
Чтобы в каталоге присутствовала только информация о базах, расположенных на данном сервере, нужно предоставить этому серверу и его администратору доступ менеджера, а -Default- - доступ читателя.
Чтобы в каталоге присутствовала только информация о базах, расположенных на нескольких серверах, нужно на остальных серверах создать реплику этой базы с первого сервера и предоставить всем серверам и их администраторам доступ менеджера, а -Default- - доступ читателя.
Чтобы в каталоге присутствовала информация о базах на всех серверах домена, нужно на всех серверах иметь одну реплику этой базы и предоставить группам LocalDomainServers (серверы домена) и Administrators (администраторы серверов домена) доступ менеджера, а -Default- - доступ читателя.
Можно иметь в каталоге информацию о базах в разных доменах организации, обеспечив присутствие на всех серверах одной реплики базы CATALOG.NSF
и предоставив группам LocalDomainServers (серверы домена), OtherDomainServers (серверы других доменов организации) и всем администраторам серверов доступ менеджера, а -Default- - доступ читателя.
База "Общая адресная книга"
Пользователь использует персональную адресную книгу как "записную книжку" для своих адресов (фирм, пользователей и групп), в том числе и тех, которых нет в общей адресной книге (документы Company, People, Group), описания соединений станции с серверами (документ Server Connection), хранения описаний своих возможных местоположений (документ Location), а также для хранения своих взаимных сертификатов (документ CrossCertificate) и информации о сертификаторах домена (документ Server\Certifier).
Вспомним формы из персональной адресной книги.
· Person
- информация о пользователе. Прежде всего представляют интерес полный почтовый адрес и сертифицированный публичный ключ, который необходим для шифрования почты, отправляемой этому пользователю.
· Group
- информация о группе: тип группы и ее состав. Обратите внимание, что при репликациях между станцией и сервером станция получает информацию о составе группы из персональной адресной книги.
· Location
- информация о возможном местоположении: название местоположения, тип местоположения, временная зона, почтовый сервер и сервер-посредник, порты станции, используемые в этом местоположении, информация о настройках почты и Internet-броузинга, расписание репликаций "станция-сервер".
· Server Connection
- информация о соединении станции с сервером: тип соединения, имя сервера, порт, используемый станцией для соединения, местоположение, в котором используется это соединение. Возможны следующие типы соединений: Local Area Network - по локальной сети, Dialup Modem - "удаленное" (с использованием модема), Passthru Server
- через сервер-посредник, Remote LAN Service
- инициализация установления соединения внешним сервисом (например, Microsoft RAS) между станцией и удаленной локальной сетью и затем работа с сервером Notes, находящемся
в удаленной локальной сети, по сетевому протоколу, поддерживаемому этим соединением.
В версии 4.5 появился еще один тип соединения: Hunt Group. Типичная ситуация, в которой применяется такое соединение, приведена на Рис. 4.1. Здесь любая из станций Notes устанавливает соединение с сервером-посредником, "набирая" один и тот же "внешний" телефонный номер. Автоматическая телефонная станция, на которую приходит входящий вызов, переключает его на первый свободный внутренний телефонный номер, тем самым "соединяя" станцию Notes с каким-то из серверов-посредников. Каждый из серверов-посредников по локальной сети предоставляет доступ к серверу назначения. Станции Notes "безразлично", какой из серверов-посредников будет использован для доступа к серверу назначения. В настройках станции все это описывается парой документов Server Connection. Первый, типа Passthru Server, содержит в поле Destination server name: имя сервера назначения, а в поле Passthru server name or hunt group name: - название hunt-группы. Второй, типа Hunt Group, содержит название hunt-группы и внешний телефонный номер. Единственное "предназначение" названия hunt-группы - логически "связать" оба документа. Станция Notes, устанавливая соединение с сервером назначения, в первую очередь анализирует "первый" документ, а по содержащемуся в нем названию hunt-группы находит "связанный" с ним "второй" документ.
Рис. 4.1 Доступ к серверу назначения через любой из серверов-посредников
· Server\Certifier
- информация о сертификаторе. Чисто информационный документ, копируемый из общей адресной книги и позволяющий пользователю при выполнении запросов на ресертификацию узнать почтовый адрес сертификатора.
· CrossCertificate
- взаимный сертификат. Это документ, при наличии которого пользователь может получать доступ к серверам в других организациях. Его пользователь может создать сам ("от своего имени") или скопировать из общей адресной книги, если такой в ней есть и администратор даст пользователю к этому документу доступ не ниже читателя.
Общая адресная книга создается при установке первого сервера в домене и впоследствии реплицируется на дополнительные серверы. Она содержит информацию о серверах домена, зарегистрированных пользователях, сертификаторах, внешних и чужих доменах, группах, а также документы, описывающие соединения между серверами и программы, запускаемые на серверах.
Переходим к рассмотрению форм из общей адресной книги.
База "Протокол работы сервера/станции"
Виды
· Database Sizes - только на сервере - показывает информацию обо всех базах в порядке сортировки по их размеру.
· Database Usage - на сервере и станции - показывает сведения о работе с базами; категоризировано по базам и датам.
· Miscellaneous Events - на сервере показывает время начала и окончания "различных событий"; на станции показывает продолжительность использования модема. Категоризировано по серверам и датам.
· Phone Calls - на сервере дает информацию о модемных контактах, которые сервер произвел или на которые ответил (обслужил внешний вызов); на станции показывает вызовы по модему, включая возникшие проблемы, как то ошибки CRC и повторные передачи.
· Replication Events - на сервере показывает все репликации между серверами, включая информацию о том, когда происходила репликация, как долго она выполнялась и какой сервер инициировал вызов. На станции показывает репликации, отсортированные по серверам, и список возникших при этом проблем, например проблемы со списком управления доступом.
· Sample Billing - только на сервере - показывает сеансы работы (сессии) пользователей и других серверов с этим сервером, с сортировкой по именам. Формат удобен для экспорта в электронные таблицы для предоставления отчетов руководству и "выписывания" счетов на оплату.
· Usage by Date - только на сервере - показывает сеансы работы (сессии) пользователей и других серверов с этим сервером. Содержит число и продолжительность сеансов, открытые в сеансах базы, продолжительность доступа к базам, количество транзакций и использование сети (сколько килобайт "прокачано"). Категоризировано по дате.
· Usage by User - только на сервере - как Usage by Date, но с категоризацией по пользователям.
База "Протокол сертификаций"
· имя пользователя, сервера или сертификатора
· тип лицензии
· дата сертификации и дата окончания срока действия сертификата.
Создание базы
Создайте на первом сервере в организации новую базу CERTLOG.NSF по шаблону Certification Log (CERTLOG.NTF).
Создание документов в базе
Документы автоматически создаются в расположенной на регистрационном сервере реплике базы CERTLOG.NSF при регистрации каждого нового пользователя, сервера или сертификатора оргединицы. Если же база отсутствует на регистрационном сервере, то при регистрации каждого нового пользователя, сервера или сертификатора оргединицы никакие документы в ней, естественно, не создаются.
Виды
· By Certifier Name - содержит имена сертификаторов, имена пользователей и серверов, тип лицензии (North American или International) и дату сертификации, категоризированные по имени сертификатора.
· By User Name - содержит имена пользователей и серверов, тип лицензии, дату сертификации и имя сертификатора, отсортированные по имени пользователя или сервера.
· By Expiration Date - содержит дату истечения срока действия сертификата, имя сертификатора, имя пользователя или сервера, отсортированные по дате истечения срока действия сертификата.
Реплики и ACL
На очередном сервере домена следует создавать реплику базы CERTLOG.NSF с первого сервера домена. В списке управления доступом (ACL) обычно сертификатору организации и серверам из группы LocalDomainServers дают доступ менеджера, сертификаторам оргединиц - доступ автора, а -Default- - нет доступа.
Безопасность СПЯ
СПЯ имеет ряд особенностей, связанных с защитой информации. Это гарантирует, что только пользователи, которые должны иметь доступ к сообщению, смогут получить к нему доступ.
· Для СПЯ применяется локальное шифрование, так что доступ к нему может иметь только ID сервера, на котором этот СПЯ был создан.
· Список управления доступом СПЯ установлен так, что только ID сервера и только как сервер имеет к нему доступ. Это означает, что пользователь (обычно, администратор сервера) не сможет использовать ID сервера, чтобы обратиться к СПЯ из оболочки рабочей станции. Никто не может даже добавить пиктограмму СПЯ в рабочее пространство станции.
· СПЯ не содержит видов, и ни один вид не может быть добавлен в него.
В СПЯ могут быть помещены любые сообщения, за исключением только зашифрованных (при их отправке была выбрана опция шифрования). Дело в том, что тело зашифрованного сообщения "уникально" - оно может быть прочитано только его получателем. Если шифрованное сообщение отправляется нескольким получателям, на самом деле каждому из получателей доставляется собственная "уникальная" копия. Поэтому просто не имеет смысла сохранять тела зашифрованных сообщений в СПЯ. Если пользователь потребует в документе Person шифровать всю его входящую почту, его входящая почта тоже не будет сохраняться в СПЯ.
Certifer - информация о сертификаторах домена
Документы формы Certifer содержат информацию о сертификаторах организации и оргединиц (лицах, имеющих ID сертификатора и сертифицирующих пользователей и серверы). Первый документ Certifer создается автоматически при создании первого сервера в первом домене организации. При создании сертификатов оргединиц для их владельцев также создается документ Certifer.
Рис. 4.28 Информация о сертификаторе
Что делать, если пользователь
Принципиально проблема неразрешима, и вопрос лишь в рациональных действиях по выходу из этой неприятной ситуации...
Следует предупреждать пользователя о необходимости делать копии его ID-файла перед внесением в него любых изменений и после этого. В некоторых случаях допустимо иметь архив ID-файлов пользователей. Один из вариантов организации такого архива рассматривается в 9.6. Если архив имеется, воспользуйтесь им. Однако это "не спасет" в случае, если пользователь создал ключ шифрования, использовал его для шифрования документов в базах, но более никому не передал. Подобное может случиться с зашифрованной почтой и зашифрованными локальными базами данных, если пользователь "успел" изменить публичный ключ.
Если же копии ID-файла нет, остается только вновь зарегистрировать пользователя под его прежним именем.
· Откройте документ Person этого пользователя в общей адресной книге, запомните местоположение почтового ящика, затем закройте и удалите документ Person.
· Зарегистрируйте пользователя заново под прежним именем, указав TEMP.nsf в качестве файла почтового ящика.
· Исправьте в новом документе Person местоположение почтового ящика с TEMP.nsf на прежнее.
· Проверьте, что под новым ID-файлом удается "войти" в почтовый ящик пользователя.
· Удалите TEMP.nsf и передайте пользователю новый ID-файл.
Что такое ID-файлы пользователя, сервера и сертификатора
Каждый сервер или пользователь Notes имеет свой ID-файл - ассоциированный с этим сервером или пользователем уникальный двоичный файл, обычно имеющий расширение .ID. Этот файл идентифицирует своего владельца в контактах с серверами, используется в процессах шифрования, создания и проверки "электронной подписи" и т.п..
ID-файл пользователя или сервера создается сертификатором (certifier). Сертификатор - лицо (обычно, ваш администратор), имеющее специальный ID-файл - ID сертификатора. ID-файл сертификатора используется при создании, сертификации и ресертификации ID-файлов пользователей и серверов.
При создании в ID-файл включаются:
· Имя владельца ID-файла, например Nikolay N. Iontsev/InterTrustCorp/SU.
· Вид лицензии (International или North American). За пределы Северной Америки Notes
поставляется только с лицензиями вида International. Вид лицензии определяет длину используемых в алгоритмах шифрования ключей.
· Тип (Lotus Notes, Lotus Notes Desktop или Lotus Notes Mail) и номер лицензии
Notes.
· Один иерархический сертификат и, возможно, несколько неиерархических (простых) сертификатов. Сертификаты используются при установлении подлинности пользователя или сервера в первой фазе их контакта с сервером и при проверке "электронной подписи". Если в ID-файле пользователя нет необходимого сертификата, он не сможет "проверить электронную подпись" и обычно не получит доступа к серверу.
· Публичный ключ (public key). Публичный ключ используется при шифровании почты и локальных баз данных, а также в процессах создания и проверки "электронной подписи". Его копия заносится также в общую адресную книгу и становится доступной другим пользователям домена. Копия публичного ключа может передаваться пользователям из других доменов.
Однако имеется одна тонкость. Копия публичного ключа, которая хранится в поле с меткой Certified Public Key:
из адресной книги - "сертифицированный публичный ключ" - содержит публичный ключ, но не является в точности публичным ключом.
· Личный ключ (private key). Он имеется только в ID-файле и нигде более. Используется для шифрования почты и локальных баз данных, а также в процессах создания и проверки "электронной подписи".
· Пароль. Необходим для предотвращения использования этого ID-файла без ведома его владельца. В первой фазе контакта пользователя с сервером станция Notes обращается к используемому ID-файлу, запрашивает у пользователя пароль и сравнивает его с паролем, хранящимся в используемом ID-файле.
После создания в ID-файле могут быть изменены или добавлены:
· Пароль. ID-файл очень трудно "подделать" (автору такие факты не известны), однако его можно физически скопировать. Если ID-файл скопирован "злоумышленником", единственной защитой от его несанкционированного использования будет служить пароль. Изменение пароля выполняет сам владелец ID-файла. Администратор может устанавливать минимально-допустимую длину пароля для ID-файла, а с версий Notes 4.5 также может вынуждать пользователя регулярно менять пароль и запрещать доступ к серверу с использованием копии ID-файла с устаревшим паролем.
· Сертификаты. Может быть заменен иерархический сертификат и добавлены или удалены простые сертификаты. Простые сертификаты необходимы только для доступа к серверам с неиерархическими (простыми) именами. Однако использование серверов с простыми именами и, соответственно, простых сертификатов, является атавизмом Notes версий 1-2, и в настоящее время маловероятно.
· Ключи шифрования (encryption key's). Ключи шифрования используются для шифрования документов в базах данных. Они создаются пользователями и передаются другим пользователям, которые должны иметь доступ к документам, зашифрованным этими ключами.
· Имя владельца ID-файла может быть изменено сертификатором по запросу самого владельца ID-файла. Эта операция влечет также замену содержащихся в ID-файле сертификатов.
· Публичный ключ может быть изменен владельцем ID-файла и передан сертификатору для ресертификации ID-файла владельца (замены в нем сертификатов) и распространения (помещения в адресную книгу). Поскольку публичный ключ однозначно связан с личным ключом, эта операция на самом деле означает смену обоих ключей.
Для исследования или изменения содержимого вашего ID-файла используйте пункт меню File - Tools - User ID… . Вы получите диалоговое окно, в котором можно видеть имя владельца, тип ID, вид и тип лицензии, изменить пароль.
Рис. 8.1. Окно свойств ID пользователя - закладка Basics
Выбирая пиктограммы в левой части окна ("меняя закладки"), вы получите доступ к сертификатам, ключам шифрования и различным операциям, которые можно выполнить с ID-файлом.
Отметим понятие "безопасная копия" (safe copy) ID-файла. Это создаваемый из "настоящего" ID-файла "кнопкой" Create Safe Copy (на закладке More Options) файл, не содержащий личного ключа и ключей шифрования владельца. Невозможно работать на станции, используя "безопасную копию" вместо "настоящего" ID-файла. Обычно "безопасная копия" ID-файла создается для передачи сертификатору. Сертификатор использует ее при ресертификации ID-файла, создании простого сертификата или выпуске взаимного сертификата. В случае ресертификации или создания простого сертификата этот сертификат помещается в "безопасную копию", затем "безопасную копию" возвращают владельцу, а последний "кнопкой" Merge A Copy "заменяет" иерархический сертификат в своем "настоящем" ID-файле или "добавляет" в "настоящий" ID-файл новый простой сертификат.
Рис. 8.2. Окно свойств ID пользователя - информация о сертификатах
Рис. 8.3. Окно свойств ID пользователя - возможные операции
ID-файл сервера идентифицирует сервер в контактах сервер-сервер и сервер-станция. Он создается при установке сервера Notes и непосредственно расположен в каталоге программ Notes на сервере. Содержит те же компоненты (обычно, кроме пароля), что и ID-файл пользователя. Различие лишь в том, что при создании ID-файла сервера информация о нем была занесена в документ Server в Адресной книге, а не в документ Person, как при регистрации нового пользователя.
ID-файл сертификатора (CERT.ID) идентифицирует сертификатора организации. Он создается в процессе установки первого сервера Notes в организации. Правда, впоследствии может быть создан и другой ID-файл сертификатора организации. Сертификатор (обычно, администратор) использует ID-файл сертификатора при регистрации новых пользователей и серверов (добавление сертификата в их ID-файлы), ресертификации пользователей и серверов (замена сертификатов в их ID-файлах) и выпуске взаимных сертификатов. Кроме того, ID-файл сертификатора также используется при создании древовидного набора ID-файлов для сертификаторов оргединиц в организации. Несмотря на то, что ID-файл сертификатора имеет в основном те же компоненты, что и ID-файлы пользователя и сервера, имеются и отличия. В частности, сертификатор не может работать под ID-файлом сертификатора (с иерархическим именем) как пользователь Notes - для этого у сертификатора имеется "обыкновенный пользовательский" ID-файл.
Что такое переключения (failover) и когда они происходят
Когда пользователь Notes версий 4.х пытается обратиться к члену кластера, который по каким-то причинам не доступен, происходит переключение (failover)
запроса пользователя на другой доступный сервер в кластере. Иными словами, запрос "переадресуется" на другой доступный сервер кластера. Только если такое переключение по какой-то причине не может быть осуществлено (например, ни на одном из доступных серверов кластера нет реплики запрошенной базы), пользователь получит сообщение наподобие "Server is not responding". Обратите внимание, что клиент Notes версий 3.х не поддерживает возможность переключения.
Уточним условия, при которых возникает переключение.
· При попытке открыть базу данных. Если пользователь пытается открывать базу данных на недоступном сервере, происходит переключение на сервер, имеющий реплику запрошенной базы. Пиктограмма реплики базы на новом сервере добавляется в верхнюю часть стека пиктограмм базы в рабочем пространстве или в доступное место на текущей закладке рабочего пространства, если в установках станции не выбрана опция "стекирования" пиктограмм реплик.
Если на сервере, на который выполняется переключение, имеется несколько реплик нужной базы, то из них всегда выбирается та реплика, которая имеет то же самое имя файла, включая путь, что и первоначально запрошенная. Например, пусть в кластере имеются три базы данных с разными именами файлов SALES.NSF, EAST.NSF и WEST.NSF, но с одинаковым идентификатором реплики. Например, базы EAST.NSF и WEST.NSF могут быть селективными репликами SALES.NSF (реплицируемые документы отбираются по формуле селективной репликации). Сервер True содержит все три базы. Сервер Royal
содержит только SALES.NSF. Сервер Navy содержит все три базы. Если пользователь пытается открывать базу EAST.NSF на сервере True, но этот сервер недоступен, происходит переключение на сервер Navy, на базу с именем файла EAST.NSF.
· При попытке выполнить репликацию между станцией и сервером. Когда пользователь инициирует репликацию локальной базы данных с базой данных на сервере-члене кластера, но этот сервер оказывается недоступным, происходит переключение на другой сервер кластера, имеющий соответствующую реплику.
· При попытке обратиться к почтовому серверу (Home/Mail server) пользователя. Почтовый сервер пользователя определен в локальной адресной книге в "текущем" документе Location и используется при поиске адресов или отправке исходящей почты. Существует много ситуаций, когда станция обращается к почтовому серверу, но не к почтовому ящику пользователя на нем. Если этот сервер оказывается недоступен, происходит переключение на другой доступный член кластера. Это событие отображается сообщением в строке состояния станции.
· При попытке открыть почтовый ящик пользователя. Местоположение почтового ящика пользователя определено в локальной адресной книге в "текущем" документе Location. Когда пользователь пытается открыть свой почтовый ящик (в том числе выбором Open Mail или Create Memo во всплывающем меню строки состояния или выбором Create-Mail-<форма> в основном меню), но почтовый сервер оказывается недоступен, происходит переключение на другой доступный член кластера, имеющий реплику почтового ящика пользователя. Пиктограмма этой реплики добавляется в верхнюю часть стека пиктограмм почтового ящика, а произошедшее событие отображается сообщением на строке состояния. "Новый" почтовый ящик используется до смены текущего местоположения пользователем или до выхода из программы станции Notes.
· При попытке задачи Mail Router передать почту. Если на нескольких серверах кластера имеются реплики почтового ящика пользователя, и пользователю было отправлено сообщение, но при доставке сообщения задача Mail Router потерпела неудачу при обращении к реплике на том сервере, который определен как почтовый в документе Person этого пользователя в общей адресной книге, происходит переключение на реплику на другом сервере кластера. Таким образом, пользователь может получать почту с серверов внутри кластера и от серверов Notes версий 4.х "снаружи кластера", даже если его почтовый сервер не функционирует. Обратите внимание, что серверы Notes версий 4.х "снаружи кластера" должны использовать тот же сетевой протокол, что используется внутри кластера, а также находиться в том же самом домене. Чтобы задача Mail Router пользовалась возможностью переключения, в файле NOTES.INI "несущего задачу" сервера Notes версии 4.х задают переменную MailClusterFailover=1. Обычно это делается централизованно для всех серверов версий 4.х в домене.
· При попытке обратиться к базе Web Navigator. Если пользователь, станция которого настроена на работу с серверной базой Web Navigator, пытается открыть страницу на Web-сервере, происходит обращение к серверу Notes, указанному для этих целей в поле InterNotes server в текущем документе Location. Если этот сервер недоступен, происходит переключение на другой сервер-член кластера, который тоже настроен как
InterNotes Server. Однако для этого требуются дополнительные настройки: базы WEB.NSF на серверах кластера должны быть репликами, но реплицировать между ними многочисленные документы-образы страниц не имеет смысла, для чего используется формула селективной репликации наподобие Form != "HTMLForm".
· В элементах дизайна баз. Когда используется метод OpenWithFailover класса NotesDatabase
из LotusScript или "команда" @Command ([FileOpenDatabase]).
Таким образом, администратор, правильно спланировав и реализовав размещение реплик наиболее часто используемых и "критических" баз на многих серверах кластера, гарантирует, что запросы пользователей на открытие баз не потерпят неудачу, даже если они исходно были "адресованы" к недоступному серверу. Переключение происходит обычно настолько быстро, что пользователь даже не замечает, что оно произошло.
Что такое сертификаты
Сертификат (обычно хранимый в ID-файле пользователя, сервера или сертификатора) содержит следующие составляющие:
· имя и публичный ключ выдавшего сертификат;
· дата-время выдачи и дата-время окончания срока действия сертификата;
· имя и публичный ключ пользователя или сервера, которому сертификат выдан;
· вид лицензии Notes.
На этом уровне подробности сертификат можно представлять себе в виде "бумажного документа" примерно следующего содержания.
Рис. 8.4 Интерпретация содержания сертификата
Сертификат подтверждает, что данное имя пользователя, сервера или сертификатора (предмет сертификата) "правильно ассоциировано" с его публичным ключом.
Сертификат "подписан" с использованием личного ключа выдавшего его сертификатора. Следовательно, "подпись под сертификатом" может быть проверена. Для проверки "подписи" необходим публичный ключ выдавшего сертификат сертификатора.
Ассоциация имени и публичного ключа, содержащаяся в сертификате, используется Notes для доказательства идентичности того, кто действует, и того, за кого он себя выдает, в двух случаях:
· Всякий раз, когда пользователь (или сервер) соединяется с сервером Notes. При этом выполняется процесс, называемый установлением подлинности (процедура аутентификации). Чтобы пользователь (или сервер) получил доступ к серверу, ID-файл устанавливающего соединение пользователя или сервера и ID-файл сервера, с которым устанавливается соединение, обычно должны иметь общий, т.е. выданный одним и тем же сертификатором, сертификат.
· Всякий раз, когда получена "подписанная" почта или проверяется "подпись под секцией документа". Когда почта или документ "подписываются", все сертификаты подписавшего их" пользователя копируются из его ID-файла непосредственно в документ. Чтобы получатель мог установить подлинность "подписавшего", "подписавший" и получатель обычно должны иметь общий сертификат.
Сертификаты бывают трех видов: неиерархические (простые), иерархические и взаимные.
Повторим, что в Notes могут использоваться неиерархические (простые) или иерархические имена для пользователей, серверов и сертификаторов. Неиерархические имена - наследие от Notes версий 1.х-2.x, вынужденно поддерживаемое и в Notes версий 3.х. Иерархические имена - нововведение Notes версий 3.x, ставшее стандартом в версиях 4.х. При использовании простых имен применяются простые сертификаты, при использовании иерархических имен - иерархические и взаимные сертификаты. В зависимости от используемой системы имен существенно различаются очень многие соглашения, понятия, возможности и процессы. Но, поскольку в настоящее время простые имена уже практически никем не применяются, мы уделим связанным с ними простым сертификатам ровно столько внимания, сколько это необходимо для лучшего понимания иерархических и взаимных сертификатов.
Configuration - управление значениями переменных в файлах NOTES.INI на серверах
Документ формы Configuration используется для управления значениями некоторых переменных в файлах NOTES.INI серверов домена.
Рис. 4.25 Пример документа Server Configuration
Поле Server name: может содержать или имя сервера, к которому относится данный документ, или символ "*", означающий, что документ распространяется на все серверы домена (списки недопустимы). По нажатию кнопки Set/Modify Parameters появляется диалоговое окно, в котором можно изменить значения уже использованных в документе переменных или добавить в документ новые переменные с необходимыми значениями.
Рис. 4.26 Окно по кнопке Set/Modify Parameters
Выбор имен переменных выполняется из списка в очередном диалоговом окне, "вызываемом" кнопкой
Рис. 4.27 Список имен стандартных переменных
Через непродолжительное время после появления документа в адресной книге (это может потребовать репликации) сервер обнаружит документ и выполнит в "своем" файле NOTES.INI и в своей виртуальной памяти предписанные документом изменения. Признаком того, что изменения выполнены, является появление на консоли сервера сообщения
Searching Server Configuration document(s) for parameters...
Connection - соединение между серверами
Документы формы Connection
используются для организации репликаций по расписанию и передачи почты между серверами. Для репликаций вы обычно должны создать только один документ Connection в одном направлении (например, если репликация происходит между серверами A и B, то только с сервера A на сервер B), поскольку при репликации информация обычно передается в обе стороны. Повторение документов в обеих направлениях (например, с сервера A на сервер B и с сервера B на сервер A) хотя и допустимо, но лишь усложнит составление общего расписания репликаций и обычно увеличит нагрузку на сеть. Для передачи почты документ Connection необходим только тогда, когда серверы расположены в разных поименованных локальных сетях Notes. Обычно документы Connection для передачи почты должны создаваться в двух направлениях (например, если почтой могут обмениваться серверы A и B, то один документ "отвечает" за передачу почты с A на B, а другой - с B на A, и при этом каждый документ "работает" только при наличии почты в этом направлении).
Типы соединений
В Notes версий 3.х имелись две формы документа Connection: Connection\Network для соединения по локальной сети и Connection\Remote для соединения с использованием модема. В версиях 4.х используется одна форма Conntection, однако в ней явно задается тип соединения (поле ключевых слов с меткой Connection Type:). Он может быть следующим.
· Local Area Network - серверы соединяются по локальной сети, вызывающий сервер (поля с метками Source server: и Source Domain:) использует выбранный поле с меткой Use the port(s): кнопкой Choose ports
сетевой порт для вызова сервера назначения (поля с метками Destination server: и Destination Domain:). Это не означает, что серверы должны находиться в физически одной и той же локальной сети, необходимо лишь свободное прохождение пакетов используемого портом протокола между серверами. Например, используя протокол TCP/IP, серверы, находящиеся на разных континентах, могут напрямую связываться между собой. При использовании протокола TCP/IP в поле с меткой Optional network address: следует указать IP-адрес компьютера, на котором находится вызываемый сервер (вместо IP-адреса можно задать DNS-имя или WINS-имя). При использовании других протоколов оставьте это поле пустым.
Рис. 4.2 Фрагмент документа Connection в случае соединения по локальной сети
Хотя форма "позволяет" в поле с меткой Use the port(s): указывать список сетевых портов (например, TCPIP и NETBOIS), из этого не следует, что если не удастся установить соединение по первому порту (TCPIP), то будет использоваться второй порт (NETBOIS). Наоборот, чтобы достичь перехода на "резервный" порт при отказе основного, необходимо создать несколько документов Connection, в каждом из которых выбран только один сетевой порт, причем для документа, использующего основной порт, выбрать в поле с меткой Usage priority: приоритет использования Normal, а для документов,
использующих резервные порты, выбрать приоритет использования Low.
· Dialup Modem - серверы связываются между собой с использованием модемов, для вызывающего сервера указан используемый COM-порт и телефонный номер вызываемого сервера (поле с меткой Destination phone number:). К этому же типу относится соединение COM-портов двух достаточно близко расположенных серверов нуль-модемным кабелем; номер телефона при этом не требуется. В специальных случаях (см. главу 5) может быть использован скрипт соединения, имя которого задается в поле с меткой Login script file name:. Такой скрипт может иметь до 4-х аргументов, указываемых в полях с меткой Login script arguments:. Обратите внимание, что при обычном модемном соединении никакой скрипт соединения не требуется, и соответственно не должен указываться в документе. Отметим, что если в поле Use the port(s):
указан список портов, для установления соединения используется первый свободный порт, а если в поле Destination phone number: указан список телефонных номеров, предпринимаются попытки "дозвона" по первому номеру, если был неуспех, то по второму номеру, и т.д.
Рис. 4.3 Фрагмент документа Connection в случае модемного соединения
· Passthru Server - используется в случае, когда серверы не могут связываться между собой напрямую по локальной сети или модему, однако имеется "третий" сервер, с которым может связаться вызывающий сервер, и который в свою очередь может связаться с вызываемым сервером. При этом "третий" сервер соответствующим образом настроен - он "не возражает против предоставления услуг по ретрансляции". В документе Connection указывается имя этого сервера-посредника (поле с меткой Use passthru server:) и имя сервера назначения (поля с метками Destination server: и Destination Domain:), который в свою очередь должен вызывать сервер-посредник.
Соединение типа Passthru Server выполняется за несколько этапов. Вначале вызывающий сервер пытается установить соединение с сервером-посредником. Если эти серверы не в одной поименованной сети, в адресной книге вызывающего сервера дополнительно необходим "обычный" документ Connection, в котором описано, каким образом выполняется соединение между этими серверами. Затем сервер-посредник пытается установить соединение с сервером назначения или очередным сервером-посредником в цепочке. И опять, если эти серверы не в одной поименованной сети, в адресной книге сервера-посредника должен присутствовать "обычный" документ Connection, в котором описано, каким образом выполняется соединение между этими серверами.
Так, в примере на Рис. 4.4 серверы из одного домена InterTrust/InterTrustCorp/SU и NotesSrv400/InterTrustCorp/SU находятся в одной поименованной сети, так что "дополнительный" документ Connection между этими серверами может отсутствовать. Однако серверы NotesSrv400/InterTrustCorp/SU
и 194.196.39.10/Srv/LotusEmea/Net в разных поименованных сетях, и в адресной книге присутствует документ Connection типа Local Area Network между этими серверами.
Рис. 4.4 Фрагмент документа Connection в случае соединения через сервер-ретранслятор
· Remote LAN Service - соединение с использованием внешнего (по отношению к Notes) сервиса удаленного доступа к локальной сети.
Территориально удаленные локальные сети могут быть связаны между собой постоянно с использованием программно-аппаратных средств, называемых мостами. В этом случае обеспечивается свободное прохождение сетевых пакетов через мост из одной локальной сети в другую, что "прозрачно" для Notes. Поэтому для соединения между серверами Notes, установленными в локальных сетях, которые "постоянно связанны" мостами, используется документ Connection типа Local Area Network.
В то же время имеются программные средства, позволяющие с использованием модемов, сетевого оборудования X.25 или ISDN осуществлять между территориально удаленными сетями соединения, обеспечивающие прохождение сетевых пакетов. Но это уже коммутируемые, т.е. устанавливаемые только по потребности, а не постоянные соединения. Одним (но не единственным) из таких программных средств является Microsoft Remote Access Service (Microsoft RAS). В одной из локальных сетей устанавливается сервер Microsoft Windows NT, а на нем сервис Microsoft RAS. Из другой локальной сети с этим сервером может связаться клиент Microsoft RAS (с компьютера под MS Window
3.11, MS Window 95, MS Windows NT). Microsoft RAS использует PPP или SLIP
в качестве протокола передачи сетевых пакетов по последовательным линиям связи. Поверх протокола PPP могут передаваться пакеты протоколов TCP/IP, NETBOIS, IPX/SPX, поверх протокола SLIP - TCP/IP. Клиент Microsoft RAS может применяться и для установления соединений с серверами поставщиков услуг Internet (Internet Service Providers, ISP).
Каждое возможное соединение клиента Microsoft RAS представлено в его списке соединений (Phonebook) отдельным описанием соединения (Phonebook entry). Описание соединения идентифицируется именем описания соединения (Entry name) и содержит сведения об используемом протоколе работы по последовательным линиям (PPP или SLIP), передаваемых поверх него сетевых протоколах, применяемых при установлении соединения скриптах, а также обычно дополнительные параметры:
имя устанавливающего соединение пользователя, его пароль, телефонный номер модема на вызываемом
сервере... Для установления соединения из клиента Microsoft RAS достаточно выбрать имя нужного описания соединения (Entry name) и нажать кнопку Dial. Или запустить из окна Command Prompt программу RASDIAL, указав ей параметром имя нужного описания соединения... Когда соединение установлено, во время его функционирования из одной локальной сети в другую "прозрачно" для Notes передаются пакеты соответствующих сетевых протоколов (например, TCP/IP).
Именно на такой случай соединения между локальными сетями предусмотрен документ Connection типа Remote LAN Service. Предполагается, что сетевой порт Use the LAN port(s): использует сетевой протокол, поддерживаемый клиентом Microsoft RAS. "Во исполнение документа Connection" сервер Notes сначала инициирует клиента Microsoft RAS на установление соединения. По сути дела, со стороны Notes это сводится к запуску входящей в состав клиента Microsoft RAS программы RASDIAL с параметрами имя_описания_соединения [имя_пользователя пароль /PHONE:телеф_номер]. Когда соединение установлено, Notes использует протокол порта Use the LAN port(s): для работы с сервером Notes из другой локальной сети. Разрыв такого соединения также инициируется Notes
по завершении выполняемых серверами работ. По сути дела, это сводится к запуску сервером Notes той же самой программы RASDIAL с параметрами имя_описания_соединения /DISCONNECT.
Завершим рассмотрение документа Connection типа Remote LAN Service. Выбор сервиса удаленного доступа к локальной сети выполняется в окне, вызываемом кнопкой с меткой Choose a Service Type. В окне, вызываемом кнопкой с меткой Modify Remote LAN Service Configuration, в поле с меткой Remote Connection Name: дают имя описания соединения из списка соединений Microsoft RAS (Entry name), а в следующих за ним полях - дополнительную информацию, которая дополняет или заменяет соответствующую информацию в описании соединения Microsoft RAS (Phonebook entry).
Рис. 4.5 Фрагмент документа Connection в случае соединения с использованием внешнего сервиса для удаленного доступа к локальной сети
На Рис. 4.6 - Рис. 4.10 дается пример настройки соединения средствами Microsoft RAS на платформе Windows NT 4.0 с сервером у поставщика услуг Internet.
Рис. 4.6 В окне клиента Microsoft RAS выбрано соединение с именем RINET
В поле Phone number preview: задан телефонный номер модемного пула на сервере у поставщика услуг Internet. В номере телефона "P" означает использование пульсового набора, а "9," - "выход на городскую ATC". Наличие кнопки Hang Up вместо кнопки Dial свидетельствует о том, что соединение в настоящий момент установлено.
Рис. 4.7 Описание соединения RINET, закладка Basic: заданы имя соединения, телефонный номер и используемый модем
В поле Entry name: указано имя описания соединения. На этой же закладке можно указать список телефонных номеров, которые могут использоваться для установления соединения, и список модемов, из числа установленных на компьютере и "отданных в распоряжение" Microsoft RAS, которыми может устанавливаться это соединение.
Рис. 4.8 Описание соединения RINET, закладка Server:
поверх протокола PPP функционирует сетевой протокол TCP/IP
В поле Dial-up server type: в качестве протокола работы по последовательным линиям выбран протокол PPP. По соединению передаются только пакеты сетевого протокола TCP/IP.
В окне, "вызываемом" кнопкой TCP/IP Settings, выбраны опции Server assigned IP address (IP-адрес назначается сервером поставщика услуг) и Use default gateway on remote network
(используется шлюз по умолчанию, находящийся у поставщика услуг) и даны IP-адреса DNS-серверов поставщика услуг.
Рис. 4.9 Описание соединения RINET, закладка Script: выбранный скрипт обеспечивает ввод имени пользователя
и его пароля без участия человека
После "дозвона" запускается стандартный скрипт Generic login. Иногда может потребоваться его незначительная корректировка. В частности, стандартный скрипт "ожидает" в строке OK=<match>"ogin:"
, пока сервер поставщика услуг передаст ему строку "Login:". Однако серверы поставщиков услуг, с которыми работал автор, в "этом месте" передавали строку "Username:". Исправление очевидно: OK=<match>"sername:" .
Рис. 4.10 Описание соединения RINET, закладка Security: способ аутентификации
· X.25 - соединение сервера с сервером по сети X.25. Такой тип соединения используется только в случае, когда на вызывающем и вызываемом серверах Notes установлены:
· карта X.25 фирмы Eicon Technology Corporation (Eicon HSI/PC 1MB версии 1.0 или старше, Eicon Dial-Port Network Adapter/PC 2MB версии 1.0 или старше, Eicon/S51 cadr),
· программное обеспечение Eicon OSI LAN Gateway версии от V3R1 для OS/2 или Connections for Windows NT версии V4R1 или WAN Services for Windows NT версии V3R4 для Windows NT, разработанное и поставляемое фирмой Eicon Technology Corporation и выполняющее функцию драйвера карты Eicon,
· программное обеспечение Lotus Notes Connect for X.25 Release 4 для OS/2 или Windows NT, разработанное фирмой Lotus и в настоящее время свободно доступное на Web-узле www.lotus.com.
Протокол X.25 широко используется в глобальных телекоммуникационных сетях (например, Sprint Net)
и обеспечивает быструю и безошибочную передачу больших объемов данных. Протокол X.25 обеспечивает формирование пакетов из передаваемых данных у отправителя, передачу пакетов по сети X.25 и извлечение данных из принятых пакетов у получателя. Реализует протокол X.25 сама карта X.25 фирмы Eicon, без привлечения ресурсов компьютера. Для этого на карте имеются собственные постоянное запоминающее устройство с программным обеспечением нескольких протоколов, включая X.25, процессор фирмы Motorola и не менее 1 Mб оперативной памяти.
Программное обеспечение Eicon OSI LAN Gateway, Connections for Windows NT или WAN Services for
Windows NT функционирует уже на компьютере, в котором установлена карта. Используя это программное обеспечение, можно настроить карту как виртуальное многоканальное устройство, способное поддерживать несколько одновременных сессий обмена данными, осуществляемых другими программами, выполняемыми на компьютере.
Одним из основных поставщиков аппаратного и программного обеспечения фирмы Eicon Technology Corporation (www.eicon.com, sales@eicon.com) в странах СНГ и Балтии является фирма Rase Communication USA Inc. (www.rcnet.ru, sales@rcmail.rcnet.ru, (095)198-9710, (095)198-9711).
Продукт Lotus Notes Connect for X.25 является многопортовым драйвером X.25
для Lotus Notes. Каждый порт Notes, если он активен, связан с определенными виртуальными каналами карты. Теоретически Lotus Notes Connect for X.25 допускает до 64 портов, но на практике их количество может быть ограничено производительностью карты.
В документе Connection типа X.25, кроме уже рассмотренного ранее, задается DTE-адрес вызываемого сервера (поле с меткой Remote DTE address:) и некоторые другие специфические параметры.
Рис. 4.11 Фрагмент документа Connection в случае соединения по сети X.25
· SNA - соединение для репликаций и передачи почты с использованием устройства SNA Gateway с серверами Notes на майнфреймах.
· SMTP - соединение для обмена почтой по протоколу SMTP (Internet), используется агентом передачи почты SMTP MTA (см. 7.11).
· X.400
- соединение для обмена почтой по протоколу X.400, используется агентом передачи почты X.400 MTA.
· cc:Mail
- соединение для обмена почтой с постофисом cc:Mail, используется агентом передачи почты cc:Mail MTA.
Итак, в документе Connection задают имена двух серверов, которые должны соединиться, и используемый для этого порт. В поле с меткой Use the Network port(s):
в принципе может быть задан список портов. В этом поле можно также "записать" символ "*", что будет означать использование первого порта из списка активных портов для текущего местоположения.
Приоритет соединения
Если для доступа к серверу Notes можно использовать нескольких портов, вы можете "вынуждать" Notes использовать определенный порт, установив в соответствующем этому порту документе Connection в поле с меткой Usage priority:
приоритет Normal, а в документах Connection, соответствующих остальным портам, приоритет Low.
Дело в том, что Notes всегда в первую очередь пытается установить соединение, используя документы Connection c приоритетом Normal. Если установить соединение "по этим документам" не удастся, Notes попытается выбрать порт для связи с сервером из других источников. Только если и последнее не приведет к успеху, Notes будет использовать документы Connection с приоритетом Low.
Например, если в одной и той же поименованной сети Notes
для доступа к серверу можно использовать порты SPX и TCPIP, но имеется только один документ Connection, в котором указан только порт TCPIP
с приоритетом Normal, то Notes в первую очередь должен использовать информацию из этого документа Connection. Notes проверит, определен ли и работоспособен ли порт TCPIP, и, если все хорошо, выберет этот порт. Но если в той же ситуации в этом документе Connection был указан приоритет Low, Notes для выбора порта в первую очередь должен будет использовать информацию из других источников, в частности, из документа Server, и только в последнюю очередь информацию из документа Connection. Допустим, если Notes обнаружит, что порт SPX определен в документе Server "ранее" порта TCPIP, то он выберет порт SPX. А информация из документа Connection (порт TCPIP с приоритетом Low) будет использована только в случае неудачной попытки установления соединения портом SPX.
Приоритеты в документах Connection для модемных соединений, соединений по X.25, посредством внешнего сервиса для подключения к удаленной локальной сети и passthru-соединений работают тем же самым образом.
Процесс установления соединения
Процесс установления соединения с сервером Notes происходит в принципе одинаково и для соединения, инициированного сервером, и для соединения, инициированного станцией. Соединение с сервером включает три фазы: первоначальный поиск пути на сервер, расширенный поиск пути на сервер (если первоначальный поиск не дал результата) и выполнение соединения с сервером. Найти "путь на сервер" означает определить порт, которым следует выполнять соединение, адрес первого сервера в цепочке, вызываемого по этому порту (поскольку возможен вызов через сервер-посредник) и имя непосредственно вызываемого сервера (если используется сервер-посредник). Если Notes определил, что для выполнения соединения необходим сервер-посредник, он выполняет соединение с сервером посредником, а не с вызываемым сервером.
В первой фазе - первоначальный поиск - Notes использует документы Connection из персональных адресных книг и документы из общих адресных книг, и на основе этой информации пытается найти путь на вызываемый сервер. При этом Notes последовательно выполняет перечисленные ниже "шаги". Если очередной шаг позволил определить путь, Notes не выполняет остающиеся шаги, а сразу же переходит к третьей фазе: созданию соединения с сервером.
· Шаг 1.1. На станции в окне Open Database или Trace Connection пользователь может задать имя вызываемого сервера в формате имя_порта!!!имя_сервера, например, LAN0!!!InterTrust/InterTrustCorp/SU. Такой формат задания вызываемого сервера явно указывает на порт станции, которым необходимо связаться с этим сервером. В документах Connection подобный формат указания вызываемого сервера не применяется. В этом случае Notes предпринимает попытку связаться с вызываемым сервером, используя именно указанный порт. Если попытка окажется неудачной, Notes не будет пытаться использовать другой порт станции для соединения с этим сервером.
· Шаг 1.2. Notes проверяет, не существует ли уже соединение с нужным сервером. Если существует, он будет использовать существующее соединение.
· Шаг 1.3. Notes использует для поиска пути только документы Connection из персональных (если соединение выполняется со станции) или общих (если соединение выполняется с сервера) адресных книг, имеющие приоритет Normal. Если соединение выполняется со станции, при отборе таких документов учитывается текущие местоположение и имя пользователя (см. поля с метками Only from Location(s): и Only for user: в документе Connection из персональной адресной книги).
Если такие документы имеются, Notes просматривает их в следующем порядке:
· Local area network
· Remote LAN service
· Dialup modem
· Passthru server
· Поиск группы серверов-посредников.
Например, имеется два документа Connection - один по локальной сети (типа Local area network), а другой с использованием Remote LAN service. Тогда Notes сначала пытается использовать документ типа Local area network для определения пути на вызываемый сервер. Только если ему не удается определить путь из этого документа, Notes использует документ типа Remote LAN service.
В документе Connection в качестве имени вызываемого сервера может быть указан шаблон (например, */Srv/LotusEmea/Net). Такой шаблон задает группу серверов с общим иерархическим именем. В фазе первоначального поиска Notes игнорирует документы, в которых в качестве имени вызываемого сервера указан шаблон. Если в одном документе Connection в качестве имени вызываемого сервера указан шаблон (например, */Srv/LotusEmea/Net), а в другом документе Connection указан конкретный сервер (например, NotesServer-36/Srv/LotusEmea/Net), Notes будет использовать "конкретный" документ Connection для определения пути.
Если имеется документ Connection типа Passthru server, то обычно должен также присутствовать документ Connection, который обеспечивает путь на passthru-сервер. Чтобы выполнить соединение с passthru-сервером, можно использовать любой тип документа Connection - Local area network, Remote LAN Service, Dialup modem, Passthru server или группа сераеров-посредников. При необходимости можно определять путь на сервер "с использованием цепочки" из нескольких passthru-серверов, но не более чем из девяти.
· Шаг 1.4. Notes пытается найти путь на вызываемый сервер, используя информацию из "постоянного кэша" ранее успешно выполненных соединений.
В процессе своей работы Notes сохраняет информацию о последних успешно им выполненных соединениях с серверами в "постоянном кэше". Для каждого успешно выполненного соединения запоминается имя сервера, порт, использованный для доступа к нему, и сетевой адрес сервера. Для станции эта информация хранится в соответствующем текущему местоположению документе Location из персональной адресной книги, для сервера - в документе Server из общей адресной книги (это поля-списки $SavedServers, $SavedPorts, $SavedAddresses, $SavedDate). Устаревшая информация автоматически удаляется из "постоянного кэша" через 30 дней.
В фазе расширенного поиска Notes использует документы Connection из персональных адресных книг и документы из общих адресных книг, и на основе этой информации пытается найти путь на вызываемый сервер. При этом Notes
последовательно выполняет перечисленные ниже "шаги". Если очередной шаг позволил определить путь, Notes не выполняет остающиеся шаги, а сразу же переходит к последней фазе: созданию соединения с сервером.
· Шаг 2.1. Notes использует для поиска пути только документы Connection из персональных (если соединение выполняется со станции) или общих (если соединение выполняется с сервера) адресных книг, имеющие приоритет Normal и, в отличие от третьего шага в фазе первоначального поиска, включая и документы, в которых в качестве вызываемого сервера указан шаблон. Если соединение выполняется со станции, при отборе таких документов учитывается текущие местоположение и имя пользователя.
· Шаг 2.2. Если вы пытаетесь выполнить соединение со станции, Notes посылает запрос на Home-сервер, используя для этого последовательно каждый доступный порт станции, пока не найдет путь на этот сервер. Home-сервер хранит в своей виртуальной памяти информацию о серверах из общей адресной книги и использует эту информацию, чтобы найти путь на указанный в запросе сервер. Если Home-сервер не отвечает ни по одному из доступных портов, Notes посылают запрос на вторичный сервер имен (secondary name server). Если и вторичный сервер имен не отвечает, Notes пробует соединяться непосредственно с вызываемым сервером по локальной сети, используя в качестве адреса сервера его имя (многие сетевые протоколы позволяют определять адрес сервера по его имени, а драйверы протоколов Notes используют эту возможность, если она доступна). В общем, выполняемые в данном шаге запросы могут занять относительно значительное время.
Если же соединение выполняется с сервера, Notes сразу используют сохраненную в памяти этого сервера информацию из общей адресной книги (используется информация из документов Server), чтобы определить путь на вызываемый сервер. Обратите внимание, что если вы пытаетесь выполнить соединение со станции администратора, работающей под ID сервера, должен функционировать и сервер - иначе "сохраненная в памяти этого сервера информация из общей адресной книги" попросту недоступна. Если общая адресная книга не содержит информацию относительно вызываемого сервера, Notes пробует соединиться непосредственно с этим сервером по локальной сети, используя в качестве адреса сервера его имя, как это упоминалось выше. Поскольку в данном шаге отсутствуют запросы к серверам имен, шаг выполняется относительно быстро.
· Шаг 2.3. Notes использует документы Connection как приоритета Low, так и приоритета Normal, и, вместе с запросами к серверу имен, повторяет шаг 2.
Таким образом, документы Connection приоритета Low не используются, пока Notes пытается найти сервер, используя документы Connection приоритета Normal и выполняя прямые соединения. Notes станет использовать "низкоприоритетные" документы Connection только тогда, когда сервер не удается обнаружить в локальной сети.
· Шаг 2.4. Станция Notes пытается использовать сервер-посредник по умолчанию (см. поле Default passthry server в документе Location), чтобы выполнить соединение.
Если станция имеет passthru-сервер по умолчанию для текущего местоположения, Notes пытается найти путь на этот passthru-сервер, используя шаги от 1 до 3. Если для станции не указан passthru-сервер по умолчанию или если Notes не может найти путь на него, но станция в данный момент времени имеет модемное соединение с сервером, Notes попытается использовать сервер, с которым в настоящее время имеется соединение, как passthru-сервер.
· Шаг 2.5. Если Notes все еще не может найти путь на вызываемый сервер, выдается сообщение о невозможности соединиться.
Если Notes находит путь, то начинается третья фаза, в ходе которой выполняется соединение вызывавшего сервера или станции с вызываемым сервером. Если используется passthru-сервер, Notes соединяется с ним и передает ему запрос на соединение с вызываемым сервером, а уже на сервере-посреднике лежит задача по установлению соединения с вызываемым сервером или, в случае цепочки passthru-серверов, с очередным passthru-сервером.
На станции можно получить подробную информацию о том, как Notes пытается выполнить соединение. Для этого выберите File - Tools - User Preferences, затем закладку Ports и далее нажмите кнопку Trace Connection. В окне Trace Connection введите или выберите из списка имя сервера, с которым следует соединяться, и нажмите кнопку Trace. Изменять количество выводимой информации можно во всплывающем списке Log options.
Рис. 4.12 Трассировка соединения со станции с сервером DarkStar через сервер-посредник InterTrust
Ниже приведена трассировочная информация, полученная в окне на Рис. 4.12. Вначале станция, согласно имеющемуся в персональной адресной книге документу Connection типа Passthry, "узнает", что с сервером DarkStar необходимо соединяться через сервер InterTrust. Начинается поиск пути на сервер InterTrust. В персональной адресной книге имеется несколько документов Connection на сервер InterTrust
, но только один из них, использующий порт TCPIP, имеет приоритет Normal, а остальные - приоритет Low. Станция успешно соединяется с сервером InterTrust и передает ему запрос на соединение с сервером DarkStar. В общей адресной книге имеется документ Connection типа Dialup modem на сервер DarkStar, причем в нем указаны два порта COM3 и COM4. Поскольку порт COM3 в данный момент занят, для соединения с DarkStar
используется порт COM4.
Determining path to server DarkStar/SunFire
Checking normal priority connection records only...
Passthru connection record found for DarkStar/SunFire via InterTrust/InterTrustCorp/SU
Searching for path to InterTrust/InterTrustCorp/SU
Local network connection record found for InterTrust/InterTrustCorp/SU
Pass through InterTrust/InterTrustCorp/SU to connect to DarkStar/SunFire
Connecting to InterTrust/InterTrustCorp/SU over TCPIP
Using address '194.220.151.111' on TCPIP
Connected to InterTrust/InterTrustCorp/SU
Authenticating with InterTrust/InterTrustCorp/SU
Asking server for connection to DarkStar/SunFire
Port to be used on passthru server is COM4
On passthru server, connect to DarkStar/SunFire
Connected to DarkStar/SunFire
Connected to server DarkStar/SunFire
Кроме того, подобную информацию можно получить, просматривая документы из вида Miscellaneous Events в базе LOG.NSF.
Что и когда выполняется по соединению
По соединению могут выполняться репликации баз данных или (и) передача почты. Что именно выполняется, выбирается в поле с меткой Tasks:. Соединение, если оно разрешено (в поле Schedule: выбрано ENABLED), должно выполняться "в соответствии с расписанием": по заданным дням (Days of week:) на заданном временном интервале (Call at times:) с определенным интервалом повторения (Repeat interval of:). Если соединение предназначено для репликаций, сервер "будет стремиться соблюдать расписание", исключая разве что случаи, когда ему не удается установить соединение. Если соединение предназначено только для передачи почты, оно будет соблюдаться только при наличии "неинтенсивного" потока почты среднего приоритета.
Рис. 4.13 Расписание выполнения соединений и задачи, выполняемые по соединению
К вопросу передачи почты имеют отношение два поля. Значение в поле Route at once if:
касается только передачи почты среднего приоритета. Такая почта передается по расписанию, если в очереди на отправку на сервер назначения имеется меньше заданного предельного количества сообщений. Если же "предел" достигнут, немедленно, без учета расписания, предпринимается попытка передать почту. Целое число (от 1 до 10) в поле Routing cost: определяет "стоимость соединения" и влияет на выбор маршрута, по которому доставляется почта. Подробно вопросы передачи почты рассматриваются в главе 7.
К вопросу выполнения репликаций относятся четыре поля. Поле Replicate databases of:, существовавшее и в Notes версий 3.х, позволяет ограничить множество баз, которые участвуют в репликациях, но поддерживается в Notes версий 4.х скорее всего ради сохранения совместимости... В Notes версий 4.х появилась возможность управлять типом репликации (Replication Type:),
осуществлять репликации не для всех имеющихся на серверах реплик баз, а только для конкретных баз или баз в каталогах, указанных в списке (Files/Directories to Replicate:), а так же указывать ограничивать время, отводимое на репликацию, тем самым "растягивая" репликацию больших объемов информации на несколько сеансов (Replication time limit:). Подробно вопросы репликаций рассматриваются в главе 6.
Cross Certificate - взаимный сертификат
Документы формы Cross Certificate содержат созданные в вашей организации взаимные сертификаты. Эти документы создаются автоматически в процессе взаимной сертификации (см. 8.6).
Взаимный сертификат - документ, обычно выдаваемый сертификатором (Issued By:) одной организации для сертификатора, пользователя или сервера (Issued To:) из другой организации. В Notes версий 4.х взаимные сертификаты могут также выдаваться "от лица" пользователя или сервера.
Рис. 4.29 Пример взаимного сертификата
Используются эти документы в момент, когда пользователь (сервер) из одной организации (сторона А) устанавливает соединение с сервером из другой организации (сторона В) - в ходе процесса установления подлинности (аутентификация). Если этот процесс завершится неуспешно, сторона А обычно не получит доступа к серверу на стороне В. А чтобы процесс завершился успешно, необходимо наличие двух документов Cross Certificate. В адресной книге сервера на стороне А должен иметься взаимный сертификат, выданный "от имени" этого сервера или его предка для пользователя (сервера) или их предка на стороне В. В адресной книге пользователя (сервера) на стороне В должен иметься взаимный сертификат, выданный "от имени" этого пользователя (сервера) или их предка для сервера или его предка на стороне A. Под предком здесь понимается любой сертификатор, который в дереве имен находится "выше" соответствующего пользователя (сервера).
Database Monitor - система наблюдения за базами данных
Система наблюдения за базами данных позволяет осуществлять контроль за частотой репликаций баз и изменениями в ACL баз.
Чтобы установить наблюдение за частотой репликаций баз, в базе Statistics & Events создают документы Replication Failure Monitor. В таком документе (см. Рис. 11.14) содержится следующее.
· Enabled/Disabled: - разрешено/запрещено использовать документ.
· On the server(s): - серверы, на которые распространяется действие документа: имя сервера, список имен серверов или "*" для всех серверов.
· If the database(s): - список имен файлов баз, за частотой репликаций которых устанавливается наблюдение. Символ "*" означает все базы.
· Has not replicated with server(s): - серверы, с которыми контролируются репликации: имя сервера, список имен серверов или "*" для всех серверов.
· Within the last: - интервал времени (в часах). Если в течение этого интервала не произойдет ни одной успешной репликации базы из списка If the database(s) между серверами из списка On the server(s) и Has not replicated with server(s), будет сгенерировано событие. Обратите внимание, что если репликация происходит, но при этом обнаруживается, что в реплицируемых базах не было никаких изменений, то считается, что она была неуспешна.
· Generate an event of severity: - степень серьезности генерируемого события типа Replication - один элемент из списка. Назначенная степень серьезности определяет, как задача Event будет обрабатывать это событие.
· And optionaly mail a notification to: - адрес лица, получающего почтой уведомление о нарушении максимально допустимой частоты репликаций баз. Обычно это администратор или менеджер базы. Параметр необязательный.
Например, согласно документу на Рис. 11.14 событие типа Replication
должно возникать, если хотя бы одна из баз Names.nsf или Catalog.nsf на любом сервере не реплицировались в течение 24 часов с любым другим сервером. В дополнение к событию администратор получает уведомление почтой.
Рис. 11.14 Пример документа для наблюдения за частотой репликаций баз
Чтобы установить наблюдение за изменениями, выполняемыми разными лицами в ACL баз, в базе Statistics & Events создают документы ACL Change Monitor.
Рис. 11.15 Пример документа для наблюдения за изменениями ACL базы
В документе ACL Change Monitor содержится следующее.
· Enabled/Disabled: - разрешено/запрещено использовать документ.
· Server name (s): - серверы, на которые распространяется действие документа: имя сервера, список имен серверов или "*" для всех серверов.
· Database name: - имя файла базы, за изменениями в ACL которой устанавливается наблюдение. Только одно значение на документ.
· Event severity: - степень серьезности генерируемого события типа Security - один элемент из списка. Назначенная степень серьезности определяет, как задача Event будет обрабатывать это событие.
· Person to notify via mail: - адрес лица, получающего почтой уведомление об изменениях в ACL базы. Обычно это администратор или менеджер базы. Параметр необязательный.
Например, согласно документу на Рис. 11.15 событие типа Security
должно возникать, если произошли изменения в ACL базы names.nsf на любом из серверов. В дополнение к событию администратор должен получать уведомление почтой. Когда такое событие действительно произойдет, администратор получит письмо следующего вида.
Рис. 11.16 Пример письма об изменении в ACL базы
Если задача Event протоколирует события типа Security степени серьезности Warnings(high), в базе протоколирования появится документ Event.
Рис. 11.17 Пример документа Event по событию, связанному с изменениями в ACL базы
Обратите внимание, что на документ Event, как и на документ Alarm, вы можете кнопкой Create Trouble Ticket создать связанный с ним новый документ - Event Trouble Ticket - "карточку аварийной ситуации". По смыслу документ Event Trouble Ticket является заданием администратору сервера, на котором возникло событие, предпринять действия по его анализу и обработке.
Directory Assistance
Если в вашей организации несколько доменов или ваш домен поддерживает активные связи с другими доменами, начиная с версии Notes 4.5 полезно использовать Directory Assistance. Это предоставит пользователям возможность выбрать имена из общих адресных книг других доменов, когда они адресуют почту, определяют списки управления доступом к базам (ACL) или заполняют поля типа Readers, Authors или Names
в документах. Когда пользователи отправляют почту получателям из других доменов, правильность указанных имен получателей будет предварительно автоматически проверяться по имеющимся в наличии адресным книгам других доменов.
Чтобы установить Directory Assistance, вы создаете базу данных "Главная адресная книга" (Master Address Book) по шаблону MAB45.NTF. В документах из главной адресной книги определяете правила именования, используемые в доменах. Это позволяет Notes быстро находить те адресные книги доменов, которые соответствуют имеющимся в имени старшим компонентам. Кроме того, в документах из главной адресной книги указываются один или более "стратегических" серверов, на которых имеются реплики адресных книг других доменов. Под словом "стратегический" просто понимается, что этот сервер наиболее быстро доступен вашим пользователям и функционирует постоянно, а следовательно, способен быстро и безотказно обслуживать возникающие запросы пользователей к репликам адресных книг других доменов.
Рис. 10.1 В виде из главной адресной книги содержатся правила для поиска адресных книг по старшим компонентам в адресе получателя письма
Рис. 10.2 Начало документа Directory Assistance - определены правила именования, используемые в домене
Рис. 10.3 Продолжение документа Directory Assistance - определено местоположение реплик адресных книг этого домена
После этого вы создаете реплику главной адресной книги на всех серверах только вашего или, если это необходимо, даже каждого домена.
Остается "сообщить" серверам, что теперь они "должны начать пользоваться" главной адресной книгой. Обычно это осуществляется с использованием задачи Administration Process. Откройте адресную книгу, выберите вид Server\Servers, "отметьте галочкой" документы Server для тех серверов, которые должны использовать главную адресную книгу и для которых имя файла (включая путь) реплики главной адресной книги одинаково. Выберите в меню Actions - Set Master Address Book Information. В появившемся окне введите имя файла главной адресной книги (включая путь, если она расположена в подкаталоге). Нажмите кнопку Ok. Если нужно, повторите эту операцию для других серверов, у которых реплика главной адресной книги имеет другое имя файла или расположена в другом подкаталоге.
В результате выполненных вами действий в базе Administration Requests будут созданы запросы на включение информации о местоположении главной адресной книги в документы Server. Эти запросы "достигнут репликациями" реплики адресной книги вашего домена на ее сервере администрирования. Задача Administration Process этого сервера внесет в документы Server в соответствующее поле необходимую информацию. "Измененные" документы Server "достигнут репликациями" остальных адресных книг вашего домена. После этого серверы вашего домена станут использовать главную адресную книгу.
Рис. 10.4 Поле Master address book name: в документе Server содержит путь и имя файла главной адресной книги
Отметим, что соответствующее изменение в документе Server можно проделать и "вручную". Однако использование задачи Administration Process
предохраняет от возникновения возможных репликационных конфликтов в адресной книге.
Теперь, когда пользователь адресует письмо получателю из другого домена, Notes "проверяет" введенное пользователем имя получателя перед отправкой письма. Чтобы сделать это, Notes сначала выполняет поиск имени получателя в адресной книге "своего" домена. Если имя там не найдено, Notes обращается к правилам именования в других доменах, выбирая их из реплики главной адресной книги на почтовом сервере отправителя. Это позволяет Notes выбрать другую адресную книгу для продолжения поиска. Если почтовый сервер пользователя не имеет ее реплики, он выдает удаленный поисковый запрос на сервер, имеющий нужную реплику.
Когда же пользователь при поиске имени выбирает адресную книгу другого домена, почтовый сервер пользователя обращается к "своей" реплике главной адресной книги, чтобы определить, где находится реплика адресной книги нужного домена. Если этой реплики нет на почтовом сервере пользователя, почтовый сервер выдает удаленный запрос на сервер, имеющий нужную реплику. Тот сервер передает список имен на станцию, сделавшую запрос, и затем список предъявляется пользователю.
Учтите, что возможности Directory Assistance доступны только тем пользователям, у которых в документе Location указано, что их почтовый ящик находится на сервере (а не локально на станции).
Добавление сервера в кластер и вывод его из кластера
Установка на сервер программного обеспечения для поддержки кластера сложности не вызывает - достаточно при установке сервера выбрать на закладке Advanced Services (Рис. 2.3) необходимые компоненты. Позвольте напомнить, что формально для использования программного обеспечения поддержки кластера должны приобретаться лицензии Lotus Domino Advanced Services.
Обычно добавление сервера в кластер инициируется из вида Server\ Servers в адресной книге "отметкой" соответствующего документа Server и нажатием кнопки Add to Cluster. В результате в базе данных ADMIN4.NSF создается запрос на включение сервера в кластер. Запрос репликациями "достигает" базы данных ADMIN4.NSF на сервере администрирования адресной книги. Его задача ADMINP вносит необходимые изменения в документ Server включаемого в кластер сервера (поля ClusterName и CIReplID). Изменения в документе Server достигают репликациями включаемого в кластер сервера. Сервер "обнаруживает" изменения в "своем" документе Server
и запускает задачи Cluster Administration Process и Cluster Manager. Эти задачи:
· добавляют имена задач CLDBDIR и CLREPL в переменную ServerTasks в файле NOTES.INI;
· создают базу CLDBDIR.NSF, если она не существует;
· запускают задачу CLDBDIR, если она еще не запущена;
· заполняют базу CLDBDIR.NSF
соответствующей информацией, если она была пуста;
· запускает задачу CLREPL, если она еще не запущена.
Вывод сервера из состава кластера обычно инициируется из вида Server\Clusters в адресной книге "отметкой" соответствующего документа Server и нажатием кнопки Remove from Cluster. В результате в базе данных ADMIN4.NSF создается запрос на вывод сервера из кластера. Запрос репликациями "достигает" базы данных ADMIN4.NSF
на сервере администрирования адресной книги. Его задача ADMINP "очищает" поля ClusterName и CIReplID
в документе Server выводимого из кластера сервера. Изменения в документе Server достигают репликациями выводимого из состава кластера сервера. Сервер "обнаруживает" изменения в "своем" документе Server и запускает задачу Cluster Administration Process. Эта задача:
· удаляет имена задач CLDBDIR и CLREPL из переменной ServerTasks в файле NOTES.INI;
· удаляет в базе CLDBDIR.NSF
документы, относящиеся к расположенным на этом сервере базам данных, и "реплицирует эти удаления" в реплики CLDBDIR.NSF
на других серверах-членах кластера;
· удаляет базу CLDBDIR.NSF;
· завершает задачи CLDBDIR, CLREPL и Cluster Manager.
Обратите внимание, что для "перемещения" сервера из одного кластера в другой не обязательно выводить его из состава одного кластера, а затем добавлять в другой. Достаточно выбрать в виде Server\Servers соответствующий документ Server, нажать кнопку Add to Cluster и выбрать имя кластера, в который перемещается сервер. Но реализация этого запроса осуществляется задачами ADMINP
и Cluster Administration Process в два этапа: вывод из состава одного кластера и добавление в состав другого кластера.
Документ User Setup Profile
При массовых установках станций иногда полезно заранее создать в общей адресной книге документы User Setup Profile, содержащие информацию о сервере-посреднике по умолчанию (имя и телефонный номер), доступных пользователям "удаленных серверах" (для каждого имя и телефонный номер) и InterNotes-сервере. После этого при регистрации пользователя можно будет выбрать необходимый для него User Setup Profile (см. Рис. 2.29). Тогда при установке станции в персональной адресной книге пользователя в документ Location будет автоматически внесена информация о сервере-посреднике по умолчанию и InterNet-сервере, а так же будут автоматически созданы соответствующие документы Connection типа Dial-up для подключения к "удаленным" серверам - согласно информации из выбранного документа User Setup Profile.
Для создания User Setup Profile откройте в общей адресной книге вид Setup Profiles и нажмите кнопку Add…
Рис. 2.38 Пример документа User Setup Profile из общей адресной книги (фрагмент)
Введите название профиля (поле с меткой Profile name:), название InterNotes-сервера (поле InterNotes server:), в группе
полей Default Passthru Server
имя сервера-посредника по умолчанию (поле Server name:) и его телефонный номер, а в группе Default Connections to Other Remote Servers - "поэлементный" список имен других доступных пользователю Dialup-серверов (поле Server Names) и их телефонных номеров (поле Phone Number). Учтите, что символ "запятая" в поле Phone Number
интерпретируется как разделитель элементов в списке, а не как "пауза при наборе номера". Сохраните документ User Setup Profile.
Документы, которыми конфигурируется SMTP MTA
Ниже рассматриваются 4 документа, применяемые для настройки агента SMTP MTA. По каждому документу поясняется назначение содержащихся в них полей.
Рис. 7.14 Взаимосвязи между документами, используемыми для настройки SMTP MTA
Рис. 7.15 Документ Foreign SMTP Domain
Документ Foreign SMTP Domain "утверждает", что почтовые сообщения, отправленные пользователями Notes по адресам, удовлетворяющим шаблону, заданному в поле Messages Adressed to: Internet Domain:, должны доставляться в домен, имя которого задано в поле Should be Routed to: Domain name:. Если в качестве шаблона адреса задано *.* ("что угодно, содержащее точку"), то любые почтовые сообщения, адресованные в Internet, будут по почтовой системе Notes доставляться в указанный в документе Foreign SMTP Domain домен. Если в качестве шаблона адреса задано что-то наподобие *.com, то почтовые сообщения, адресованные в домены Internet, имена которых оканчиваются на *.com, будут по почтовой системе Notes доставляться в указанный в документе Foreign SMTP Domain домен. Если в качестве шаблона адреса задано что-то наподобие acme.com, то только почтовые сообщения, адресованные в домен Internet с именем acme.com, будут по почтовой системе Notes доставляться в указанный в документе Foreign SMTP Domain домен. Поле Internet host: в настройках SMTP MTA не применяется, и его оставляют пустым.
Кроме того, в документе Foreign SMTP Domain присутствуют поля Allow mail only from domains: и Deny mail from domains:, которые могут содержать списки доменов Notes, из которых разрешено или запрещено отправлять почту в домен с именем в поле Should be Routed to: Domain name:.
Итак, в соответствии с документом Foreign SMTP Domain почтовая система Notes должна доставлять почту, адресованную в Internet, в домен с именем в поле Should be Routed to: Domain name:. Логика почтовой системы Notes требует, чтобы в адресной книге присутствовал хотя бы один документ Connection, в котором "сказано", что какой-то сервер Notes из данного домена "каким-то образом умеет соединяться" с каким-то сервером из домена с именем в поле Should be Routed to: Domain name:.
Альтернатива - указать в поле Optional network address:
или IP-адрес, или имя хоста или имя домена Internet. Если указывается IP-адрес, данный SMTP MTA для отправки почты всегда будет соединятся с компьютером с этим IP-адресом и передавать на него почту. При этом предполагается наличие на этом компьютере SMTP MTA (обычно не архитектуры Notes), функционирующего как промежуточный агент передачи почты. Если указано имя хоста, в дополнение к предыдущему SMTP MTA будет обращаться к серверу DNS для определения IP-адреса хоста с промежуточным агентом. Если указано имя домена Internet, тоже будет происходить обращение к серверу DNS, но в этом случае в разное время могут быть возвращены разные IP-адреса, поскольку домен Internet может быть определен на сервере DNS несколькими "записями MX", указывающими на разные почтовые серверы.
Обратите внимание, что "непустое" поле Optional network address: может быть практически использовано в ситуации, когда сервер Notes с установленным на нем агентом расположен в "закрытой внутрикорпоративной" сети, и может соединяться только с корпоративным почтовым сервером, который находится как в "закрытой" сети, так и в Internet. В простейшем случае этот почтовый сервер имеет два IP-адреса, принадлежит обеим сетям, но не выполняет роутинга пакетов между сетями.
Документ Connection "функционирует", когда в поле
Connection: выбрано Enabled. Значение в поле Routing cost - целое число в диапазоне от 1 до 10, интерпретируемое как "стоимость" данного соединения. Значение в этом поле будет использоваться при выборе маршрута "наименьшей стоимости" до сервера Notes, имеющего SMTP MTA, если в домене имеется несколько таких серверов.
Поля в группах Report Message Congestion и Report Messcage Congestion has Subsided в документации не описаны. Во-видимому, группу полей Report Message Congestion следует трактовать как количество сообщений соответствующего приоритета, ожидающих отправки, при котором фиксируется "состояние перегруженности" агента и администратору MTA высылается соответствующее сообщение. Соответственно группа полей Report Messcage Congestion has Subsided задает более низкие пороговые значения, при которых считается, что "состояние перегруженности спадает".
(или иной, указанный в поле Alias separator character:), определяют его алиас (псевдоним), содержащий только ASCII-символы. При преобразовании адресов Notes в адреса Internet вместо имени домена Notes будет подставляться его алиас, а при обратном преобразовании - вместо алиаса будет подставляться имя домена Notes.
· Internet domain suffix: - содержит имя домена Internet или список имен доменов Internet, "зарегистрированных" за вашей организацией (не более 32-х). Например: acme.com или inttrust.ru. Если за организацией не зарегистрировано имя домена Internet, укажите в поле хост-имя компьютера, на котором установлен SMTP MTA, например, inttrust.rinet.ru.
Для исходящей SMTP-почты SMTP MTA использует только первый элемент из этого поля в качестве "суффикса" адреса в поле From (от кого). Например, если вы поместили acme.com первым в списке суффиксов, вся исходящая SMTP-почта будет иметь в поле From суффикс acme.com, например, jjones@acme.com или jjones%Acme@acme.com.
SMTP MTA, принадлежащий данному глобальному домену, принимает входящую SMTP-почту с любыми суффиксами адресов в поле To (кому), перечисленными в поле Internet domain suffix:. Например, если вы указали в поле Internet domain suffix:
список acme.com, sales.acme.com и pubs.co.uk, будут приниматься все сообщения, адреса получателей которых имеют перечисленные суффиксы, например, jjones@acme.com, jsmit@sales.acme.com, mblue@pubs.co.uk.
Если в вашей организации имеется несколько доменов Internet, установлено несколько SMTP MTA, и требуется, чтобы каждый SMTP MTA принимал и отправлял почту только с одним суффиксом, создайте по одному документу Global Domain на каждый суффикс и "привяжите" к каждому документу Global Domain соответствующий MTA в документе Server.
· Local part formed from: - определяет, в какой форме имя отправителя включается в адрес в поле From для исходящей SMTP-почты. Возможные три варианта.
· Fullname
- полное иерархическое имя пользователя, например, John Jones/Sales/Acme.
· Common name
- общее имя пользователя, например, John Jones.
· Short name
- краткое имя пользователя, как задано в поле Short name:
его документа Person, например, jjones. В этом случае MTA должен иметь доступ к документу Person, а в поле Domain: этого документа должно быть указано правильное имя домена Notes.
Обратите внимание, что вы должны гарантировать уникальность имени отправителя. Уникальность автоматически будет обеспечена при выборе Fullname, тогда как при выборе Short name для обеспечения уникальности может потребоваться внести соответствующие корректировки в документы Person.
· Notes domain(s) included: - определяет, включается ли, и если да, то как, имя домена отправителя в адрес From для исходящей SMTP-почты. Это поле представляет особый интерес, когда пользователь из одного домена Notes должен иметь возможность отправить письмо в Internet через SMTP MTA, находящийся в другом домене Notes. Возможны три варианта.
· None - названия доменов, перечисленных в поле Notes domains and aliases:, не включаются в адрес From. Однако если отправляемое в Internet сообщение поступило из домена, названия которого нет в поле Notes domains and aliases:, имя домена будет включено в адрес From. Чтобы входящая из Internet почта могла доставляться в домены, перечисленные в поле Notes domains and aliases:, на сервере с SMTP MTA при этом варианте придется иметь реплики адресных книг этих доменов и перечислить их имена файлов в переменной Names в NOTES.INI.
· One - только одно название домена (обычно домена, "соседнего" домену, имеющему MTA), включаются в адрес From. В этом случае на сервере не нужно иметь реплики адресных книг других доменов - MTA передает входящее сообщение в имеющийся в адресе домен Notes, "предполагая", что этот домен "сам сумеет" доставить сообщение получателю.
· All (значение по умолчанию) - в адрес From включается полный путь через все промежуточные домены Notes. Этот вариант гарантирует, что MTA сможет вернуть ответ отправителю. Если вы выбираете All, вы можете не перечислять имена доменов Notes в поле Notes domains and aliases:, за исключением следующих случаев:
· в поле Outbound Mail Restriction:
выбрано Yes - тогда допустима только почта из доменов в поле Notes domains and aliases:;
· имена некоторых доменов содержат не ASCII-символы - поэтому вы должны определить для них алиасы.
· Notes domain position - имена доменов могут включаться в адрес From слева или справа от символа "@".
· Left of @ (значение по умолчанию) - например, john_jones%sales@acme.com. В этом случае можно выбрать в поле Notes domain separator: в качестве символа-разделителя имен доменов Notes или "%", или "точку".
· Right of @
- например, john_jones@sales.acme.com. В этом случае разделителем имен доменов Notes может быть только символ "точка".
Обратите внимание, что по умолчанию Notes заменяет каждый пробел в имени на символ подчеркивания - например, John Jones "становится" John_Jones. Переменная SMTP_Space_Repl_Char из файла NOTES.INI позволяет указать иной символ для замены пробела.
· Address format: - формат адреса в поле From. Возможны два варианта.
· Address Only
(значение по умолчанию) - только адрес в соответствии с выборами в рассмотренных выше полях. Например, если Internet domain suffix = acme.com, Local part formed from = Short Name, Notes domain(s) included
= None, Notes domain position = Left of "@" и Notes domain separator = %, для John Jones получится jjones@acme.com.
· Name and Address
- к адресу добавляется общее имя отправителя в формате "Common Name"<Address Only>. Например, "john jones"< jjones@acme.com>.
· Outbound mail restriction: - если выбрано Unrestricted (это значение по умолчанию), SMTP MTA будет отправлять в Internet почту из любого домена Notes, если же выбрано Restrict to global domain - только из доменов, указанных в поле Notes domains and aliases:. Обратите также внимание на возможность наличия подобных ограничений в документе Foreign SMTP Domain в полях Allow mail only from domains: и Deny mail from domains:. Ограничения из документа Foreign SMTP Domain действуют при доставке сообщения почтовой системой Notes
в базу SMTP.BOX. Ограничения из документа Global Domain действуют позже - при отправке сообщения из SMTP.BOX
в Internet. Получается, что отправляемое в Internet сообщение должно "последовательно пройти пару ворот", вводимых этими ограничениями.
Все указанные в поле Internet domain suffix:
имена хостов или доменов Internet (например, sales.acme.com и acme.com) должны быть определены на сервере DNS. Иначе сообщения, посланные из Internet в эти домены или на хосты, "не придут" на сервер Notes, на котором выполняется SMTP MTA. Обычно используют сервер DNS, находящийся у провайдера услуг Internet. Поэтому, чтобы изменить информацию на сервере DNS, приходится обратиться к провайдеру. Каждое из имен хостов должно "отображаться" на IP-адрес вашего сервера Notes;
это реализуется "записью A" (Host Address Record) в файле сервера DNS. Каждое из имен доменов Internet
должно "отображаться" на хост-имя вашего сервера Notes; это реализуется "записью MX" (Host Mail Exchanger Record) в файле сервера DNS. Записи MX позволяют ассоциировать домен Internet с одним или более хостов, на которых функционируют SMTP MTA. Например, одна запись MX связывает домен Internet
с хостом основного SMTP MTA, а другая запись MX связывает тот же самый домен Internet
с хостом "резервного" SMTP MTA. Целое число, имеющееся в записи MX
(Preference value), определяет порядок выбора хоста при доставке почты. Вначале делается попытка выбрать хост из записи MX с наименьшим preference value, если он не функционирует, то из записи MX со следующим в порядке возрастания preference value и т.д. "Просмотреть" информацию, имеющуюся в файле DNS, можно с помощью утилиты NSLOOKUP, которая входит в состав большинства реализаций протокола TCP/IP.
Пример 1. Имеется один домен Notes и один домен Internet - acme.com. В поле Internet Domain Suffix:
указано acme.com. Имеется два сервера Notes, на которых функционируют SMTP MTA, основной - хост-имя notesmain.acme.com, и резервный - хост-имя notesback.acme.com. Адреса отправителей и получателей SMTP-почты имеют суффикс acme.com. В этом случае в файле сервера DNS должны иметься "приблизительно" следующие записи.
1. Запись MX: acme.com MX 1 notesmain.acme.com
2. Запись MX: acme.com MX 2 notesback.acme.com
3. Запись A: notesmain.acme.com A 194.32.171.65
4. Запись A: notesback.acme.com A 194.32.171.112
Пример 2. Имеется один домен Notes и три домена Internet: acme.com, sales.acme.com, finance.acme.com. Все три имени доменов Internet перечислены в поле Internet Domain Suffix:. Есть два сервера Notes, имеющих SMTP MTA, основной - хост-имя notesmain.acme.com, и резервный - хост-имя notesback.acme.com. Адреса получателей SMTP-почты имеют суффикс acme.com, sales.acme.com или finance.acme.com, а отправителей - acme.com. В этом случае в файле сервера DNS должны иметься "приблизительно" следующие записи.
1. Запись MX: acme.com MX 1 notesmain.acme.com
2. Запись MX: acme.com MX 2 notesback.acme.com
3. Запись MX: sales.acme.com MX 1 notesmain.acme.com
4. Запись MX: sales.acme.com MX 2 notesback.acme.com
5. Запись MX: finance.acme.com MX 1 notesmain.acme.com
6. Запись MX: finance.acme.com MX 2 notesback.acme.com
7. Запись A: notesmain.acme.com A 194.32.171.65
8. Запись A: notesback.acme.com A 194.32.171.112
Рис. 7.18 Фрагмент документа Server, содержащий настройки SMTP MTA
Признаком того, что на сервере Notes функционирует SMTP MTA, является выбор в документе Server в расположенном в "самом начале документа" поле Routing tasks: значения SMTP Mail Routing наряду с Mail Routing. Если вы забудете это сделать, отправляемые в Internet сообщения не будут доставляться почтовой системой Notes до базы SMTP.BOX на сервере с SMTP MTA - "первый обнаруживший" их сервер Notes будет возвращать уведомление о недоставке с причиной "No route found to domain <Internet-домен получателя>
from server <имя сервера Notes>
via server INTERNETHOST. Check Server, Connection and Domain documents in Name & Address Book".
Приступим к рассмотрению полей из секции Internet Message Transfer Agent (SMTP MTA) в документе Server.
· Global Domain name: - в этом поле должно содержаться название глобального домена, которому принадлежит функционирующий на данном сервере Notes агент SMTP. Благодаря этой "связи" (по одинаковому названию в полях Global Domain name: документов Server и Global Domain) агент получает доступ к информации из документа Global Domain.
· Fully qualifed Internet host name: - хост-имя данного компьютера, например, intrust.rinet.ru. Это имя должно быть определено на сервере DNS, а вы всегда можете его получить по команде PING -а IP-адрес (MS Windows). Именно под этим именем данный SMTP-агент "представляется" другим SMTP-агентам, когда открывает с ними соединения. Это же имя будет фигурировать в заголовках передаваемого сообщения.
· MTA administrator: - имя пользователя (обычно администратора MTA) или имя группы (в формате Notes), которым SMTP MTA отправляет почтовые сообщения о происходящих на нем событиях, требующих вмешательства администратора. Например, о появлении "мертвой" почты или состоянии "перегруженности". Кроме того, SMTP MTA обычно получает достаточно много входящих сообщений, адресованных на имя Postmaster@... Для получения этих сообщений рекомендуется создать в адресной книге соответствующий документ Person, и указать в нем либо вновь созданный отдельный почтовый ящик, либо уже существующий почтовый ящик конкретного администратора MTA.
· Poll for new messages every: - это значение (в секундах, по умолчанию - 120 секунд) определяет частоту опроса конвертором исходящей почты базы SMTP.BOX на предмет наличия новых сообщений. Это же значение задает частоту опроса задачей Delivery Report Task очередей исходящих и входящих сообщений на предмет удаления уже доставленных или формирования сообщений о недоставке. Более короткий интервал опроса потребует отвлечения большего количества ресурсов компьютера. Более длинный интервал опроса увеличит задержку в отправке сообщений.
· MTA Work Path: - рабочий каталог, который был создан при установке SMTP MTA. В этом каталоге MTA сохраняет временные файлы, создаваемые для присоединенных файлов и OLE-объектов, содержащихся в теле сообщения. Проверьте, что указанный рабочий каталог существует.
· Log level
- степень подробности протоколирования работы SMTP MTA в базе данных LOG.NSF.
· Minimal
- протоколируются все обязательные сообщения о состоянии и сообщения о фатальных ошибках.
· Normal
(значение по умолчанию) - дополнительно к уровню Minimal протоколируются все предупреждающие сообщения.
· Informational
- дополнительно к уровню Normal протоколируются все информационные сообщения.
· Verbose
- дополнительно к уровню Informational протоколируются дополнительные сообщения, которые могут помочь при поиске неисправностей.
· Enable daily housekeeping: и Perform daily housekeeping at: - по умолчанию в поле Enable daily housekeeping:
выбрано Enabled, что означает, что SMTP
MTA ежедневно в момент времени, заданный в поле Perform daily housekeeping at:
(по умолчанию - 01:00), на короткий отрезок времени автоматически приостанавливает свою работу, выполняет уплотнение баз SMTP.BOX, SMTPIBWQ.NSF и SMTPOBWQ.NSF, и затем автоматически возобновляет работу. Выполняемое действие эквивалентно действию по команде консоли Tell SMTPMTA Compact. Если вы хотите запретить автоматическое выполнение "ежедневных регламентных работ", выберите в поле Enable daily housekeeping:
Domain - домен
В адресной книге версии 4.х имеется несколько типов документов формы Domain. Все они, однако, так или иначе оказывают влияние на процесс доставки почты.
Документы формы Domain типа Non-adjacent ("не-соседний домен") определяют, что почта из вашего домена, адресованная в указанный в этом документе домен, должна сначала отправляться в указанный в этом же документе "промежуточный" домен. Такие документы могут создаваться администратором, если ни один из серверов его домена не имеет соединения ни с каким из серверов домена получателя, однако имеется сервер, который может соединяться с некоторым сервером в "промежуточном" домене, а в свою очередь в "промежуточном" домене имеется либо сервер, способный соединяться с сервером из домена получателя, либо очередной документ Domain типа Non-adjacent, определяющий очередной "промежуточный домен".
Однако документы Domain типа Non-adjacent всего лишь скрывают от пользователя маршруты доставки почты. Имеющиеся в документе Domain типа Non-adjacent разрешения или запреты на доставку почты из доменов распространяются только на письма, в адресе которых явно не указан "промежуточный" домен, а не являются реальными ограничениями по доставке почты. Пользователь всегда может указать в адресе своего сообщения полный маршрут доставки вида
ПОЛУЧАТЕЛЬ @ДОМЕН_ПОЛУЧАТЕЛЯ @ПРОМЕЖУТОЧНЫЙ_ДОМЕН,
в результате чего его сообщение сначала будет доставлено из домена отправителя в ПРОМЕЖУТОЧНЫЙ_ДОМЕН, а из него в ДОМЕН_ПОЛУЧАТЕЛЯ.
Для введения реальных ограничений по доставке почты в версиях 4.х появился документ формы Domain типа Adjacent ("соседний домен"). Имеющиеся в документе Domain типа Adjacent разрешения или запреты на доставку почты проверяются для любых писем, маршрутизируемых через ваш домен в этот "соседний" домен.
Документы формы Domain типа Foreign определяют "чужие" (т. е. не архитектуры Lotus Notes) домены, подключенные к вашему домену (архитектуры Lotus Notes) через шлюзовой сервер. Шлюзовой сервер позволяет пользователям двух разнородных доменов обмениваться между собой почтой. Чаще всего шлюзовой сервер - программа, выполняющаяся на компьютере сервера Notes. С точки зрения пользователя Notes отправка сообщения пользователю из "чужого" домена выглядит так же, как и отправка сообщения пользователю Notes из другого домена - в адресе только следует указать нужное имя "чужого" домена. Серверная задача Mail
Router по информации из адресной книги узнает, что это сообщение адресовано в "чужой" домен, и потому доставит его в "шлюзовую" базу данных, указанную в соответствующем документе Domain типа Foreign. Шлюзовой сервер обнаружит сообщение в "шлюзовой" базе, перекодирует его в формат "чужого" домена и, как правило, передаст "чужой" системе электронной почты, которая и выполнит его доставку получателю.
Более подробно документы формы Domain рассматриваются в главе 7.4.
Домен
Домен - группа серверов, совместно использующих одну и ту же по содержанию базу данных "Общая адресная книга" - общую адресную книгу - на основе репликаций. Репликация - обмен изменениями между двумя копиями одной и той же базы, расположенными на разных серверах. Адресная книга создается на первом сервере домена при установке сервера и реплицируется с него на другие серверы домена. Изменения, вносимые в адресную книгу на одном из серверов домена, при репликациях автоматически (но не "мгновенно", а в соответствии с составленным администратором расписанием репликаций) распространяются на адресные книги других серверов домена.
В общей адресной книге содержится информация обо всех пользователях и серверах данного домена, всех возможных соединениях между серверами этого домена для выполнения репликаций и передачи почты, возможных соединениях серверов данного домена с некоторыми серверами из других доменов, и т.п. Иногда говорят, что "информация из адресной книги полностью задает конфигурацию домена", а "каждый из серверов домена полностью знает конфигурацию своего домена, но не знает конфигурации других доменов".
Домен никак не лимитируется физическим расположением серверов. Можно иметь один домен в одной организации, даже если ее многочисленные офисы разбросаны по всему миру. Напротив, можно иметь много доменов в одной крупной и расположенной территориально в одном месте организации.
Обычно в домене используют один ID сертификатора организации - одно дерево имен. Но в то же время в одном домене можно иметь и несколько деревьев имен - использовать несколько ID сертификаторов организации.
Рис. 1.7 Два домена, в первом три сервера, во втором два сервера
Иметь ли один домен или много доменов в одной организации? Общая рекомендация при использовании Notes версий 4.х - один домен для одной организации. Сравнить же оба подхода позволяет расположенная ниже таблица. Преимущества отмечены знаком "плюс", недостатки - знаком "минус".
| Один домен | Много доменов | ||
| +
Проще адресация | +
Меньшее время поиска адресата, поскольку адресная книга меньше | ||
| +
Проще управление | +
Больше децентрализации и анонимности - каждый домен сам управляет своей адресной книгой | ||
| +
Более быстрая передача почты внутри домена | +
Лучшее использование памяти сервера, поскольку адресная книга меньше | ||
| + Отсутствие проблем с шифрованием почты в организации (публичные ключи всех пользователей из адресной книги доступны всем в домене) | -
Пользователи должны указывать имя домена в адресах почтовых сообщений (если только серверы не поддерживают реплики адресных книг всех доменов, с которыми поддерживается связь) | ||
| -
Длительное время поиска по полным именам адресатов из-за больших размеров адресной книги | -
Труднее обслуживать, поскольку управление децентрализовано. Однако при поддержке на серверах реплик адресных книг других доменов централизованное обслуживание возможно | ||
| -
Проблемы центра имеют более разрушительное воздействие на всех | -
Более медленная передача почты | ||
| - Для шифрования почты в организации приходится или добавлять в адресную книгу документы Person пользователей из других доменов (поскольку нужны их публичные ключи), или поддерживать на сервере реплики адресных книг других доменов | |||
| - Доступны дополнительные возможности по разграничению передачи почты между доменами |
Как удобнее организовать работу в многодоменной среде? Возможны три подхода.
1. На каждом сервере только одна адресная книга. Пользователь при посылке почты должен указать имя домена, например:
Yuri Kornveits @ LOTUSINT
Nick V. Svischev/ipc-lan/su @ ipc-lan@LOTUSINT
Управление адресной книгой децентрализовано. Если потребуется внести изменения во все адресные книги, их придется выполнять по одному разу в каждом домене - а это может вызвать определенные трудности, особенно, если домены территориально удалены.
2. Каждый из серверов имеет свою адресную книгу и реплики (всех) адресных книг других доменов. Все эти адресные книги перечислены в файле NOTES.INI каждого сервера, например:
Names=NAMES,EASTNAME,WESTNAME
Подробнее переменная Names
рассматривается в 2.3.
Обычно пользователь при посылке почты выбирает сначала нужную адресную книгу, а в ней нужного пользователя. Кроме того, в поле адреса получателя почты пользователь может просто задать только составляющие имени получателя - в этом случае Notes осуществляют поиск адресата по всем доступным адресным книгам. Но следует учитывать, что адресные книги нескольких доменов могут использоваться Notes только для адресации почты. Во всех остальных ситуациях используется только адресная книга своего домена, указанная в списке Names= первой.
Имеется возможность вносить изменения во все адресные книги всех доменов из одной точки - с рабочей станции "Главного администратора", которому администраторы других доменов предоставили соответствующий доступ к адресным книгам своих доменов.
3. Данный подход возможен только при использовании Notes версий 4.5 и старше. Каждый из серверов имеет свою адресную книгу и реплику базы данных Master Address Book. Реплики (всех) адресных книг других доменов присутствуют только на некоторых серверах, "наиболее легко" доступных всем пользователям доменов.
В базе данных Master Address Book определяются используемые в доменах правила присвоения имен (чтобы поиск по имени осуществлялся быстрее) и ссылки на реплики адресных книг других доменов, которые в данном домене расположены обычно не на всех, а только на основных, наиболее легко доступных пользователям, серверах.
Обычно пользователь при отправке почты сначала выбирает нужную адресную книгу (из числа "упомянутых" в Master Address Book). При этом станция пользователя обращается к реплике выбранной адресной книги (ее местоположение указано в Master Address Book), получает от "несущего" ее сервера список имен и предъявляет список пользователю.
Более подробно данный подход рассматривается в 10.1.
Дополнительные возможности
1. Секции с управляемым доступом в форме
· Секция с управляемым доступом, созданная в форме, обеспечивает доступ на редактирование ко всем полям в ее пределах только для тех, кто явно или как член группы перечислен в поле определения доступа этой секции.
· Но значения полей определения доступа секций хранятся в документе незащищенным образом, а потому могут быть легко изменены многими. Поэтому секции с управляемым доступом не считают возможностью по обеспечению безопасности.
2. Пароль ID-файла пользователя
· Предотвращает неавторизованное использование ID-файла для доступа к базам данных.
· В версиях 4.х имеется возможность защиты ID-файла несколькими паролями (см. 9.6).
3. Port Encryption - шифрование на уровне порта
· Выбором опции "Encrypt Network Data" в окне User Preferens на закладке Ports на одном конце соединения вводится шифрование передаваемой через порт информации на обоих концах. Однако этот выбор используется редко, поскольку он значительно уменьшает скорость передачи данных по соединению из-за затрат на шифрование.
4. Очистка информации о пользователе
· Нажатием клавиши F5 пользователь предотвращает возможность несанкционированного использования его станции для доступа к серверу во время его отсутствия - приходится снова вводить пароль и проходить процедуру аутентификации.
· Окно User Preferens на закладке Basics так же позволяет пользователю задать "период бездействия", по истечении которого Notes автоматически закрывает доступ пользователя к серверу - доступ может быть возобновлен только после повторного ввода пароля.
5. Переменные из файла NOTES.INI на станции
· NoDesignMenu=1 устраняет на станции меню Design.
· NoExternalApps= 1 запрещает на станции возможности OLE, DDE, DIP, @Command, @DbLookup, @DbColumn, @MailSend, @DDExxx, запуск присоединенных файлов.
· NoMailMenu=1 устраняет на станции меню Mail.
6. Disable replication of this database
· Эта опция в окне репликационных установок базы запрещает реплицировать базу, даже если ее реплика имеется на другом сервере или станции.
7. Прочие свойства базы
· Базу можно запретить "вносить" в каталог баз (CATALOG.NSF) или "показывать" в окне Open Database, что уменьшит вероятность использования базы не информированными о ней пользователями.
· Для Notes версий 3.x свойство базы Hide the design of this database позволяет "скрыть" дизайн базы - а значит предотвратить его изменение. Эта установка сохранится и для всех копий и реплик, впоследствии выполненных с этой базы как оригинала. Для Notes версий 4.х аналогичного эффекта можно достичь заменой дизайна базы с выбором опции Hide formulas and LotusScript. После этого у базы данных любая информация о дизайне станет недоступна. В то же время база не потеряет возможности наследовать дизайн с "открытого", но недоступного всем пользователям дизайн-шаблона.
Рис. 9.4 Дизайн почтового ящика пользователя станет "скрытым"
Рис. 9.5 И информация о дизайне базы станет недоступна
Однако администратору следует относиться к этой возможности лишь как к одному из способов предотвратить попытки продвинутых пользователей изменять дизайн баз, но вовсе не как к способу защиты дизайна базы "на уровне интеллектуальной собственности". Продвинутый разработчик баз "снимает" такую защиту за несколько минут в три приема, не выходя при этом из оболочки станции Notes
(по крайней мере до версии 4.51 включительно это так). Не станем здесь пояснять, как это делается, чтобы не лишить администратора одного из приемов борьбы с попытками недостаточно квалифицированных пользователей изменять дизайн, нередко на деле приводящими к неработоспособности базы. Разработчики и администраторы, по неосторожности "потерявшие" оригинал с "открытым" дизайном, смогут узнать это у своих более опытных коллег или обратиться к автору.
Что же касается защиты дизайна базы "как интеллектуальной собственности", можно, во-первых, упомянуть утилиту LNHIDE (имеется в Lotus Notes Knowledge Base), а во-вторых, предложить наиболее актуальные фрагменты на языке LotusScript хранить в виде текстовых файлов, включаемых в дизайн с помощью директивы %Include.
8. Обеспечение безопасности сервера Notes
· Особое внимание должно быть обращено на физическую безопасность сервера. Никакие перечисленные выше "двери" не сработают, если опытный злоумышленник получит физический доступ к серверу. Сервер Notes должен находиться в закрытом от постороннего доступа помещении. Следует закрывать "консоль операционной системы" компьютера, несущего сервер Notes, если это возможно. Желательны меры по предотвращению возможности перезагрузки компьютера выключением питания...
· Команда консоли сервера Notes SET SECURE позволяет защитить консоль паролем.
· SET SECURE [новый пароль] устанавливает пароль для консоли сервера. Когда пароль установлен, команды LOAD, TELL, SET CONFIG недоступны и оболочка станции или API-программы не запускаются (кроме тех программ, которые запускаются автоматически согласно документу PROGRAM из адресной книги или переменной ServerTasks
в файле NOTES.INI). Для команд EXIT и QUIT требуется ввод пароля.
· SET SECURE [текущий пароль] открывает консоль. Если вы - администратор или, позвольте пошутить, опытный злоумышленник - забыли текущий пароль, удалите строку Server_Console_Password=<текущий пароль в зашифрованном виде> из файла NOTES.INI).
· SET SECURE [текущий пароль] [новый пароль] используют для смены пароля.
Доставка почты в не-соседний домен
Часто встречается ситуация, когда два домена Notes непосредственно не связаны друг с другом (то есть серверы в одном домене не имеют прямой связи с серверами из другого домена), однако каждый из этих доменов связан с некоторым третьим доменом. Например, на Рис. 7.9 домен Y имеет соединения с обоими доменами X и Z, но домены X и Z не имеют прямого соединения друг с другом (они "не-соседние").
Рис. 7.9 Здесь X и Z -
"не-соседние" домены, а Y - соединяющий их "промежуточный" домен
В принципе сообщение может доставляться через несколько доменов. Для этого достаточно указать в адресе полный путь между доменами. Например, сообщение с адресом Sally Jones@ Dom3@ Dom2@Dom1
"следует" через домен Dom1 в домен Dom2, а из него в домен Dom3, в котором и находится получатель Sally Jones. По мере передач сообщения из домена в домен всякий раз из адреса получателя как бы отбрасывается (точнее, помечается как использованное) крайнее правое имя домена. Процесс продолжается, пока справа от имени получателя не останется имен доменов. Однако в этом случае пользователям требуется знать связи между доменами...
Для доставки почты между не-соседними доменами вместо того, чтобы требовать от пользователей указания в адресе точной информации о маршруте доставки между доменами, можно создать в адресных книгах доменов документы формы Domain типа Non-adjacent Domain (не-соседний домен). Этот документ определяет домен, который должен использоваться в качестве промежуточного при доставке почты в не-соседний домен. Для доставки почты из домена X в домен Z в адресной книге домена X должен содержаться документ Non-adjacent Domain, определяющий, что почта, предназначенная для домена Z, должна передаваться через домен Y.
Рис. 7.10 Пример документа Non-adjacent Domain
Когда Router домена Х
имеет сообщение в домен Z, например, с адресом Sally Jones@Z, он будет передавать сообщение на сервер в домене Y. Сервер в домене Y
будет отправлять эту почту на тот сервер в домене Z, с которым у него имеется соединение. Кроме того, в поле с меткой Allow mail only from domains: можно указать список доменов, почту из которых, если в адресе явно не указан домен Y, разрешается доставлять в домен Z. В поле с меткой Deny mail only from domains: можно указать список доменов, почту из которых, если в адресе явно не указан домен Y, запрещается доставлять в домен Z. По умолчанию оба поля пусты, то есть ограничений нет.
Чтобы домен Z
также мог передавать почту в домен X без явного указания в адресе домена Y, в адресной книге домена Z должен содержаться документ Domain типа Non-adjacent Domain, определяющий, что почта, предназначенная для домена X, должна передаваться через домен Y.
Если бы в нашем примере в адресной книге домена X отсутствовал документ Non-adjacent Domain на домен Z, отправителю пришлось бы указать в адресе получателя полный путь, включающий все имена доменов, через которые должно передаваться сообщение. Например, пришлось бы указать Sally Jones@Z@Y, если домен получателя сообщения Sally Jones называется Z, а сообщение из домена отправителя сначала должно передаваться в домен Y, а из домена Y в домен Z.
Однако обратите внимание, что ограничения на передачу почты в документе Domain типа Non-adjacent Domain работают буквально следующим образом: если в адресе сообщения явно не указан промежуточный домен, и оно пришло из "разрешенного" домена, это сообщение передается в промежуточный домен. Если же если в адресе сообщения явно не указан промежуточный домен, но оно пришло из "запрещенного" домена, сообщение не передается в промежуточный домен. Тогда такое сообщение не может быть доставлено в домен назначения, поскольку текущий домен не имеет с ним прямого соединения, и в результате отправитель получит уведомление о недоставке. Но если отправитель из "запрещенного" домена явно укажет в адресе промежуточный домен, имеющиеся в документе Non-adjacent Domain ограничения на передачу почты "не сработают", и сообщение будет доставлено. Поэтому к документу Domain типа Non-adjacent Domain следует относиться только как к средству "скрывать" от пользователей промежуточные домены, но не как к средству защиты от пользователей из других доменов, пересылающих почту через ваш домен.
Для устранения этого недостатка в Notes версий 4.х появился документ Domain типа Adjacent Domain. Вы можете создать такие документы на все "окружающие ваш домен" соседние домены, и в каждом из них указать, из каких доменов разрешено или запрещено передавать почту в соседние домены через ваш домен.
Рис. 7.11 Пример документа Adjacent Domain
Так, приведенный документ Domain типа Adjacent Domain разрешает передавать в домен Y только почту, отправленную пользователями домена X, но не пользователями из других доменов.
Дверь Базы данных
1. Основным средством контроля доступа к базе данных является список управления доступом базы (ACL). Подробно ACL рассматривается в 9.2.
· Если пользователь или сервер указан в ACL как член более чем одной группы, ему предоставляется наивысший уровень доступа по содержащим его группам.
· Если пользователь или сервер указан в ACL индивидуально и как член группы, он получает свой индивидуальный уровень доступа (даже если он "ниже", чем групповой).
2. Directory Link's
Доступ к некоторым каталогам (и, следовательно, к содержащимся в них базам данных) может контролироваться посредством файлов Directory Link. Эти файлы должны располагаться в каталоге данных Notes и иметь расширение .DIR. Ниже дается пример файла DNOTES.DIR, который "предоставляет" доступ к каталогу, указанному в первой строке файла, только трем группам и одному пользователю, указанным в следующих строках файла. В результате все пользователи "видят" каталог DNOTES, но "войти" в него могут только те, для кого доступ разрешен (строки 2-5 в файле DNOTES.DIR).
d:\dirlinks\dnotes
Administrators
CN=Andre A. Linev/O=InterTrustCorp/C=SU (! в версиях 4.х)
Andre A. Linev/InterTrustCorp/SU (! в версиях 3.х)
LocalDomainServers
Students
Рис. 9.1 Все "видят" каталог, но не все могут получить доступ к содержащимся в нем базам
В Notes версий 4.5 стало возможным управление Directory Link's со станции администратора. Для получения "окна управления" выбирают в меню File-Tools-Server Administration, далее сервер, кнопку Servers и в меню кнопки Directories and Links.
Рис. 9.2 Окно для управления Directory Link's
Дверь Документы
1. Ограничение доступа к документу с использованием полей типа Readers
· Поля типа Readers - один из эффективных способов контроля за тем, кто может "видеть" документ в базе данных, расположенной на сервере. Поля типа Readers можно "узнать" при просмотре полей документа в окне свойств документа на закладке Fields: хотя тип поля Readers "показывается" как Text, его параметр Field Flags будет содержать SUMMARY READ-ACCESS NAMES.
· Документ, содержащий поля типа Readers, будет "виден" тем, кто явно или как член группы присутствует хотя бы в одном поле типа Readers
из документа. Кроме того, такой документ буден "виден" и тем, кто явно или как член группы присутствует хотя бы в одном поле типа Authors
из документа.
Доступ же пользователя к документу определяется его доступом к базе данных. Так, читатель базы, присутствующий в поле типа Readers документа, "видит" документ и может открыть его только в режиме чтения. Редактор базы, присутствующий в поле типа Readers документа, "видит" документ и может открыть его как в режиме чтения, так и в режиме редактирования. Однако, например, менеджер базы, отсутствующий в полях типа Readers документа, "не видит" этот документ и поэтому вообще не может его открыть.
· Поля типа Readers могут быть предусмотрены в форме разработчиком базы. Для этого используется или свойство формы Default Read access for documents created with this form, или в форме просто создаются собственные поля типа Readers. Когда по такой форме создается документ, в нем будут автоматически созданы предусмотренные поля типа Readers.
· Даже если в форме не были предусмотрены поля типа Readers, любой пользователь, способный перевести документ в режим редактирования, может "защитить документ от посторонних", воспользовавшись закладкой с изображением ключа в окне свойств документа. В результате в документе по сохранении появится поле $Readers, а его параметр Field Flags имеет значение SUMMARY READ-ACCESS.
Рис. 9.3 Ограничение доступа на чтение документа
· Документ, " скрытый от посторонних" хотя бы одним из этих способов, не может быть скопирован. Иными словами, если вы "не видите" документ в базе, расположенной на сервере, вы и не можете его скопировать "с сервера на локал". В том числе и когда делаете копию или реплику всей базы средствами Notes.
2. Ограничение доступа на редактирование документа
· Если пользователь или сервер имеет в ACL базы доступ автора, но не указан индивидуально или как член группы хотя бы в одном поле типа Authors этого документа, он не сможет редактировать такой документ в расположенной на сервере базе. Иными словами, Joe Smith/Acme, который имеет доступ автора к базе DISC.NSF, может редактировать только те документы, хотя бы в одном поле типа Authors которых содержится имя Joe Smith/Acme. Для имеющих к базе доступ редактора или выше поля типа Authors не запрещают редактировать документ.
· В версиях Notes 4.х непосредственно перед переводом документа в режим редактирования (события QueryOpen
или QueryModeChange) может быть определено, кто пытается это сделать, и в зависимости от этого документ может быть переведен или не переведен в режим редактирования.
Дверь Формы и виды
Зашита на уровне форм и видов создается разработчиком базы данных, а потому рассматривается здесь достаточно конспективно. Учтите, что перечисляемые ниже приемы имеют смысл только для баз, расположенных на сервере. Такая защита или перестанет функционировать, или может быть достаточно легко устранена лицом с опытом разработки баз, когда база будет скопирована с сервера локально. Да и в базе, расположенной на сервере, пользователь, имеющий доступ к документу из вида, всегда сможет получить информацию из его полей на закладке Fields из окна свойств документа...
1. Форма и ее свойства - кто может создать документ по этой форме.
· Свойство Who can create documents with this form
контролирует, кто может создавать документ по этой форме в базе, расположенной на сервере.
· Свойства Include in Create menu/Create-Other Dialog/Search Builder, Default database form, Anonymous Form, Available for Public Access Users также уточняют контекст, в котором может использоваться форма.
· Активизация объекта с помощью Auto Launch
позволяет "скрыть" используемую форму.
2. Форма - скрытые абзацы в форме
· Пользователь с доступом читателя к базе обычно "может видеть" в документе, открытом по форме, гораздо меньше, чем пользователь с доступом редактора в той же базе.
· В версиях 4.х отдельные области формы или целые субформы могут быть сделаны "видимыми" только для определенных пользователей и "невидимыми" для других.
3. Выбор формы при открытии документа
· В версиях 4.х непосредственно перед открытием документа (событие QueryOpen) может быть определено, кто пытается его открыть, и в зависимости от этого документ может быть открыт по необходимой форме или не открыт вовсе.
4. Виды
· Свойства May be used by (Read Access)
и
Available for Public Access Users контролирует, кто сможет открыть этот вид в базе, расположенной на сервере.
· Формула отбора документов вида и скрытые столбцы могут применяться дизайнером для исключения полей и документов из вида.
Дверь Поля
1. Шифрование полей
· Один из наиболее эффективных способов защиты документов в базах. Пользователь или сервер, имея возможность читать документ, не будет "видеть" содержимого зашифрованных полей в этом документе, если не имеет в своем ID-файле необходимого ключа шифрования. Шифрование полей в документах базы отличается от шифрования почты. Оба механизма шифрования рассматриваются в 9.4.
2. "User must have at least Editor access to update"
· Для того чтобы изменить поле с таким свойством, пользователь должен иметь к базе данных доступ не ниже редактора. Пользователь с доступом автора не сможет изменить такое поле в документе, хотя, являясь автором документа, может перевести документ в режим редактирования и изменить в нем поля, для которых данное свойство не установлено. Многочисленные примеры использования полей с таким свойством встречаются в общей адресной книге. Например, поле
с меткой Certified Public Key: в документе Person.
Дверь Сервер
Доступ к серверу Notes определяют четыре фактора: успешное выполнение процедуры аутентификации, сравнение публичного ключа со значением из адресной книги сервера, проверка пароля и список управления доступом к серверу.
1. Процедура аутентификации. A и B должны иметь сертификат от общего сертификатора или взаимные сертификаты. Если это не выполняется, в сообщениях об отказе доступа обязательно говорится об отсутствии сертификата.
· Проверка простых сертификатов. Если один из A или B (или оба сразу) имеют неиерархические имена, в процедуре аутентификации проверяются только их простые сертификаты. Если А и В не имеют общего (т.е. выданного обоим одним и тем же сертификатором) простого сертификата, в доступе будет отказано и будет получено сообщение "Your ID has not been certified to access the server".
· Проверка иерархических сертификатов. Если оба A и B имеют иерархические имена, они должны иметь иерархический сертификат-компоненту от общего сертификатора или взаимные сертификаты. Если ни первое, ни второе не выполняются, в доступе будет отказано и будет получено сообщение "Your/Server
Address Book does not contain any cross certificates capable of authenticating the server".
Однако в Notes версий 4.х выбором Yes в поле Allow anonymous Notes connections: документа Server (см. Рис. 4.22) можно разрешить доступ к серверу любым серверам и станциям версий 4.х, даже если для них процедура аутентификации завершилась неуспешно. Такой клиент получает доступ к серверу под именем Anonymous. Однако станции и серверы версий 3.х в такой ситуации "сами себе запрещают" доступ к серверу версии 4.х.
2. Сравнение публичного ключа со значением из адресной книги сервера. Если в документе Server в поле Compare public keys… выбрано Yes (см. Рис. 4.22), публичный ключ обращающегося к серверу клиента сравнивается со значением его публичного ключа из документа Server или Person в адресной книге сервера. При несовпадении ключей попытка доступа отвергается. Такая возможность предотвращает доступ к серверу лиц, "похитивших" ID-файл клиента и знающих его пароль, после того, как "обнаруживший факт хищения" клиент сменит публичный (и, одновременно, личный) ключ в своем ID-файле.
3. Проверка пароля. Может использоваться между станциями и серверами версии не ниже 4.5 (см. 8.5.9). Обеспечивает сравнение пароля в ID-файле обращающегося к серверу пользователя станции с паролем, хранящимся в документе Person
общей адресной книги. При несовпадении ключей попытка доступа отвергается.
4. Список управления доступом к серверу. Если в доступе к серверу было отказано и получено сообщение "Server Error: You are not authorized to access the server", это означает, что три предыдущих проверки завершились успехом, однако доступ явно запрещен в т.н. списке управления доступом к серверу.
Под списком управления доступом к серверу подразумевается часть полей из секции Restrictions документа Server из адресной книги (Рис. 4.23) или перечисляемый ниже набор переменных из файла NOTES.INI сервера.
Поле Access server: может содержать список имен, групп или шаблонов имен тех, кому разрешен доступ к серверу, а поле Not access server: - список тех, кому доступ запрещен. Если оба поля Access server: и Not access server: пусты, любой прошедший три предыдущих проверки получает доступ к серверу. Если поле Access server: не пусто, клиент А должен входить в содержащийся в поле список, но не входить в список, содержащийся в поле Not access server:, если последнее не пусто.
С полями Access server: и Not access server: "связаны" переменные Allow_Access и Deny_Access из файла NOTES.INI. В качестве значений этих переменных могут задаваться списки имеющих или не имеющих доступ к серверу. Однако эти переменные "действуют" только тогда, когда соответствующие им поля из документа Server пусты. "Непустые" списки из документа Server перекрывают "аналогичные им" переменные из файла NOTES.INI.
Кроме того, в файле NOTES.INI могут задаваться переменные, регулирующие доступ к серверу через его конкретный порт.
· Allow_Access_<имя порта> - список имеющих доступ к серверу через его порт <имя порта>. Например, Allow_Access_COM1 может задавать список тех, кто имеет доступ к серверу через порт COM1.
· Deny_Access_<имя порта> - список тех, кому запрещен доступ к серверу через его порт <имя порта>.
Обратите внимание, что этим переменным нет "аналогов" в документе Server.
Наконец, при доступе к серверу через сервер-посредник "начинают работать" поля Access this server:, Route through:, Cause calling: и Destinations allowed: из секции Restrictions документа Server (Рис. 4.23). С этими полями могут быть "связаны" переменные из файла NOTES.INI с именами соответственно Allow_Passthru_Access, Allow_Passthru_Clients, Allow_Passthru_Callers и Allow_Passthru_Targets. Принцип "связи" - непустое поле из документа Server заменяет значение соответствующей переменной из NOTES.INI.
Event Logging - система протоколирования событий
Система протоколирования событий позволяет собирать информацию обо всех ошибках и тревогах, возникающих на обслуживаемых вами серверах.
С точки зрения API Notes событие - сигнал от одной серверной программы другой о том, что произошло что-то, представляющее взаимный интерес. События передаются через очередь событий. Любая серверная программа может создать, обычно для "общения" с другими программами, "свою" очередь событий. Серверная программа, помещающая события в очередь, называется генератором событий. Серверная задача, удаляющая события из очереди, обычно после их обработки, называется обработчиком событий.
В API Notes имеется набор функций для работы с событиями. Всякое событие имеет два свойства, задаваемых целочисленными константами:
· тип события
- стандартный: Comm/Net, Mail, Misc, Replication, Resource, Security, Server, Statistics, Update или нестандартный: определенный разработчиком API-программы;
· "серьезность события" - Fatal - крах системы, Failure - тяжелая, серьезная ошибка, но не приводящая к краху, Warnings(high) - операция завершилась неуспешно
и обычно требуется вмешательство администратора, Warnings(low) - падение производительности, Normal - сообщение о состоянии.
Кроме этого в событии содержатся относящиеся к нему данные: длина данных (слово) и соответствующее количество байт данных.
Серверные задачи, входящие в комплект поставки сервера, наиболее часто используют так называемую стандартную очередь событий. Именно в эту очередь заносится информация обо всех событиях, возникающих при работе сервера. И именно из этой очереди серверная задача Event "умеет" некоторые события "извлекать" и необходимым образом протоколировать. Какие события должны извлекаться и как они должны протоколироваться - задается в настройках в базе Statistics & Events.
Задача Event может протоколировать информацию о событиях следующими способами: почта (Mail), передача на другой сервер
в пределах одной поименованной сети (Relay to other server), протоколирование в базе (Log to database), передача другой программе, например, Notes View,
по протоколу SMNP (SMNP Trap), запись информации о событии непосредственно в протокол Windows NT на данном компьютере (Log to NT Event Viewer).
Описание всевозможных событий, включая связанные с ними сообщения об ошибках, содержатся в базе Statistics & Events в виде 5. Names & Messages\Messsages.
Для настройки системы протоколирования событий в базе EVENTS4.NSF необходимо создать набор документов Event Notification (в виде 2. Event Monitors).
Рис. 11.9 Тип Mail: отправка письма о событии в почтовую базу
В документе Event Notification
содержится следующее.
· Enabled/Disabled: - задаче Event разрешено/запрещено "интерпретировать" этот документ.
· Server name(s): - серверы, на которые распространяется действие документа: имя сервера, список имен серверов или "*" для всех серверов.
· Event type: - тип события, подлежащего протоколированию. Список возможных типов:
· Comm/Net - коммуникации по модему или локальной сети;
· Mail - передача почты;
· Replication - репликации;
· Resourse - системные ресурсы, например, исчерпана память на диске;
· Relay to another server - передача события на другой сервер;
· SNMP Trap - передача информации о событии по протоколу SNMP другой программе, например, Notes View;
· Log to NT Event Viewer - запись информации о событии непосредственно в протокол Windows NT на данном компьютере.
· Notification destination: - "место" протоколирования, зависящее от выбранного способа протоколирования события.
· Mail - адрес почтового ящика или почтовой базы.
· Log to a database - файл базы данных, в которую выполняется протоколирование, и Local - если эта база находится на этом же сервере, или имя сервера, если база находится на другом сервере, но в одной поименованной сети с сервером - источником события.
· Relay to another server - имя сервера, в системную очередь которого передается событие. Этот сервер должен находиться в пределах одной поименованной сети с сервером - источником события.
· SNMP Trap - имя данного сервера Notes. Предполагается, что на компьютере, на котором установлен этот сервер Notes, запущена специальная задача, способная принимать информацию о событии и передавать ее далее по протоколу SNMP. Например, когда на сервере Notes установлена поддержка Notes View 4.0, в качестве такой "специальной задачи" выступает сервис Lotus NotesView SNMP Agent. Этот сервис принимает информацию о событии и далее по протоколу SNMP передает ее на другой компьютер - станцию управления Notes View.
· Log to NT Event Viewer - ничего дополнительно не требуется, поскольку информация о событии функциями API Windows NT заносится в протокол событий Windows NT на этом же компьютере.
Рис. 11.10 Тип Mail: отправка письма о событии в почтовую базу
Например, в документе Event Notification на Рис. 11.9 "сказано", что информация о событиях типа Comm/Net (связанных с проблемами при работе по локальной сети или коммутируемым соединениям) должна отправляться письмом в почтовую базу. Согласно документу на Рис. 11.10 информация обо всех событиях, касающихся безопасности, отправляется в почтовый ящик администратора. Документ на Рис. 11.11 "требует" протоколировать события о репликациях на указанном сервере в расположенной на нем локально базе (обычно это база STATREP.NSF), а документ на Рис. 11.12 - возникающие на одном сервере события, связанные с функционированием системы доставки почты, передавать в стандартную очередь событий на другом сервере.
Рис. 11.11 Тип Log to Database: протоколирование в локальной базе
Рис. 11.12 Тип Relay to other server: передача события на другой сервер
Обратите внимание, что если вы хотите собирать информацию о событиях с многих серверов в одном месте, но в пределах одной поименованной сети, обычно используют способ протоколирования Relay to other server. Серверы - источники событий - передают их в очередь на сервер, протоколирующий события. Последний сервер обычно протоколирует события из очереди в локальной базе. Если же сервер - источник событий - и сервер, протоколирующий события, находятся в разных поименованных сетях (или в разных доменах), события приходится доставлять почтой по адресу почтовой базы на сервере протоколирования. Однако если в этом случае протоколируется слишком много событий, будут излишне перегружены задачи маршрутизации почты.
Основные принципы работы системы протоколирования событий показаны на Рис. 11.13. Все серверные задачи могут помещать события в стандартную очередь. В частности, задача Report, обнаружив ситуацию, "вызывающую тревогу", помещает в стандартную очередь событие типа Statistics заданной вами степени серьезности. Задача Event "подключается" к стандартной очереди событий, отбирает из нее события заданного типа и заданных степеней серьезности, и указанным образом их протоколирует. Заметим, что подобным же образом функционирует и задача Server Logger, "ведущая" протокол работы сервера в базе LOG.NSF.
Рис. 11.13 Принцип работы задач Report и Event
Функции серверной задачи Mail Router и база MAIL.BOX
Задача Mail Router должна выполняться на каждом сервере Notes, который используется как почтовый сервер. Router не имеет никаких собственных протоколов передачи сообщений. Он использует обычные средства работы с базами данных Notes, когда извлекает документы сообщений из одних баз и записывает эти документы в другие базы.
При выборе базы данных, в которую должен быть записан документ сообщения, Router использует информацию из предопределенных полей этого сообщения. В документе сообщения всегда присутствуют поля SendTo (список адресов получателей сообщения)
и From (адрес отправителя). Кроме того, могут иметься поля CopyTo (список адресов получателей копии сообщения), BlindCopyTo (список адресов получателей "слепой" копии сообщения), DeliveryPriority (приоритет доставки), DeliveryReport (возвращать ли уведомление о доставке), ReturnReceipt (возвращать ли уведомление о прочтении) и целый ряд других. Чтобы "увидеть" эти поля, исследуйте в вашем почтовом ящике любое входящее сообщение, выбрав в окне свойств документа сообщения закладку Fields.
Рис. 7.1 Окно свойств документа сообщения, закладка Fields
Задача Router исполняет следующие функции:
· периодический просмотр локальной базы MAIL.BOX на предмет появления в ней новых сообщений;
· доставка сообщений пользователям, почтовые ящики которых находятся локально на сервере, где функционирует задача Router;
· решение задачи маршрутизации и передача сообщения в базу MAIL.BOX другого сервера.
Обратите внимание на следующие важные моменты.
· Router может только передавать сообщения на другой сервер. При этом он связывается с этим сервером, открывает на нем базу MAIL.BOX и записывает в нее сообщения. Router не занимается приемом сообщений с другого сервера или от пользователя. В него "не заложена" возможность вызывать другой сервер для того, чтобы "забрать предназначенную себе почту". Однако в некоторых случаях Router способен воспользоваться соединением, установленным с "его" сервером по инициативе другого сервера, чтобы передать "свои" сообщения на установивший соединение сервер.
· Router не использует задачу Replicator для выполнения своих функций.
· Каждая база MAIL.BOX - "собственность и забота" одного Router. Обычно любой может помещать сообщения в MAIL.BOX. Но только Router, выполняющийся на сервере, на котором находится MAIL.BOX, может "вынимать" из него сообщения. Стандартные установки в списке управления доступом MAIL.BOX:
Depositor для -Default- и Manager для сервера, на котором выполняется Router.
· Сообщения, приходящие пользователю извне, помещаются задачей Router в почтовый ящик пользователя на сервере. Исходящие сообщения пользователя, активный почтовый ящик которого находится на сервере (режим On Server), сразу записываются Mailer-ом в MAIL.BOX на сервере. Исходящие сообщения от пользователя, активный почтовый ящик которого находится на станции (режим Local) сначала записываются Mailer-ом в MAIL.BOX на станции, а затем, когда станция связывается с почтовым сервером, передаются Mailer-ом в MAIL.BOX на сервере. Пользователь, работающий в режиме Local, использует механизм репликаций, реализуемый программным обеспечением станции, чтобы обмениваться документами между своим локальным почтовым ящиком и его репликой на сервере. При этом из реплики на сервере в почтовый ящик на станции передаются пришедшие пользователю новые сообщения, а в обратную сторону, если это не запрещено в репликационных установках, копии отправленных пользователем сообщений.
Рис. 7.2 Основные положения почтовой системы Notes
В работе задачи Router прослеживаются два цикла.
· Цикл доставки новой почты. Период выполнения цикла очень короток - около одной минуты. Router обнаруживает появление новой почты, анализируя время модификации файла MAIL.BOX. Такая проверка происходит быстро и с малыми вычислительными затратами, оттого и может выполняется столь часто. Как только Router обнаруживает изменение времени модификации файла MAIL.BOX, он выполняет просмотр базы MAIL.BOX, чтобы найти новые сообщения и организовать их доставку своими подпроцессами.
· Цикл повторной доставки ранее не доставленной почты. Период выполнения цикла более длинный - ориентировочно 10-30 минут. Router выполняет просмотр базы MAIL.BOX, чтобы найти ранее не доставленные сообщения и организовать их повторную доставку своими подпроцессами.
MAIL.BOX используется для временного хранения исходящих (со станции) или доставляемых (на сервер) сообщений. MAIL.BOX автоматически создается на сервере при первом запуске задачи Router. MAIL.BOX автоматически создается на станции при первом выборе режима Local в документе Location и сохранении этого документа.
MAIL.BOX станции используется только в режиме Local. Именно в него Mailer - отвечающее за доставку почты программное обеспечение станции - помещает отправленные пользователем сообщения - исходящую со станции почту. В режиме On Server Mailer станции помещает отправленные пользователем сообщения непосредственно в MAIL.BOX на сервере.
Для сервера MAIL.BOX является местом временного хранения сообщений, поступивших на сервер и ожидающих дальнейшей доставки серверной задачей Router. Здесь же может находиться так называемая "мертвая" почта (dead mail) - сообщения, которые не удалось доставить в течение суток, а по истечении этого срока вернуть отправителю уведомление об их недоставке (Delivery Failure Report). Одни сутки - только значение по умолчанию, его можно изменить, задав в файле NOTES.INI переменную MailTimeout=<число дней> или MailTimeoutMinutes=<число минут>. Заметим, что в Notes версий 3.х "мертвая" почта трактовалось "уже" - только как сообщения, которые не удалось доставить в течение суток - и оттого "встречалась чаще".
В MAIL.BOX версий 4.х всего один вид Mail. Он "показывает" всю почту, ожидающую доставки, отсортированную по времени появления. "Мертвые" письма (Dead letters) отображаются в этом виде в отдельной категории и отмечаются пиктограммой красного цвета.
Рис. 7.3 В MAIL.BOX имеется два "мертвых" письма, а ожидающих отправки нет
Чтобы повторно попытаться отправить "мертвую" почту, нужно выполнить агента Release Dead Messages.
Повторим, что причиной появления "мертвой" почты является невозможность доставить сообщение адресату в течение 24-х часов из-за отсутствия связи или неработоспособности вызываемого сервера, а затем, по аналогичным причинам, невозможность вернуть отправителю сообщения уведомление о недоставке. Ошибка в имени получателя или домена получателя, а также возможность вернуть уведомление о недоставке из-за отсутствия связи или неработоспособности вызываемого сервера в течение 24-х часов не влекут появления "мертвой" почты - в этом случае отправитель получает уведомление о недоставке почти немедленно (Рис. 7.4) или через некоторое время (Рис. 7.5, Рис. 7.6).
Рис. 7.4 Уведомление о недоставке - почтовый сервер отправителя сразу выяснил, что из текущего домена нет пути в домен X
Рис. 7.5 Уведомление о недоставке - путь из домена отправителя (InterTrustCorp, г. Москва) в домен получателя (Kiev, г. Киев) имеется, сообщение доставляется на сервер в домене Kiev, но там выясняется отсутствие получателя. Поскольку между серверами InterTrust/InterTrustCorp, MOSCOW_ISLAND и Viaduk/Kiev/UA используются модемные соединения, с момента отправки сообщения до получения уведомления о недоставке проходит некоторое время
Рис. 7.6 Уведомление о недоставке, возвращенное на сообщение, которое серверу не удалось доставить в течение суток, хотя все необходимые документы в адресной книге присутствовали
и ведения групп. Группы используются
Документы формы Group применяются для создания и ведения групп. Группы используются в списках рассылки, в списках управления доступом к базам (ACL), в списке доступа к серверу. Группы LocalDomainServers (серверы "нашего" домена) и OtherDomainServers (серверы других доменов) создаются автоматически при создании адресной книги. При работе с серверами в других организациях рекомендуется создавать группу External Servers, содержащую список таких серверов. Можно порекомендовать также создать группы Administrators - администраторы серверов и лица, приравненные к ним в правах; Replica Makers - лица, имеющие право создавать реплики баз на сервере; Terminations - лица, прекратившие работу в организации; Restricted Agent - пользователи, которые могут выполнять на сервере агентов с ограниченными возможностями; Unrestricted Agent - пользователи, которые могут выполнять на сервере агентов с неограниченными возможностями. Остальное - по замыслу администраторов. Но учтите, что чем рациональнее вы спланируете создаваемые группы, тем легче и понятнее вам будет управлять обеспечением безопасности в вашем домене.
Рис. 4.14 Пример документа Group
В качестве члена группы может быть указана также другая группа, но допускается не более 6 уровней вложенности.
Отличием от версий 3.х является наличие типа группы - поле с меткой Group Type:. Тип группы может быть одним из следующих: Multi-purpose - многоцелевая, Access Control List only - группа используется только в списках управления доступом баз, Mail only - группа используется только для рассылки почты, Deny List only - группа используется для запрещения доступа и ее состав не должен модифицироваться задачей Administration Process. Не удивляйтесь, что вновь созданная группа типа Deny List only "исчезает" из вида Groups. Дело в том, что группы типа Deny List only представлены в отдельном виде Server\Deny Access Groups.
Идентификатор документа и свойство Seq Num поля (пункта)
Две реплики базы могут иметь разные версии одного документа, пока не произойдет репликация. После успешной репликации в обеих репликах содержатся одинаковые версии того же самого документа.
Идентификатор документа в базе данных Notes включает:
· DocumentUniqueID
- универсальный идентификатор документа, одинаковый во всех репликах. Это инвариант для всех версий документа
· DocumentVersionID
- описывает специфическую версию документа. Он изменяется при создании новых версий документа. Состоит из четырех компонент: дата-время последней модификации документа (SD), последовательный номер (SN), идентификатор реплики базы, в которой был создан документ (DB) и идентификатор местоположения документа в этой базе данных (NT).
Рис. 6.17 Рамкой обведены дата-время последней модификации (SD) и последовательный номер (SN) документа
Две версии одного и того же документа (с одинаковым DocumentUniqueID) в разных репликах могут иметь разный последовательный номер (SN) и дату-время последней модификации (SD). При сохранении документа после внесения изменений увеличивается на единицу его последовательный номер (SN) и изменяется дата-время его модификации (SD).
Рис. 6.18 Свойство Seq Num поля (пункта)
Кроме того, в версиях 4.х в момент сохранения документа в базе отслеживается, какие поля (более строго, пункты полей, поскольку поля типа Rich Text хранятся в виде серии пунктов, каждый размером не более чем 64 Кб) действительно были изменены. Для тех полей, которые действительно изменились, свойство поля Seq Num устанавливается равным последовательному номеру документа (SN). Если же поле не изменилось, его Seq Num не меняется (сохраняет прежнее значение).
Иерархическая система имен в организации
По умолчанию в Notes все пользователи из одной организации получают доступ ко всем серверам, которые они "видят" со своих станций (имеется в виду, что у станции и сервера есть общий протокол). Напротив, пользователи из других организаций по умолчанию не имеют доступа к серверам в данной организации.
Имена должны следовать структуре вашей организации. Рассмотрим пример организационной структуры компании на Рис. 1.6.
US ï
СТРАНА
|
____________________________________________
|
Acme Corp., Inc. ï
ОРГАНИЗАЦИЯ / ДОМЕН
|
____________________________________________
|
Finances Personnel Marketing Sales ï
ОРГ. ЕДИНИЦА #1
|
____________________________________________
|
Austin Denver San Diego Little Rock ï ОРГ. ЕДИНИЦА #2 (Город)
|
____________________________________________
|
Other Users Jon Jones ï
ИМЯ ПОЛЬЗОВАТЕЛЯ
Рис. 1.6 Дерево имен компании Acme Corp., Inc. сначала использует деление по функциональному назначению, а затем по территориальному расположению оргединиц
В этом примере полное иерархическое имя пользователя Jon Jones имеет вид Jon Jones/Austin/Marketing/Acme Corp., Inc./US, оно состоит из компонент C(Страна)=US, O(Организация)=Acme Corp., Inc., OU1(Оргединица #1)=Marketing, OU2(Оргединица #2)=Austin, CN(Имя пользователя) = Jon Jones.
Название организации - старшая компонента в именах всех пользователей, серверов и сертификаторов, относящихся к этой организации. В именах допустимо не более 4-х уровней оргединицы (OU1-OU4). С точки зрения теории графов вы имеете дело с деревом (деревом имен). Оконечным узлам (листьям) дерева имен соответствуют пользователи или серверы, каждый из которых представлен своим ID-файлом. Неоконечным узлам дерева соответствуют сертификаторы, каждый из которых тоже представлен своим ID-файлом. Сертификатор - лицо, имеющее возможность зарегистрировать новых пользователей, новые серверы или других сертификаторов "ниже себя на уровень" в дереве имен. Имена сертификаторов начинаются с символа /, например: /Acme Corp., Inc./US - сертификатор этой организации, /Marketing/Acme Corp., Inc./US - сертификатор оргединицы уровня 1,
/Austin/Marketing/Acme Corp., Inc./US - сертификатор оргединицы уровня 2 (именно этот сертификатор и зарегистрировал пользователя Jon Jones).
Выбор иерархической системы имен в случае большой организации (например, 2000 пользователей и 40 серверов) оказывается ответственным и далеко не простым делом.
Иерархические сертификаты
Иерархические сертификаты удостоверяют иерархические имена. В ID-файле пользователя с иерархическим именем может присутствовать только один иерархический сертификат. Однако внутренне иерархический сертификат представляет собой последовательность сертификатов-компонент, выданных сертификаторами верхних уровней организации для подчиненных им уровней. В результате полное иерархическое имя пользователя "согласовано" с имеющейся в ID-файле последовательностью сертификатов-компонент.
Например, иерархическому имени Mary Jones/Sales/Software Products/Lotus/US соответствует такая последовательность сертификатов-компонент:
· Mary Jones/Sales/Software Products/Lotus/US сертифицирована /Sales/Software Products/Lotus/US
· /Sales/Software Products/Lotus/US сертифицирован /Software Products/Lotus/US
· /Software Products/Lotus/US сертифицирован /Lotus/US
· /Lotus/US сертифицирован "самим же" /Lotus/US (это верхний уровень в дереве имен).
Каждый сертификат-компонента устанавливает ассоциацию между соответствующим именем и публичным ключом "за подписью" соответствующего уровня (см. Рис. 8.4). Например, первый сертификат-компонента устанавливает ассоциацию между именем Mary Jones/Sales/Software Products/Lotus/US и ее публичным ключом "за подписью" сертификатора /Sales/Software Products/Lotus/US. /US не имя сертификатора, а обозначение страны, применяемое для того, чтобы гарантировать всемирную уникальность имени.
Рассмотрев сертификаты-компоненты, имеющиеся в ID-файле (см. Рис. 8.2), вы можете обнаружить, что их на самом деле больше, чем следует из приведенных выше соображений. Дело в том, что некоторые сертификаты-компоненты могут присутствовать в двух экземплярах - для лицензий видов International и North American. Однако в поставляемых за пределы Северной Америки версиях Notes International эти оба экземпляра "отображают" одно и то же.
Когда ID-файл пользователя с иерархическим именем сертифицируется, в нем заменяется сразу вся последовательность сертификатов-компонент. Поэтому сертификацию ID-файла с иерархическим именем более точно называют ресертификацией.
Использование сертификатов при проверке электронной подписи
Остается объяснить последний момент, связанный с проверкой электронной подписи - из какого источника станция, проверяющая подпись, получает публичный ключ подписавшего письмо или секцию. Этим источником не может быть общая адресная книга, поскольку в противном случае администратор сервера мог бы подменять в ней публичные ключи пользователей и этим "управлять" процедурой проверки подписи. Дело в том, что поле $Signature или $Sig_SectionName содержит не только зашифрованное личным ключом подписавшего значение контрольной суммы по подписываемым полям, но и все сертификаты, извлеченные из ID-файле подписавшего письмо или секцию. Этим объясняется и размер полей $Signature или $Sig_SectionName - в среднем 500 - 700 байтов. Таким образом, документ с несколькими электронными подписями - "недешевое удовольствие".
Для того чтобы "уверенно" определить публичный ключ подписавшего письмо или секцию, станция проверяющего выполняет процедуру проверки сертификатов подписавшего. Эта процедура подобна той, которая выполняется при установлении подлинности пользователя, устанавливающего контакт с сервером. Предположим, письмо или секцию подписал Nikolay N. Iontsev/InterTrustCorp/SU, а проверяет его подпись станция под ID-файле Vladimir A. Panov/InterTrustCorp/SU. Станция Владимира Панова определяет, что общей частью имен подписавшего и проверяющего является /InterTrustCorp/SU. Это имя сертификатора, который создал иерархический сертификат и для Nikolay N. Iontsev/InterTrustCorp/SU, и для Vladimir A. Panov/InterTrustCorp/SU. Прежде всего необходимо определить публичный ключ сертификатора /InterTrustCorp/SU. Он может быть определен из сертификата-компоненты в ID-файле на станции Владимира Панова. Сертификатам, извлеченным из своего ID-файле, станция Владимира Панова "доверяет". Теперь, "уверенно" зная публичный ключ сертификатора /InterTrustCorp/SU, необходимо проверить содержащийся в поле $Signature или $Sig_SectionName сертификат-компоненту, которую создал сертификатор /InterTrustCorp/SU для Nikolay N. Iontsev/InterTrustCorp/SU. В этом сертификате-компоненте (см. 8.2) имеется значение контрольной суммы по информации сертификата, зашифрованное личным ключом сертификатора. Это значение контрольной суммы дешифрируется публичным ключом сертификатора, а затем сравнивается с вычисленным текущим значением контрольной суммы по информации предоставленного сертификата-компоненты. Если значения контрольных сумм совпали, сертификат-компонента, как говорится, "имеет силу". Тогда из этого сертификата-компоненты можно извлечь публичный ключ Nikolay N. Iontsev/InterTrustCorp/SU и "уверенно" использовать уже при проверке контрольных сумм по подписываемым полям письма или секции.
Отметим, что если бы имена подписавшего и проверяющего имели больше уровней иерархии, подобные проверки сертификатов-компонент выполнялись бы несколько раз. Если бы подписавший и проверяющий принадлежали к разным организациям, т.е. не имели бы общего сертификатора, для проверки сертификатов-компонент потребовались бы взаимные сертификаты из адресной книги. Если бы проверяемый документ имел несколько секций, подписанных разными лицами, аналогичная процедура выполнялась бы для сертификатов-компонент каждого из этих лиц.
Использование Shared Mail в случае
Если используются реплики ПЯ на станции, можно сделать так, чтобы тела сообщений автоматически помещалось в СПЯ, когда эти сообщения реплицируются из ПЯ на станции в ПЯ на сервере. Для этого используют команду консоли сервера:
Load Object Set -Always USERMAIL.NSF SHARED.NSF ,
где USERMAIL.NSF - имя ПЯ, имеющего локальную реплику, или имя каталога, содержащего ПЯ, имеющие локальные реплики.
Эта команда обеспечит при последующих репликациях между станцией и сервером автоматическое сохранение тел сообщений в СПЯ. Чтобы сделать это для сообщений, уже содержащихся в ПЯ, используйте команду Load Object Link.
Чтобы отключить имеющие локальные реплики ПЯ от использования СПЯ и еще раз сохранить сообщения полностью, введите с консоли сервера команду
Load Object Reset -Always USERMAIL.NSF ,
где USERMAIL.NSF - имя ПЯ реплики или каталога, содержащего ПЯ реплик.
Использование задачи ADMINP для установки проверки пароля при аутентификации
Возможность проверки пароля при аутентификации поддерживается только серверами и станциями версии не ниже 4.5. Для того чтобы сервер выполнял проверку пароля, в документе Server в секции Security должна быть выбрана опция Check Password. Сервер версии ниже 4.5 не выполняет проверку пароля, даже если вы выберите опция Check Password в его документе Server. Проверка выполняется не для всех пользователей, а только для тех, для которых она разрешена в документе Person. Чтобы проверка могла выполняться, необходимо, чтобы станция пользователя была версии не ниже 4.5. Если пользователь, для которого была разрешена проверка пароля, пытается осуществить доступ к серверу версии не ниже 4.5 со станции версии ниже 4.5, его аутентификация кончается неуспехом, и он не получает доступа к серверу.
Если проверка пароля при аутентификации разрешена, пользователь получит доступ к серверу только в том случае, если пароль, содержащийся в его ID-файле, совпадает с паролем, который "помнит" сервер. Поэтому в ситуации, когда ID-файл пользователя и его пароль стали доступны "злоумышленникам", пользователю достаточно сменить пароль в своем ID-файле и обратиться к администратору.
Администратор либо разрешает серверам выполнять для этого пользователя проверку пароля, либо, если это уже разрешено, "очищает" в документе Person пользователя поле, в котором хранится старый пароль. В результате при первом обращении пользователя к одному из серверов, поддерживающих проверку пароля, новый пароль пользователя в зашифрованной форме будет передан станцией пользователя этому серверу и помещен в документ Person пользователя. Если "злоумышленник" успеет проделать это раньше законного пользователя, администратору придется снова "очистить" в документе Person поле, в котором хранится пароль, а пользователю - повторить попытку обращения к серверу.
Разрешение выполнять для пользователя процедуру проверки пароля при аутентификации администратор "дает" из вида People общей адресной книги. В виде отмечаются документы Person необходимых пользователей, затем в меню выбирается Actions - Set Password Fields. В появившемся окне в поле с меткой Check password:
выбирается Check password ("проверять пароль"). Альтернативы: Don't check password - отменить проверку, Lockout ID - "заблокировать ID-файл" ( тогда процедура аутентификации для пользователя без всяких условий будет оканчиваться неуспешно).
Рис. 8.27 Выбор проверки пароля для пользователя
Дополнительно могут быть заполнены поля
· Required change interval: - количество дней, спустя которое серверы начинают предлагать пользователю изменить пароль в его ID-файле, причем значение 0 "запрещает" серверам "вынуждать" пользователя периодически изменять пароль;
· Grace period: - количество дней, в течении которых серверы "предлагают" пользователю изменить пароль, но все еще предоставляет пользователю доступ, "снисходительно наблюдая" за его отказами, прежде чем лишают "упрямого" пользователя права доступа.
После нажатия кнопки Ok в базе данных Administration Requests создается документ-запрос Set Password
Information. Запрос репликациями достигает сервера администрирования адресной книги. Задача Adminp этого сервера выполняет запрос, внося соответствующие изменения в поля Check password:, Required change interval: и Grace period: документа Person пользователя. Модифицированный документ Person репликациями поступает в адресные книги других серверов домена. При попытке пользователя зарегистрироваться на сервере, для которого разрешена проверка пароля, станция сообщает серверу зашифрованный пароль, а сервер создает в базе данных Administration Requests новый документ-запрос Change User Password in Address Book. Запрос репликациями достигает сервера администрирования адресной книги. Задача Adminp этого сервера выполняет запрос, внося соответствующие изменения в поле Password digest: документа Person пользователя. Модифицированный документ Person репликациями поступает в адресные книги других серверов домена.
Рис. 8.28 Секция из документа Person, содержащая поля, относящиеся к проверке пароля при аутентификации
После этого все серверы, на которых разрешена проверка пароля, в ходе аутентификации пользователя сравнивают пароль его ID-файла (он передается серверу станцией в зашифрованной форме) со значением из документа Person. Аутентификация завершается успехом только при совпадении паролей. Попытка получить доступ к серверу под ID-файлом с другим паролем заканчивается получение сообщения "You have a different password on another copy of your ID file and you must change the password on this copy to match".
Кроме того, если требуется, серверы "вынуждают" пользователя периодически менять его пароль, не допуская при этом повторения ранее использованных паролей (хранятся до 50 прежних паролей).
Использует ли ПЯ СПЯ? Как отличить ПЯ от СПЯ?
Чтобы определить, использует ли конкретный ПЯ или все ПЯ из некоторого каталога возможности Shared Mail, а так же выяснить, какой файл является просто ПЯ, а какой - СПЯ, используется команда консоли:
Load Object Info USERMAIL.NSF ,
где USERMAIL.NSF - имя файла ПЯ или имя содержащего ПЯ каталога.
> load object info mail
15.08.96 14:17:01 Object Store Manager: Process started
15.08.96 14:17:02 Object Store Manager: mail\ALINEV.NSF is not an object store (это ПЯ, а не СПЯ)
15.08.96 14:17:02 Object Store Manager: mail\ALINEV.NSF contains notes which use an object store (этот ПЯ содержит тела сообщений в СПЯ)
15.08.96 14:17:03 Object Store Manager: mail\asavelye.nsf is not an object store
15.08.96 14:17:03 Object Store Manager: mail\asavelye.nsf contains notes which use an object store
15.08.96 14:17:04 Object Store Manager: mail\DIVANOV.NSF is not an object store
15.08.96 14:17:04 Object Store Manager: mail\DIVANOV.NSF contains notes which use an object store
15.08.96 14:17:04 Object Store Manager: mail\muser.nsf is not an object store
15.08.96 14:17:04 Object Store Manager: mail\muser.nsf contains no notes which use an object store
15.08.96 14:17:05 Object Store Manager: mail\niontsev.nsf is not an object store
15.08.96 14:17:05 Object Store Manager: mail\niontsev.nsf contains notes which use an object store
15.08.96 14:17:05 Object Store Manager: mail\otaranch.nsf is not an object store
15.08.96 14:17:06 Object Store Manager: mail\otaranch.nsf contains notes which use an object store
15.08.96 14:17:06 Object Store Manager: mail\ppuchkov.nsf is not an object store
15.08.96 14:17:06 Object Store Manager: mail\ppuchkov.nsf contains notes which use an object store
15.08.96 14:17:06 Object Store Manager: mail\Shared.nsf is an object store (это СПЯ)
15.08.96 14:17:07 Object Store Manager: mail\SMOISEEV.NSF is not an object store
15.08.96 14:17:07 Object Store Manager: mail\SMOISEEV.NSF contains notes which use an object store
15.08.96 14:17:07 Object Store Manager: mail\VPANOV.NSF is not an object store
15.08.96 14:17:07 Object Store Manager: mail\VPANOV.NSF contains notes which use an object store
15.08.96 14:17:07 Object Store Manager: Process shutdown
Изменение иерархии в имени пользователя с использованием задачи ADMINP
Пользователю, переводимому из одной оргединицы в другую, достаточно просто сообщить об этом своему сертификатору. Сертификатор "старой оргединицы" отмечает документ Person этого пользователя в адресной книге и выбирает в меню Action - Rename Person. В появившемся диалоговом окне (Рис. 8.21) нажимает кнопку Request Move to new Certifier. Выбирает "свой" ID-файл сертификатора, вводит его пароль и получает диалоговое окно для создания запроса на перемещение.
Рис. 8.25 Окно для формирования запроса на перемещение пользователя в другую оргединицу
В этом диалоговом окне вводит имя нового сертификатора - сертификатора той оргединицы, в которую переводится пользователь. Нажимает кнопку Submit Request и закрывает адресную книгу. Работа "старого" сертификатора на этом завершена.
Рис. 8.26 Окно подтверждения "приема" пользователя в новую оргединицу
Сертификатор той оргединицы, в которую "переходит" пользователь, обнаруживает в базе Administration Requests в виде Name Move Requests
относящийся к нему документ - запрос на перевод пользователя в оргединицу этого сертификатора. Сертификатор отмечает этот документ и выбирает в меню Actions - Complete Move for selected entries. Далее выбирает свой ID-файл сертификатора, вводит его пароль, в появившемся диалоговом окне (Рис. 8.26) нажимает кнопку Certify. На этом его работа завершена.
Оставшаяся часть работы выполняется автоматически с участием задачи ADMINP подобно тому, как это описано в 8.5.7.
