Алгоритм маршрутизации
Задача 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=
Рис. 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". Например, "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
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.
Изменение имени пользователя с использованием серверной задачи ADMINP
Пользователю, решившему поменять свое имя, достаточно просто сообщить об этом своему сертификатору. Сертификатор "отмечает" документ Person этого пользователя в общей адресной книге, а затем выбирает в меню Action - Rename Person.
Рис. 8.21 Окно Certify Selected Entries
В появившемся окне нажимает кнопку Change Common Name. Далее выбирает соответствующий ID-файл сертификатора.
Рис. 8.22 Выбор ID-файла сертификатора
В появившемся после ввода пароля для ID-файла сертификатора диалоговом окне вводит новое имя пользователя.
Рис. 8.23 В окне вводится новое имя пользователя
Нажимает кнопку Rename и получает "окно-квитанцию" о передаче запроса на переименование в базу данных Administration Requests.
Рис. 8.24 "Квитанция" о приемке запроса
Все последующие шаги происходят автоматически.
1. В базу Administration Requests на том же сервере, адресная книга которого открыта, добавляется документ Address Book Change, и далее этот документ реплицируется в базы Administration Requests других серверов домена.
2. В базе Certification Log протоколируется осуществленный акт сертификации, и далее этот документ реплицируется в базы Certification Log других серверов домена.
3. Задача Adminp на сервере администрирования, назначенном для адресной книги, сканирует свою базу Administration Requests, находит в ней документ Address Book Change и в соответствии с этим документом изменяет документ Person для этого пользователя в своей адресной книге. После этого вставляет документ Status в свою базу Administration Requests.
4. Изменения в адресной книге репликациями достигают других серверов домена.
5. Наступает время, когда пользователь, пожелавший изменить свое имя, под своим "старым" ID-файлом обращается к одному из серверов домена. В этот момент пользователь получает диалоговое окно с предложением изменить имя в ID-файле. Он соглашается с предложением, и его станция выполняет изменения в ID-файле и заменяет в нем иерархический сертификат на новый.
6. Сервер, с которым пользователь устанавливал соединение, добавляет в свою базу Administration Requests документ Update Address Book.
7. Изменения в базе Administration Requests репликациями достигают других серверов домена.
8. Задача Adminp на сервере администрирования, назначенном для адресной книги, сканирует свою базу Administration Requests, находит в ней документ Update Address Book и в соответствии с этим документом изменяет старое имя пользователя на новое во всех остальных документах, в которых старое имя могло встречаться. После этого создает документ Update ACL в своей базе Administration Requests. В версиях Notes от 4.5
дополнительно создается документ Rename in Reader/Author fields.
9. Изменения в базе Administration Requests репликациями достигают других серверов домена.
10. Задачи Adminp на серверах домена сканируют свои базы Administration Requests, находят документ Update ACL и в соответствии с этим документом изменяют старое имя пользователя на новое в списках управления доступом всех тех баз, для которых данный сервер является сервером администрирования.
11. Изменения в списках управления доступом баз реплицируются на другие серверы домена.
12. В версиях Notes от 4.5 еженедельно, обычно в 12 часов дня в воскресенье, задачи Adminp на серверах домена сканирует свои базы Administration Requests в поисках документов Rename in Reader/Author fields. В соответствии с этими документами задачи изменяют старое имя пользователя на новое в полях типа Readers и Authors
всех тех баз, для которых данный сервер является сервером администрирования, а в списке управления доступом базы на закладке Advanced разрешено модифицировать поля типа Readers и Authors.
13. Изменения в полях типа Readers и Authors
реплицируются на другие серверы домена.
Электронная подпись
Могут быть "подписаны" почтовые сообщения или отдельные поля в документах. В случае "подписанной" почты Notes гарантирует получателю, что лицо, указанное в поле адреса отправителя (поле From), действительно было отправителем этого письма, и что "в пути" в это письмо не было внесено изменений. В случае подписанных полей в документе Notes гарантирует лицу, читающему документ, что в этих полях находится точно та же информация, какая была в них в момент сохранения документа лицом, эти поля "подписавшим". Но если ID-файл подписавшего письмо или документ лица был украден и не был защищен паролем или пароль известен похитителю, возможна и "подделка подписи"."Электронная подпись" тесно связана с шифрованием и сертификатами. Подпись
представляет собой вычисляемую по алгоритму хеширования RSA's Message Digest 2 (MD2) контрольную сумму (fingerprint - "отпечаток пальца") по данным из подписываемых полей документа, размером в 128 бит, которая (значение контрольной суммы) в свою очередь зашифрована личным ключом пользователя и добавлена к документу. Изменение единственного бита в подписанных данных с высокой вероятностью приводит к изменению контрольной суммы. Это делает очень маловероятным (хотя теоретически возможным) такое изменение данных в подписываемых полях документа, что при этом контрольная сумма не изменится.
Как обеспечить работу на сервере нескольких репликаторов
Если в документах Connection запланированы одновременные или перекрывающиеся по времени репликации с несколькими серверами, следует иметь на сервере несколько одновременно работающих репликаторов. При этом станут возможны одновременные репликации с разными серверами - каждый репликатор с одним сервером одновременно. Например, если на одно и то же время запланированы репликации сервера А с серверами B и С, и на сервере А запущено два репликатора, один из них будет выполнять репликацию с сервером B, в то время как второй - с сервером C.Для запуска нескольких репликаторов возможны следующие варианты.
· Переменная Replicators или переменная ServerTasks из файла NOTES.INI сервера.
· Команда Load Replica с консоли.
· Команда Load Replica имя_сервера с консоли. Запущенный такой командой репликатор завершится после выполнения репликации с указанным сервером, что эквивалентно команде Replicate имя_сервера.
· Запуск репликатора на уровне операционной системы.
Запуск репликатора на уровне операционной системы выполняется командой
хREPLICA [direction] servername [filename or directory] ,
где:
· х - "I" для OS/2, "N" для Windows NT или Windows 95, "V" для Netware;
· [direction] - необязательный параметр, определяющий тип репликации:
· пусто - Pull-Push,
· -p - Pull-Only,
· -s - Push-Only;
· Servername
- имя вызываемого сервера;
· [filename or directory] - необязательный параметр, задающий имя файла базы или каталог с базами, для которых должна выполняться репликация.
Для того чтобы избежать недоразумений при столь необычном запуске репликатора, проверьте, чтобы в переменных KeyFileName и ServerKeyFileName из файла NOTES.INI были указаны одни и те же ID-файлы. Репликатор, запущенный на уровне операционной системы, будет работать под ID из KeyFileName, в то время как сервер Notes и запущенный из него репликатор работают под ID из ServerKeyFileName.
Наконец, целесообразность применения такого способа запуска репликатора неочевидна, и, начиная с версии 4.5, упоминание о нем в базе Notes Administration Help исчезает.
После того, как на сервере уже запущено несколько репликаторов, их можно остановить, но только все сразу, командой Tell Replica Quit.
Как отождествляются между собой
Подобно идентификатору реплики базы, каждый документ в любой базе Notes имеет свой универсальный идентификатор документа (DocumentUniqueID или UNID). Вы можете "увидеть" универсальный идентификатор документа в окне свойств этого документа.
Рис. 6.9 Универсальный идентификатор документа обведен рамкой
Универсальный идентификатор документа используется при репликациях для нахождения "одинаковых" - имеющих один и тот же универсальный идентификатор - документов в обеих репликах базы.
Если имеющийся в двух репликах документ был модифицирован в одной из реплик, остается по дате модификации выяснить более новую версию и заменить ею документ в другой реплике.
Если в одной из реплик появился новый документ, то у него свой универсальный идентификатор, а в другой реплике нет документа с таким же универсальным идентификатором, так что приходится добавить этот документ в другую реплику.
Если же документ присутствовал в обеих репликах, но затем был удален в одной из них, при удалении Notes заменяет этот документ на "deletion stub". Deletion stub (stub - пень, корень зуба, окурок, ам. корешок чековой книжки) можно рассматривать как документ с тем же универсальным идентификатором, который имел удаленный документ, с датой модификации, соответствующей моменту удаления, и не содержащий никаких полей данных. В соответствии со сказанным выше о модификации документа в одной из реплик при репликации "оставшийся от документа окурок" должен заменить в другой реплике "нормальный", но имеющий более раннюю дату модификации, документ.
"Окурок", как бы мал он ни был, занимает место в базе данных. Постепенно в базе происходит "накопление окурков". Для решения этой проблемы в репликационных установках каждой базы присутствует параметр, называемый "интервалом удаления" - это количество дней XXX в поле с меткой Remove documents not modified in the last: XXX days (см. Рис. 6.10). По умолчанию параметр принимается равным 90 дней, но может быть изменен. В базах данных, находящихся как на сервере, так и на станции, в некоторые моменты времени выполняется удаление "окурков". В базах, находящихся на сервере, процесс удаления "окурков" запускается с интервалом в 1/3 от интервала удаления (по умолчанию раз в каждые 30 дней). При этом удаляются только те "окурки", которые появились в базе раньше, чем текущее время (когда выполняется процесс удаления "окурков") минус интервал удаления.
Будьте внимательны: речь шла только о поле с меткой Remove documents not modified in the last: XXX days, содержащем количество дней XXX, а вовсе не о выборе самой опции Remove documents not modified in the last: XXX days. Если вы выберите эту опцию, то в базе станут автоматически удаляться документы, которые не изменились за последние XXX (интервал удаления) дней. Процесс же удаления "окурков" функционирует независимо от того, выбрана эта опция или нет, и не имеет к ней никакого отношения.
Возможна ситуация, когда "окурки" будут удалены до того, как произойдет репликация. Например, если базы реплицируются один раз в неделю, а интервал удаления равен 3 дня, то процесс удаления "окурков" запускается ежедневно, устраняя при этом "окурки с возрастом" не менее трех дней. При этом репликатор может вновь восстанавливать удаленный в одной реплике документ из другой реплики. Так что в случае, если такое явление происходит, увеличьте интервал удаления и, тем самым, интервал запуска процесса удаления "окурков".
Как влияет шифрование почты на выполнение
Шифрование почты практически не влияет на скорость передачи сообщения от отправителя к получателю, поскольку размер шифрованного сообщения лишь немного больше размера нешифрованного. Шифрование, однако, увеличивает затраты времени в момент отправки сообщения (когда выполняется шифрование) и в момент получения сообщения (потому что его надо дешифрировать). Количество дополнительного времени на шифрование и дешифрирование - функция размера сообщения и количества графических образов, объектов и присоединенных файлов, содержащихся в сообщении.Как влияют на репликацию списки управления доступом реплик базы
Для уяснения принципа влияния списка управления доступом (ACL) на репликацию лучше "временно забыть", что в действительности вначале репликатор на сервере А "тянет к себе" информацию с сервера В. Влияние ACL на репликацию таково, что если что-то (изменения в ACL, дизайн, документы...) поступает на сервер А, то это "как бы записывает" сервер В, а значит, его "возможности по записи" таковы, как то указано для сервера B в ACL на сервере А. И наоборот, когда выполняется вторая фаза репликации. Вне зависимости от того, "заталкивает" ли репликатор сервера A информацию на сервер Bили сам репликатор сервера B "тянет ее к себе" с сервера A, эту информацию на сервер B "как бы записывает" сервер A, а значит его "возможности по записи" таковы, как то указано для сервера A
в ACL на сервере B.
A ç B (информация поступает с сервера В на сервер А)
| Если сервер B определен в ACL на сервере A как ... | При репликации сервер A принимает с сервера B ... | ||
| Менеджер | измененную ACL новые или измененные элементы дизайна новые или измененные документы (включая удаления) | ||
| Дизайнер | новые или измененные элементы дизайна новые или измененные документы (включая удаления) | ||
| Редактор | новые или измененные документы (включая удаления) | ||
| Автор | новые или измененные документы (включая удаления), в полях типа Authors которых явно или как член группы присутствует сервер В. Но поскольку обычно сервер не является автором документа (если только его имя, явно или как члена группы, специально не внесли в поле типа Authors), рекомендуется избегать назначения для серверов такого уровня доступа в ACL баз | ||
| Депозитор | только новые документы |
Поскольку репликация обычно двусторонний процесс, необходимо анализировать и действие ACL "в обратную сторону" (когда информация поступает с сервера A на сервер B).
Рекомендации по настройке ACL
· База на сервере назначения принимает к себе только то, что ее ACL позволяет изменять серверу - источнику изменений. Хотите принимать в базу все - дайте серверу-источнику доступ менеджера, хотите только дизайн и документы - дизайнера, только документы - редактора. Если дополнительно необходимо, чтобы информация только принималась сервером назначения, но не поступала на сервер - источник изменений, в ACL его реплики дайте серверу назначения доступ читателя.
· Сервер - источник изменений должен иметь в ACL базы принимающего сервера тот же доступ, как и наивысший доступ пользователя на сервере-источнике.
· Если каждый сервер имеет доступ менеджера в ACL на обоих серверах и ACL был изменен на одной или на обеих сторонах, более новая версия ACL будет заменять более старую версию. Вся информация из более старой версии ACL будет потеряна. Если "старая" ACL после репликации "вернулась обратно", проверьте правильность установки времени и информации о часовом поясе на обоих серверах.
· Если сервер указан в ACL только как член группы, всякая выясняющая его уровень доступа сторона (сервер или станция) обращается за списком группы в свою локальную адресную книгу. С этим связана часто встречающаяся проблема при репликациях между станцией и сервером: если указать имя сервера
в ACL локальной реплики явно, сервер получает на станции заданный уровень доступа, если указать в ACL группу LocalDomainServers - сервер получает на станции только уровень доступа -Default-. Дело в том, что группа LocalDomainServers в персональной адресной книге станции обычно пуста. Аналогичный эффект может наблюдаться при использовании группы LocalDomainServers
(или других групп) при репликациях между серверами из разных доменов.
· Так как имеются достаточно много связанных с доступом моментов, могущих сделать репликацию неудачной или неполной - ACL, поля Readers и Authors, роли и Directory Links *) - администраторам остается предложить только общую стратегию поиска причин неудачной репликации: "смотреть" на реплику базы данных на "другой" стороне "под ID своего сервера" и руководствоваться правилом: что вы "видите", то вы и можете реплицировать, а что вы "не видите", то вы не можете реплицировать. Однако в версиях 4.х эта стратегия может "не сработать", если в ACL для имени вашего сервера был конкретизирован тип: "только как сервер".
*) Directory Link (в версиях 4.х Directory Pointer) - текстовый файл с расширением .DIR, находящийся в каталоге данных Notes и содержащий в первой строке полное название каталога с базами, иного, чем каталог данных Notes, а в остальных строках список пользователей и групп, имеющих доступ к базам в этом каталоге. Такая возможность часто применяется в случае, когда один диск компьютера переполнен базами, а другой диск свободен, или когда просто необходимо разграничить доступ к целым семействам баз.
Как выполняется маршрутизация почты
Маршрутизацией почты на каждом сервере занимается задача Router. Алгоритм маршрутизации использует данные из документов Person, MailInDatabase, Server, Connections и Domain общей адресной книги.Так как документы Server определяют все серверы в одном домене и все поименованные сети Notes, документы Connection описывают связи между всеми серверами, а общая адресная книга реплицируется между всеми серверами в домене, все серверы домена имеют полную информацию о топологии сети в пределах домена. Эту информацию можно представить в виде ориентированного графа. Вершины графа соответствуют имеющимся серверам, а дуги отражают возможные соединения между серверами для передачи почты.
Рассмотрим это на примере (Рис. 7.7). В границах домена имеется 10 серверов Notes с условными именами S1 - S10. Информация о них содержится в документах Server адресной книги домена. В документах Server имеются сведения о поименованных сетях Notes - группах серверов, использующих для общения один и тот же тип сетевого протокола и способных в любое время соединяться между собой напрямую. В нашем примере четыре поименованных сети. Двусторонние пунктирные дуги между всеми серверами в границах поименованных сетей как раз и отражают тот факт, что почта внутри поименованных сетей всегда передается посредством прямого соединения серверов. Никаких документов Connection для этого создавать не требуется. Напротив, соединения серверов из разных поименованных сетей для передачи почты должны описываться документами Connection. В нашем примере 8 "внутридоменных" документов Connection
для передачи почты: S1 ®
S6, S6 ® S1, S3 ® S4, S4 ® S3, S4 ® S10, S10 ® S4, S10 ® S7, S7 ® S10. Кроме того, имеется 2 "междоменных" документа Connection для передачи почты: S2 ® X1 и S9 ® X2. Для "внешних" серверов X1 и X2 документов Server в адресной книге домена нет. Наличие "внешних" серверов следует из самих документов Connection. Сведения о наличии FAX-сервера и двух агентов передачи почты тоже формально следуют из имеющихся в адресной книге документов, но в данный момент не имеет смысла разбираться с этим подробнее.
Таким образом, каждый сервер (точнее, Router) домена "полностью знает" топологию своего домена и "знает" о наличии и способе соединения с некоторыми серверами из других доменов, однако "не знает" полной топологии других доменов.
Рис. 7.7 "Почтовая" топология домена как ориентированный граф
Числа на дугах графа не что иное, как "стоимость соединения". Для пунктирных дуг будем считать стоимость соединения равной 1. Таким образом, мы имеем ориентированный граф с заданными стоимостями (или длинами) дуг, а значит можем решать на нем оптимизационную задачу по выбору маршрута наименьшей стоимости (наименьшей длины) для доставки сообщения с одного сервера на другой (между двумя наперед заданными вершинами графа).
Кластеры из серверов Notes
Кластер из серверов Notes- группа из до шести серверов Notes, взаимосвязанных и взаимодействующих между собой, чтобы обеспечить высокую степень доступности, масштабируемости и балансировку загрузки.
Высокая степень доступности (high availability)
Для лучшего уяснения смысла этого понятия полезно сравнить понятия отказоустойчивость
и высокая степень доступности.
Отказоустойчивость. Модель fault tolerant и continuous availability базируется на специализированных аппаратных средствах, позволяющих обнаруживать аппаратные неисправности и выполнять практически мгновенные переключения на находящиеся в горячем резерве "избыточные" аппаратные компоненты - будь то процессор, оперативная память, питание, подсистема ввода/вывода или система хранения информации. Такое переключение (cutover) происходит практически мгновенно и обеспечивает непрерывность предоставляемого пользователям обслуживания, но характеризуется высокой стоимостью аппаратных средств. При этом "избыточные" аппаратные компоненты, пока все функционирует нормально, не выполняют никакой полезной обработки. Кроме того, в такой модели не учитываются отказы программного обеспечения. А именно программное обеспечение, а не аппаратные средства, является намного более частой причиной отказов.
Высокая степень доступности. Модель high availability и fault resiliency предполагает наличие набора общесистемных и совместно используемых ресурсов, которые сотрудничают друг с другом, "отслеживая" состояние друг друга, по возможности распределяют между собой рабочую нагрузку, а при отказе некоторых ресурсов по возможности "берут на себя" их функции, чтобы гарантировать предоставляемое пользователям обслуживание. Кластеры Notes реализуют высокую степень доступности посредством программного обеспечения, которое быстро восстанавливает предоставляемые пользователям услуги, когда компьютер, его операционная система или сервер Notes испытывают отказ.
Итак, отказоустойчивая среда не предлагает никакого прерывания предоставляемого сервиса, тогда как в среде с высокой степенью доступности предполагается прерывание предоставляемого сервиса на минимально короткое время. В нормальном режиме работы отказоустойчивая среда не предполагает использования резервных компонент. В среде с высокой степенью доступности в нормальном режиме работы все компоненты функционируют, обеспечивая полное использование вычислительной мощности, кроме относительно небольших затрат на "отслеживание" состояния других компонент.
Для многих организаций по экономическим соображениям более приемлема среда с высокой доступностью и малым количеством времени на переключение, чем дорогостоящая отказоустойчивая среда. При объединении двух или более серверов Notes в кластер для поддержки "критических" баз данных, пока все серверы кластера функционирует нормально, будет использоваться вся вычислительная мощность. При отказе программного обеспечения сервера Notes или программно-аппаратных средств "несущего его" компьютера "критические" базы данных продолжат функционировать после кратковременного прерывания, вызванного отказом.
Масштабируемость
Если разместить реплики используемой многими пользователями базы данных на нескольких серверах-членах кластера, то намного большее количество пользователей сможет работать с такой базой данных. Это происходит, во-первых, за счет синхронизации реплик внутри кластера не по расписанию, а "почти в реальном времени", и во-вторых, благодаря переключениям (failover) обращений пользователей к реплике на "сильно загруженном" или уже обслуживающем большое количество пользователей сервере в реплику на "менее загруженном работой или пользователями" сервере.
Балансировка загрузки серверов в кластере
Администратор имеет возможность "балансировать" рабочую нагрузку серверов-членов кластера, задавая "порог загрузки" для каждого сервера. При возникновении события load balance ("превышен порог загрузки") программное обеспечение станции "переключает" пользователей, пытающихся обратиться к базе данных на "сильно загруженном" члене кластера, на реплику этой базы на доступном (порог загрузки не превышен) члене кластера.
Команды консоли сервера
На Рис. 3.1 дан вид окна консоли сервера. Администратор сервера может вводить команды "после приглашения" > .
Рис. 3.1 Консоль сервера на платформе Windows NT
Рассмотрим наиболее часто используемые команды консоли сервера. Обратите внимание, что в приведенных ниже форматах команд минимально-допустимые сокращения ключевых слов подчеркнуты.
Help Дает подсказку по форматам команд.
> help
BROADCAST "msg" ["user"] Broadcast a message to user(s) of this server
DROP ["username"] [ALL] Drop one or more sessions
EXIT [password] Exit server
HELP Help (Displays this help information)
LOAD pgmname Load program
QUIT [password] Quit (exit server)
REPLICATE servername Replicate two-way request
PULL servername Replicate one-way (pull)
PUSH servername Replicate one-way (push)
ROUTE servername Route mail to server
SET Set server option:
CONFIGURATION "variable=value" Configuration variable
SECURE [current-password] [new-password] Secure Console Password
STAT [Facility] [Statname] Reset statistics
SHOW Show server information:
CONFIGURATION variable Configuration variable
MEMORY Memory information
PORT portname Port specific information
TASKS Server tasks
SERVER Server information
USERS Users with open sessions
DISKSPACE drive-letter Available disk space
SCHEDULE Next Schedule [Server/Program/Location] [Appl]
DIRECTORY Directory Information
TELL taskname command-string Send command-string to a task
Set Configuration "переменная=значение" Устанавливает значение переменной в файле NOTES.INI. Полезность команды состоит в том, что выполненное изменение "вступает в силу" немедленно. Перезапуска сервера, как после "ручной коррекции" файла NOTES.INI, не требуется.
> set conf "Log_Sessions=0"
08.09.96 09:51:47 LOG_SESSIONS changed to 0.
Show Configuration переменная Показывает на консоли текущее значение переменной из файла NOTES.INI.
> sh conf Log_Sessions
LOG_SESSIONS=1
Show Diskspace буква_диска Показывает, сколько памяти свободно на диске.
> sh disk e
Available disk space 15 345 152 bytes
Show Memory
Показывает, сколько памяти (включая виртуальную) свободно на сервере.
> sh mem
Memory Available (including virtual): 32 112K bytes
Show Port имя_порта Показывает текущее состояние порта сервера: количество открытых сессий и их характеристики, трафик по порту, статистику ошибок... В качестве имени порта задают имена, которые были выбраны для портов при их установке (LANx, TCPIP, SPX, COMx и др.).
> sh po spx
SPX Port Driver
NetWare Bindery Services: Advertising with SAP
Notes SessionID: 01BC0006
Local Address Net: 00777777 Node: 008029E04954 Socket: 6078
Remote Address Net: 00000000 Node: 000000000000 Socket: 0000
Session State: (listening)
> sh po tcpip
TCP/IP Port Driver
Transport Provider: TCP
Notes Session Local Address Foreign Address
00860004 *.* 194.73.241.129.1352
00890003 *.* 198.114.68.48.1352
00880006 194.220.151.250.1352 194.220.151.79.1033
008D0005 *.1352 *.*
> sh po lan4
NetBIOS Port Driver
Port LAN4 is using Unit/Lana 4 while the Notes server is running
Unit/Lana number: 2
This net has not been initialized by Notes
Unit/Lana number: 4
Unit ID: 00 80 29 E0 49 54 Version: 254.0
Reporting period (minutes): 0
Maximum packet size: 1482
Errors Transmits Receives
CRC 1 Successful 31995 Successful 30701
Alignment 0 Aborted 0 Dropped 0
Collision 4 Retransmitted 92
Control Blocks (NCBs) Sessions
Free 255 Current 3
Configured 255 Configured 254
Maximum 255 Maximum 254
Name Num Status
NOTESSRV400 + 2 04h registered
IRISNAMESERVER 3 3 84h registered group
xNotes......).IT 4 04h registered
LSN State Local Name Remote Name Receives Sends
48 03h connected NOTESSRV400 + xInterS.....).IQ 1 0
185 01h listening IRISNAMESERVER 3 * 0 0
186 01h listening NOTESSRV400 + * 0 0
> sh po com3
Answered incoming call from system KTEK_MAIN/KTEK/RU
Counts since the beginning of the current connection:
57600 Bit per second connection (port speed)
4800 Bit per second connection (carrier speed)
2 Currently active sessions
15 User messages sent
47 User messages received
1090 User bytes sent
66732 User bytes received
3 Retransmitted packets
0 CRC errors detected
0 Port errors detected
> sh po com4
Waiting for incoming call
Counts since the beginning of the last connection:
16 User messages sent
21 User messages received
3921 User bytes sent
2051 User bytes received
0 Retransmitted packets
0 CRC errors detected
0 Port errors detected
Show Tasks
Показывает имя сервера; его каталог; время функционирования (с момента старта сервера); число выполненных транзакций (с момента старта сервера); скорость как число транзакций в минуту - за последнюю минуту, за последний час и во время наибольшей загрузки (пик) с момента старта; наибольшее число одновременно работавших пользователей с момента старта; количество ожидающих и "мертвых" почтовых сообщений; список выполняющихся задач и их статус.
Основная часть информации в приведенном на Рис. 3.1 окне - отклик на команду SHow Tasks. Активны серверные задачи: Database Server (выполняет все транзакции удаленного пользователя: открытие, закрытие, чтение и запись баз; выполняет команды консоли; ожидает запросы на соединение по СOM- и LAN-портам и пр.), Replicator (выполняет репликации баз между серверами, но не между сервером и станцией), Router (занимается доставкой почты), Indexer (оперативно обновляет индексы баз), Agent Manager (занимается выполнением агентов в базах на сервере).
Show Users
Показывает список работающих с сервером пользователей и открытых ими баз, а для каждой открытой базы - время в минутах, прошедшее с момента последней транзакции станции пользователя с базой, например, чтения документа.
> sh us
User Name Databases Open Minutes Since Last Used
Nikolay N. Iontsev/InterTrustCorp/SU
mail\NIontsev.nsf 0
log.nsf 8
Show Directory
Показывает список баз в каталоге данных сервера Notes и рекурсивно в его подкаталогах, а также в каталогах Directory Link и рекурсивно их подкаталогах. Для каждой базы дается время модификации и количество реплик на данном сервере (если их более одной).
> sh dir
e:\notes400\data\mail.box, ModTime = 08.09.96 04:00:08
e:\notes400\data\mailobj.nsf, (2 Replica's) ModTime = 07.09.96 11:26:10
e:\notes400\data\x\ITNEWS.NSF, ModTime = 25.08.96 02:08:03
e:\notes400\data\x\DOC_KEY.NSF, ModTime = 11.06.96 02:08:53
e:\worksale\ITDocLib.nsf, ModTime = 21.08.96 16:10:45
e:\worksale\DLIB_rab.NSF, ModTime = 21.08.96 16:10:35
e:\notes400\data\web41.ntf, ModTime = 26.08.96 13:23:20
. . .
e:\notes400\data\log.nsf, ModTime = 08.09.96 09:59:27
e:\notes400\data\names.nsf, ModTime = 08.09.96 09:52:00
Show Schedule
Показывает список работ по расписанию, запланированных сервером для выполнения в ближайшее время.
> sh sched
ECURAN/MAPO/RU Mail Routing 21:25 Today
ECURAN/MAPO/RU Replication 21:44 Today
InterTrust/InterTrustCorp/SU Mail Routing 20:25 Today
InterTrust/InterTrustCorp/SU Replication 20:25 Today
Show Stat имя_статистики Выдает статистику о работе сервера. При запуске с параметром выдается только статистика по требуемой теме.
> sh stat
Agent.Daily.AccessDenials = 0
Agent.Daily.ScheduledRuns = 0
Agent.Daily.TriggeredRuns = 5
...
Agent.Hourly.UsedRunTime = 45 Seconds
Comm.NetWare.SPX.StatsLogged = 0
Database.BufferControlPool.Peak = 65406
...
Database.NSFPool.Used = 28570
Disk.C.Free = 8,136,704
...
Disk.L.Size = 629,129,216
Disk.Remote = 5
Mail.AverageDeliverTime = 163
...
MAIL.WaitingRecipients = 0
Mem.Allocated = 3494368
...
Mem.Free = 63,361,024
Mem.PhysicalRAM = 4427776
NET.LAN0.BytesReceived = 32,526
...
NET.LAN0.Sessions.Recycling = 0
NET.LAN4.BytesReceived = 0
...
NET.LAN4.Sessions.Recycling = 0
NET.Log.CN=NotesSrv400/O=InterTrustCorp/C=SU.UnwrittenEntries = 2
NET.SPX.BytesReceived = 3,134
...
NET.SPX.Sessions.Recycling = 0
NET.TCPIP.BytesReceived = 0
...
NET.TCPIP.Sessions.Recycling = 0
Replica.Docs.Added = 0
Replica.Docs.Deleted = 0
Replica.Docs.Updated = 0
Replica.Failed = 13
Replica.Successful = 257
Server.BootID = 2875960
Server.CPU.Count = 1
Server.CPU.Type = Intel Pentium
Server.Name = CN=NotesSrv400/O=InterTrustCorp/C=SU
Server.OpenRequest.MaxUsers = 0
Server.OpenRequest.PreV4Client = 0
Server.OpenRequest.Restricted = 0
Server.OpenRequest.V4Client = 16
Server.Path.Data = e:\notes400\data
Server.Ports = TCPIP,LAN0,LAN4,SPX
Server.Sessions.Dropped = 0
Server.Task = Database Server: Perform console commands
Server.Task = Database Server: Listen for connect requests on SPX
Server.Task = Admin Process: Idle
Server.Tasks = 9
Server.Time.Start = 09/08/96 11:59:32
Server.Title = Win NT 3.51
Server.Trans.PerMinute = 0
Server.Trans.PerMinute.Peak = 35
Server.Trans.PerMinute.Peak.Time = 09/08/96 12:08:35
Server.Trans.Total = 126
Server.Users = 1
Server.Users.1MinPeak = 1
Server.Users.1MinPeakTime = 09/08/96 12:05:33
Server.Users.5MinPeak = 1
Server.Users.5MinPeakTime = 09/08/96 12:05:33
Server.Users.Peak = 2
Server.Users.Peak.Time = 09/08/96 12:06:00
Server.Version.Notes = International English R4.1
Server.Version.W32 = Windows NT 3.51
Stats.Time.Current = 09/08/96 12:57:50
Stats.Time.Start = 09/08/96 11:59:16
> sh stat mail
Mail.AverageDeliverTime = 163
Mail.AverageServerHops = 4
...
MAIL.Dead = 0
...
MAIL.WaitingRecipients = 0
> sh stat mail.Dead
MAIL.Dead = 0
Show Cluster Показывает из кеша данного сервера имя кластера, в который входит этот сервер, список всех членов кластера и их состояние, основываясь на информации, полученной в процессе "исследований" кластера (cluster probes). Каждый сервер в кластере во-первых, постоянно отслеживает собственное состояние, а во-вторых, постоянно "исследует" другие серверы кластера для получения информации об их состоянии.
Если данный сервер не член кластера, выдается сообщение "This system is not configured for a cluster".
> show cluster
Cluster Information
Cluster name: IntTrustCluster, Server name: NotesSrv400/InterTrustCorp/SU
Server cluster probe timeout: 1 minute(s)
Server cluster probe count: 10784
Server availability threshold: 0
Server availability index: 100 (state: AVAILABLE)
Cluster members (2)...
server: InterTrust/InterTrustCorp/SU, availability index: 95
server: NotesSrv400/InterTrustCorp/SU, availability index: 100
Broadcast "сообщение" ["имена пользователей"] Посылает сообщение всем или только указанным пользователям. Если станция пользователя имеет активную сессию с сервером, сообщение появляется у пользователя на панели состояния (Status Bar),
> b "Server will be stopped on 10 minutes"
10:03:28 BROADCAST from NotesSrv400/InterTrustCorp/SU: Server will be stopped on 10 minutes (сообщение отправляется в том числе и серверу)
Рис. 3.2 Фрагмент панели состояния станции с полученным сообщением
Drop "имена пользователей" | All Закрывает перечисленные или все сессии пользователей или серверов.
> drop "Nikolay N. Iontsev/InterTrustCorp/SU"
08.09.96 12:07:25 Closed session for Nikolay N. Iontsev/InterTrustCorp/SU
Databases accessed: 1 Documents read: 1 Documents written: 0
Exit или Quit Останавливает сервер. Рекомендуется предварительно предупредить пользователей, чтобы они успели сохранить выполненные изменения в открытых документах из баз на сервере. Если этого не сделать, пользователи могут потерять эти изменения, если только не сохранят их (как текст) в локальной базе или файле или не дождутся рестарта сервера. Процессы же репликаций и пересылки почты будут остановлены и возобновлены в следующий по расписанию интервал после рестарта сервера.
Pull имя_сервера
[имя_базы] Запускает репликацию в одном направлении: ваш сервер принимает изменения с сервера, имя которого задано в команде.
Если параметр [имя_базы]
не указан в команде, в репликации участвуют все базы данных, реплики которых присутствуют на обоих серверах; если указан - в репликации участвует только заданная база (при условии, что ее реплика имеется на другом сервере).
> pull InterTrust/InterTrustCorp/SU names.nsf
08.09.96 12:10:15 Database Replicator started
08.09.96 12:10:15 Network: Connecting to InterTrust/InterTrustCorp/SU over LAN0
08.09.96 12:10:17 Network: Connected to server InterTrust/InterTrustCorp/SU
08.09.96 12:10:17 Starting replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:17 Finished replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:18 Database Replicator shutdown
> pull InterTrust names.nsf (к вопросу, следует ли указывать полное имя сервера)
08.09.96 12:09:39 Database Replicator started
08.09.96 12:09:39 Network: Connecting to InterTrust/InterTrustCorp/SU over LAN0
08.09.96 12:09:41 Network: Connected to server InterTrust/InterTrustCorp/SU
08.09.96 12:09:42 Starting replication with server INTERTRUST
08.09.96 12:09:42 Access control is set in names.nsf to not allow replication from INTERTRUST names.nsf
08.09.96 12:09:42 Finished replication with server INTERTRUST
08.09.96 12:09:42 Database Replicator shutdown
В последнем случае репликация начинается, но заканчивается неуспешно. В списке управления доступом принимающего информацию сервера только "полное" имя InterTrust/InterTrustCorp/SU имеет доступ менеджера, а заданное в команде "краткое" имя InterTrust отсутствует. Поэтому "краткое" имя InterTrust получает на принимающем информацию сервере только доступ читателя (как -Default-). Следовательно, информация при репликации не может быть записана в базу на принимающем сервере.
Push имя_сервера
[имя_базы] Запускает репликацию в одном направлении: ваш сервер "заталкивает" изменения на сервер, имя которого задано в команде.
> push InterTrust/InterTrustCorp/SU names.nsf
08.09.96 12:10:32 Database Replicator started
08.09.96 12:10:32 Network: Connecting to InterTrust/InterTrustCorp/SU over LAN0
08.09.96 12:10:34 Network: Connected to server InterTrust/InterTrustCorp/SU
08.09.96 12:10:34 Starting replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:34 Finished replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:34 Database Replicator shutdown
Replicate имя_сервера [имя_базы] Запускает репликацию в двух направлениях: ваш сервер сначала принимает изменения с сервера, имя которого указано в команде, а затем "заталкивает" изменения с вашего сервера на другой. Команда обычно используется для выполнения быстрых изменений в репликах баз (не дожидаясь репликации по расписанию) или при тестировании репликационных или коммуникационных проблем.
> rep InterTrust/InterTrustCorp/SU names.nsf
08.09.96 12:10:46 Database Replicator started
08.09.96 12:10:46 Network: Connecting to InterTrust/InterTrustCorp/SU over LAN0
08.09.96 12:10:48 Network: Connected to server InterTrust/InterTrustCorp/SU
08.09.96 12:10:48 Starting replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:48 Finished replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:48 Database Replicator shutdown
Route имя_сервера
Запускает процесс передачи почты на указанный сервер. Команда имеет смысл только при передаче почты через модемные соединения, поскольку при соединениях в пределах одной поименованной сети Notes передача почты выполняется почти немедленно.
Load имя_программы
Запускает программу на сервере. Это может быть как серверная задача, так и иная программа. Она должна находиться в каталоге сервера или в каталогах, в которых операционная система выполняет поиск запускаемых программ.
Tell имя_серверной_задачи команда_для_серверной_задачи Передает cерверной задаче команду. Передаваемая команда зависит от конкретной задачи. Например, команда консоли Tell ROUTER QUIT передает серверной задаче ROUTER команду QUIT - для завершения этой задачи.
Команды на консоль сервера можно "отправлять" и со станции, выбрав в меню File - Tools - Server Administration… , затем выбрав нужный сервер и нажав в окне кнопку Console. Но такой привилегией обладают только администраторы сервера. Список же администраторов сервера задается в адресной книге в документе Server, в поле с меткой Administrators.
"Ответ" сервера на команду появляется в подокне Server response. Отметим, что с версии 4.5 в окне Remote console появилась возможность Live console ("Живая консоль"), позволяющая получать в окне Remote console все команды и сообщения, появляющиеся на консоли сервера, а не только "отклики" сервера на введенные с "удаленной" консоли команды.
Рис. 3.3 Окно удаленной консоли с откликом на команду Show Port Com4
Конфигурирование POPсервера
Серверная задача POP3 позволяет любому клиенту, поддерживающему протокол POP3 (например, Microsoft Internet Explorer, Netscape Navigator или Eudora Pro), получать почту из почтового ящика, находящегося на сервере Notes. Принцип работы этой задачи был рассмотрен в 3.2.17. Здесь обсуждаются вопросы настройки задачи POP3, создания почтового ящика и документа Person для POP3-клиента и настройки программного обеспечения POP3-клиента.Задача POP3 запускается командой консоли Load POP3, а останавливается командой Tell POP3 Quit.
Настройка задачи POP3
К задаче POP3 имеют отношение следующие переменные из файла NOTES.INI.
· MailCharSet = значение. Определяет кодировку, в которой задача POP3 должна передавать сообщения POP3-клиенту. Чтобы POP3-клиент получал сообщения в кодировке Cyrillic KOI-8 (KOI8-R), должно быть задано MailCharSet=3308. Рекомендуем задать нужное значение переменной MailCharSet предварительно, еще до первого запуска задачи POP3 на сервере. Если переменная MailCharSet не определена, задача POP3
воспользуется значением переменной WWWDsp_Codepage (используется задачей WEB), которая в условиях нашей страны обычно равна 81 (Cyrillic Codepage 1251).
· POP3Domain = значение. Задает имя домена Internet для POP3-сервера. Применяется, если домен Internet для POP3-сервера не совпадает с доменом Internet
для сервера Notes, на котором работает задача POP3. Например, POP3Domain=inttrust.rinet.ru.
· POP3Port = значение. Если для протокола POP3
используется порт не со стандартным номером 110, задает номер порта.
· POP3_Enable_SSL = 1. Значение 1 разрешает использовать Secure Sockets Layer (SSL) на сервере POP3. Значение 0 или отсутствие параметра - запрещает.
Регистрация POP3-клиента
Чтобы "зарегистрировать" POP3-клиента, нужно:
· создать для него почтовый ящик по шаблону Mail (R4.5) (MAIL45.NTF) на сервере Notes, "несущем задачу POP3;
· в общей адресной книге создать для него документ Person, в котором:
· в полях First name, Middle initial и Last name указать имя, букву отчества и фамилию клиента;
· в поле User name указать иерархическое имя клиента;
· в поле Short name указать краткое имя (обычно буква имени и вслед за ней, без пробела, фамилия);
· в поле HTTP password задать пароль для клиента;
· в поле Mail System выбрать POP3;
· в поле Domain задать имя домена, которому принадлежит сервер Notes;
· в поле Mail Server указать имя этого сервера Notes;
· в поле Mail File указать путь на файл почтового ящика клиента;
· убедиться, что в поле Encrypt incoming mail выбрано No, поскольку
клиент POP3 не может принимать зашифрованную почту;
· в список управления доступом почтового ящика добавить имя клиента (в точности как было указано в поле User name
документа Person) с уровнем доступа Manager.
Настройка POP3-клиента
Пример настроек, выполняемых для Microsoft Internet Mail в составе Microsoft Internet Explorer, дается на Рис. 10.9 и Рис. 10.10. Однако в данном случае на сервере Notes, установленном на компьютере с хост-именем inttrust.rinet.ru, функционирует не только задача POP3, но и задача SMTPMTA
(агент передачи почты по протоколу SMTP). Поэтому настройки "охватывают" не только вопрос приема почты по протоколу POP3 из почтового ящика клиента с именем Nik N. Iontsev на сервере Notes, но и вопрос отправки исходящей в Internet почты непосредственно из Microsoft Internet Mail по протоколу SMTP через SMTP
MTA
на компьютере с хост-именем inttrust.rinet.ru. Входящие сообщения из Internet для NIontsev@intrust.rinet.ru принимаются SMTPMTA, конвертируются в формат Notes и помещаются в почтовый ящик для Nik N. Iontsev.
Рис. 10.9 Настройки Microsoft Internet Mail в составе Microsoft Internet Explorer
Рис. 10.10 Дополнительные настройки Microsoft Internet Mail в составе Microsoft Internet Explorer
Конфигурирование сервера Domino
Сервер Domino представляет собой задачус именем HTTP, запускаемую на сервере Notes
и позволяющую
клиентам, оснащенным Web-броузерами, получать доступ как к информации из баз данных, находящихся на сервере Notes, так и к HTML-файлам, находящимся в каталогах компьютера сервера Notes. Принцип работы задачи HTTP был рассмотрен в 3.2.16, а здесь уделяется внимание вопросам настройки и эксплуатации этой задачи.
Вопросы разработки в Notes Web-приложений - баз данных,
ориентированных на доступ с использованием Web-броузеров - не рассматриваются в этой книге. Ответы на них вы сможете найти в базе данных Lotus Notes and the Internet (вид Printed Book, категория Chapter 11 Domino Application Developer's Information).
Задача HTTP загружается командой Load http, a завершается командой Tell http quit. Чтобы задача автоматически запускалась при старте сервера, ее имя следует внести в список задач в переменной ServerTasks в файле NOTES.INI. Статистика работы сервера Domino может быть получена командой консоли Show stat domino.
Секция HTTP Server документа Server
Основные настройки задачи HTTP задаются в секции HTTP Server из документа Server
в адресной книге. Рассмотрим, группа за группой, многочисленные поля этой секции.
Рис. 10.5 Группы полей Basics и Operational Information из секции HTTP Server
Группа полей Basics определяет, как сервер контактирует с Web-броузерами.
· TCP/IP port number (по умолчанию 80). Задает номер порта, на котором сервер Domino должен "ожидать" запросы по протоколу HTTP. Стандартно для протокола HTTP используется порт 80. Не используйте значений, меньших чем 1024 (кроме стандартного 80), поскольку они зарезервированы для других прикладных программ TCP/IP. Если задается нестандартный номер порта, клиенты будут вынуждены явно задавать этот номер порта в URL. Например, URL http://domino.lotus.com:8080/ "запрашивает" начальную страницу с хоста domino.lotus.com, который "ожидает" запросы по протоколу HTTP на порту 8080. После изменения номера порта, чтобы эти изменения "вступили в силу", сервер Notes следует перезапустить.
· TCP/IP port status (по умолчанию Enabled). Выбор Enabled разрешает серверу Domino обслуживать запросы по протоколу HTTP, а выбор Disabled - запрещает. Должно быть разрешено обслуживание запросов хотя бы по одному из двух возможных протоколов:
HTTP или HTTPS (SSL). Если обслуживание запрещено по обоим протоколам, Domino не сможет функционировать. Если Domino должен обслуживать запросы только по протоколу HTTPS (SSL), выберите в этом поле Disabled.
· SSL port number (по умолчанию 443). Задает номер порта, на котором сервер Domino должен "ожидать" запросы по протоколу HTTPS (SSL). После изменения номера порта, чтобы изменения "вступили в силу", сервер Notes следует перезапустить.
· SSL port status (по умолчанию Enabled). Выбор Enabled разрешает серверу Domino обслуживать запросы по протоколу HTTPS (SSL), а выбор Disabled - запрещает. Должно быть разрешено обслуживание запросов хотя бы по одному из протоколов HTTP или HTTPS (SSL).
· Host name (по умолчанию пусто).
Поле должно содержать хост-имя компьютера, на котором установлен Domino. Это может быть любое хост-имя, которое определено для вашего компьютера на используемом DNS-сервере. Имя, указанное в поле, "возвращается" броузеру. Если ваш компьютер не имеет зарегистрированного на сервере DNS хост-имени, можно задать в этом поле IP-адрес вашего компьютера. Но при этом случае клиенты будут вынуждены задавать его IP-адрес в URL, например, http://194.220.133.11. Если вы оставляете поле Host name пустым, Domino будет использовать хост-имя, определенное в стеке протокола TCP/IP операционной системы.
· DNS lookup (по умолчанию Disabled). Выберите Enabled, если требуется, чтобы сервер Domino выполнял поиск хост-имени каждого своего клиента, обращаясь к серверам DNS. Выбор Enabled несколько ухудшает эффективность работы сервера Domino, однако в протоколах работы сервера Domino будут содержаться хост-имена клиентов, а не IP-адреса, и в фильтрах протоколирования вы сможете использовать как маски на основе хост-имен клиентов, так и маски на основе IP-адресов клиентов. Если же выбрано Disabled, сервер Domino не обращается к серверам DNS для определения хост-имени клиента.
Выбор Disabled улучшает эффективность работы сервера Domino, однако в протоколах работы Domino будут содержаться только IP-адреса клиентов и в фильтрах протоколирования вы сможете использовать маски только на основе IP-адресов клиентов.
· Default home page (по умолчанию default.htm). Если в качестве начальной страницы (home page) должен использоваться файл в формате HTML, укажите в этом поле имя этого файла. Тогда при обращении клиента к серверу Domino без явного указания нужной страницы Domino
будет просто загружать клиенту этот файл. HTML-файл должен располагаться в каталоге domino\HTML, а поле Home
URL (в группе полей Mapping) должно быть пустым. Если же в качестве начальной страницы должен использоваться документ About или навигатор из базы данных Notes, оставьте в этом поле значение по умолчанию, но в поле Home
URL укажите соответствующий URL, например, что-то подобное http://domino.lotus.com/domino.nsf?OpenDatabase для документа About или http://domino.lotus.com/domino.nsf/Main+Navigator?OpenNavigator
для навигатора.
· Maximum active threads (по умолчанию 40). Задает максимально возможное количество параллельно работающих подпроцессов (thread's), порождаемых задачей HTTP. Если заданный максимум достигнут, сервер Domino "отказывается отвечать" на новые запросы, пока уже принятые им запросы не будут обслужены и исполнявшие их подпроцессы не освободятся. Чем более мощный компьютер используется в качестве сервера, тем и большее максимально возможное количество подпроцессов должно задаваться в этом поле. Однако выбор слишком большого значения может привести к излишней трате ресурсов компьютера на "прокачку страниц" между оперативной памятью и файлом страниц. На платформе Windows NT рекомендуется экспериментально исследовать этот вопрос с применением приложения Performance Monitor.
· Minimum active threads (по умолчанию 20). Задает минимальное количество подпроцессов, всегда поддерживаемых задачей HTTP. Сервер Domino не будет закрывать подпроцессы "ниже этого минимума", даже если они неактивны, т.е. не обслуживают запросы. Подпроцессы же "сверх этого минимума" при переходе в неактивное состояние будут закрываться задачей HTTP
и открываться снова, когда это требуется.
Группа полей Operational Information управляет кэшированием, определяет используемый формат и стиль отображения графики, отображение видов и используемый набор символов.
Управление кэшированием.
· Cache directory (по умолчанию domino\cache). Определяет каталог, который сервер Domino должен использовать для сохранения графических и присоединенных файлов. Когда клиент запрашивает страницу с элементами графики, Domino преобразует каждый графический элемент в файл соответствующего графического формата, передает файл клиенту и сохраняет копию файла в каталоге кэша. Если Domino получает другой запрос на ту же самую страницу, он уже передает клиенту соответствующие файлы непосредственно из кэша. То же самое происходит и с присоединенными файлами - будучи "отсоединенными" из документа Notes для передачи клиенту, они "попадают" в кэш, а откуда в течение некоторого времени могут повторно использоваться Domino. Если в поле указывается не полный путь, то считается, что он был задан относительно каталога данных Notes.
· Garbage collection (по умолчанию Enabled) и Garbage collection interval (по умолчанию 60 минут). Чтобы не допустить "разрастания" кэша сверх максимального размера, рекомендуется разрешить (выбором значения Enabled в поле Garbage collection) периодическое выполнение сервером Domino процесса "уборки мусора". Процесс "уборки мусора" удаляет файлы из кэша, начиная с наименее часто используемых. Период, с которым запускается процесс "уборки мусора", запускается в поле Garbage collection interval.
· Maximum cache size (по умолчанию 50 MB). Максимальное количество дискового пространства, доступного для кэша (в МБ). Размер кэша обычно остается ниже заданного максимума, но может иногда становиться и немного большим. Когда максимальный размер кэша достигнут, автоматически запускается процесс "уборки мусора". Если никакое значение не задано (поле Maximum cache size пустое), сервер Domino вообще не применяет кэширование.
· Delete cache on shutdown (по умолчанию Disabled). Если выбрано Enabled, Domino будет "очищать кэш" при остановке сервера Notes. Если же выбрано Disabled, при перезапусках сервера Notes кэш будет сохраняться.
Формат и стиль отображения графики.
· Image conversion format (по умолчанию GIF). Domino может преобразовывать графические элементы из форм и документов Notes или в формат GIF, или в формат JPEG. В зависимости от того, какой из форматов был выбран вами в данном поле, будут присутствовать или отсутствовать следующие поля.
· (Выбран GIF) Interlaced rendering (по умолчанию Enabled). Если выбрано Enabled, Domino создает GIF-файлы в "чередуемом" формате. В GIF-файле "чередуемого" формата строки изображения сохранены не в обычной последовательности (строка за строкой от первой
до последней), а, например, вначале каждая восьмая строка изображения, затем каждая четвертая строка изображения, затем каждая вторая строка... Поэтому GIF-файл "чередуемого" формата в процессе загрузки в броузер отображается в окне броузера, как бы "приобретая все более и более четкие очертания". Поскольку глаз человека обладает свойством "восстанавливать" отсутствующие части изображения, у клиента создается впечатление, что загрузка изображения происходит быстро. Если же выбрано Disabled, Domino создает файлы GIF в обычном формате - такое изображение в окне броузера появляется "сверху вниз строка за строкой".
· (Выбран JPEG) Progressive rendering (по умолчанию Enabled). Если выбрано Enabled, Domino создает JPEG-файлы в "прогрессирующем" формате. Броузеры обычно загружают и отображают JPEG-файл обычного формата за один проход. JPEG-файл в "прогрессирующем" формате загружается и отображается за несколько проходов: изображение в окне броузера с каждым проходом приобретает "все более и более четкие очертания". В результате клиент может "идентифицировать" возникающее изображение прежде, чем оно полностью загружено в броузер.
· (Выбран JPEG) JPEG image quality (по умолчанию 75). Целое число в диапазоне от 5 до 100 (процентов), определяющее "качество изображения" в создаваемом Domino JPEG-файле. Большие значения - больший по размеру файл и лучшее качество изображения, малые значения - меньший по размеру файл, меньшее количество времени на загрузку, но более низкое качество изображения.
Отображение информации из вида и используемый набор символов.
· Default lines per view (по умолчанию 30). Количество "линий" из вида в базе данных Notes, "показываемое" сервером Domino в броузере на один запрос. Учтите, что эта установка используется для всех баз на сервере.
· Default character set group (по умолчанию Western). Набор символов, в котором HTML-текст будет предоставляться клиенту. Такой же набор символов должен поддерживаться и на компьютере клиента. Возможные варианты: Western, Central European, Japanese, Traditional Chinese, Simplified Chinese, Korean, Cyrillic, Greek, Turkish, Thai и Multilingual. Чтобы обеспечить поддержку русских букв, выбирают Cyrillic.
· Character set mapping (по умолчанию Latin1). Сервер Domino использует заданный в поле Default character set group набор символов и заданную в поле Character set mapping (Рис. 10.6) таблицу кодов символов при создании HTML-текста для броузера. Выбор в поле Character set mapping зависит от выбора в поле Default character set group. Если Default character set group
= Cyrillic, в поле Character set mapping можно выбрать таблицы кодов символов ISO-8859-5, CP1251 или KOI8-R.
Рис. 10.6 Группы полей Mapping, Logging, Timeouts и Character Set Mapping из секции HTTP Server
Группа полей Mapping задает местоположение HTML-файлов для сервера Domino. Учтите, что на одном компьютере "под одним сервером Notes" может функционировать несколько виртуальных серверов Domino (рассматривается ниже). В этом случае для каждого виртуального сервера Domino информация из группы полей Mapping "перекрывается" аналогичной информацией из документов Virtual Server базы данных DOMCFG.NSF.
· HTML directory (по умолчанию domino\html). Каталог для HTML-файлов. Если указан не полный путь, он "отсчитывается" относительно каталога данных Notes.
· Home URL
(по умолчанию /?Open). Укажите URL документа About, навигатора или иного элемента из базы данных Notes, HTML-образ которых Domino должен возвращать, когда клиенты "входят на сервер", не указывая явно (например, http://domino.lotus.com) требуемый им каталог или страницу. Использование значения по умолчанию /?Open влечет отображение списка баз данных на сервере (как по File - Database - Open в клиенте Notes). Для документа About
из базы данных URL выглядит подобно http://domino.lotus.com/domino.nsf?OpenDatabase, для навигатора из базы данных подобно http://domino.lotus.com/domino.nsf/Main+Navigator?OpenNavigator. Полное же описание
синтаксиса URL, поддерживаемого сервером Domino, вы сможете найти в базе данных Lotus Notes and the Internet
(вид:
Printed Book, категория: Chapter 11 Domino Application Developer's Information, документ: About the Domino URL commands). Но если вы используете начальную страницу (home page) непосредственно в формате HTML, очистите поле Home URL и укажите имя HTML-файла в поле Default home page.
· CGI URL path (по умолчанию /cgi-bin). Укажите URL-путь к каталогу программ CGI на сервере Domino. Этот путь, указываемый клиентом в URL.
· CGI directory (умолчанию domino\cgi-bin). Каталог для программ CGI. Если указан не полный путь, он "отсчитывается" относительно каталога данных Notes.
· Icon URL Path
(по умолчанию /icons). Укажите URL-путь к каталогу пиктограмм Domino. Этот путь, указываемый клиентом в URL. В большинстве случаев вы не должны изменить значения этого поля. Только если вы имеете собственный существующий каталог пиктограмм, укажите в поле URL-путь для доступа к этому каталогу.
· Path to icons (по умолчанию domino\icons). Каталог пиктограмм. Если указан не полный путь, он "отсчитывается" относительно каталога данных Notes.
Группа полей Timeouts задает временные ограничения для контактов между сервером Domino и Web-клиентом.
· Idle thread timeout (по умолчанию 0 минут). Интервал времени в минутах, в течение которого сервер Domino не должен закрывать неактивный подпроцесс. Подпроцесс становится неактивным после того, как он выполнил свой последний запрос. Если текущее количество подпроцессов больше, чем указано в поле Minimum active threads, и сервер Domino не использует некоторый подпроцесс в течение заданного интервала времени, сервер закрывает этот подпроцесс. Чтобы Domino вообще не закрывал неактивные подпроцессы, в поле задают значение 0.
· Input timeout
(по умолчанию 2 минуты). Максимальное время в минутах с момента установления клиентом HTTP-соединения с сервером Domino до посылки клиентом запроса на ресурс (GET URL). Если клиент не посылает запрос за заданное время, сервер Domino разрывает HTTP-соединение с ним.
· Output timeout
(по умолчанию 20 минут). Максимальное время в минутах, отводимое на передачу данных сервером Domino клиенту. По истечении этого времени сервер Domino "разрывает" HTTP-соединение с клиентом. Ограничение касается запросов на получение локальных файлов и информации из баз данных Notes, но не касается запросов, выполнение которых влечет запуск программ CGI.
· CGI timeout
(по умолчанию 5 минут). Максимальное время в минутах, отводимое на работу программе CGI, запущенной сервером Domino. Когда отведенное время истекает, сервер Domino
посылает программе CGI сообщение. Затем, еще через пять минут, сервер Domino "уничтожает" эту программу.
Протоколирование обращений к серверу Domino
По каждому HTTP-запросу, выполняемому броузером, сервер Domino способен протоколировать следующую информацию:
с какого IP-адреса (или DNS-имени) поступил запрос, какой броузер использует клиент, какой URL использовался для доступа, сколько байт передано, какие ошибки (если были) сгенерированны программами CGI. Протоколируемая информация может быть сохранена или в текстовом файле, или в базе данных Notes с именем DOMLOG.NSF, или в обоих местах сразу. Протоколирование в базу данных Notes обычно более удобно, но оно требует привлечения несколько больших ресурсов компьютера, чем протоколирование в текстовый файл.
Чтобы установить протоколирование в базу Notes, создайте базу данных DOMLOG.NSF в каталоге данных Notes по шаблону Domino Web Server Log (DOMLOG.NTF). Чтобы установить протоколирование в текстовый файл, заполните поля Access Log
(каталог для файлов протокола доступа) и Error Log (каталог для файлов протокола ошибок) в секции HTTP server документа Server (Рис. 10.6). Если установлены оба способа протоколирования, Domino записывает информацию в оба места. Поле Time stamp определяет формат, в котором записывается время обращения. Поле No Log
может содержать список тех IP-адресов, DNS-имен (если выбрана опция DNS Lookup) или их шаблонов, доступ с которых не должен протоколироваться.
Действие поля No Log распространяется как на протоколирование в базу Notes, так и на протоколирование в текстовый файл.
Чтобы отказаться от протоколирования в базу DOMLOG.NSF, удалите эту базу. Чтобы отказаться от протоколирования в текстовые файлы, "очистите" поля Access Log и Error Log в секции HTTP server документа Server.
Секция Security документа Server
Рассмотрим поля из секции Security
документа Server, относящиеся к вопросам безопасности сервера Domino.
Рис. 10.7 Секция Security документа Server
· Allow anonymous HTTP connections (по умолчанию Yes). Если в поле выбрано Yes, сервер Domino допускает анонимные HTTP-подключения. Каждый анонимный HTTP-клиент "будет фигурировать" на сервере под именем Anonymous. Доступ такого анонимного HTTP-клиента в каждой базе Notes определяется прежде всего списком управления доступом этой базы: как Anonymous или, если в ACL отсутствует имя Anonymous, как -Default-, но не выше максимального уровня доступа для HTTP-клиентов (Maximum internet brouser access). Если же в поле выбрано "No", сервер Domino вообще не допускает анонимных подключений. Тогда все HTTP-клиенты получают запрос на ввод имени и пароля при обращении к серверу Domino
и получают к нему доступ, только если они правильно указали имя и пароль, определенные для них в документе Person (пароль задается в поле с меткой HTTP Password:). В этом случае для "авторизованных" HTTP-клиентов уровень доступа для Anonymous
в списках управления доступом баз утрачивает смысл.
· Allow HTTP clients to browse databases (по умолчанию Yes). Если в поле выбрано Yes, HTTP-клиенты, указав URL http://host-name/?OpenServer, смогут получить список баз данных на сервере Notes. Когда же выбрано No, HTTP-клиенты не смогут получить список имеющихся на сервере баз, но смогут открывать конкретные базы данных, если знают их имена файлов и имеют к ним доступ.
· SSL key file (default=keyfile.kyr). Если сервер Domino сконфигурирован для SSL-транзакций, он может шифровать данные, передаваемые между сервером и HTTP-клиентом. Если такая возможность выбрана, в процессе шифрования используется указанный в данном поле файл.
Виртуальные серверы Domino (hosting multiple sites on one server)
На одном компьютере, "несущем" один сервер Notes
и одну задачу HTTP, может функционировать несколько виртуальных серверов Domino. Каждый виртуальный сервер Domino имеет собственные IP-адрес, Home URL, начальную страницу и каталоги HTML, CGI и Icons, но при этом структура каталога данных Notes для всех виртуальных серверов Domino остается одинаковой.
Подчеркнем, что каждый из виртуальных серверов Domino должен иметь свой собственный уникальный IP-адрес. Недостаточно иметь много DNS-имен, "отображенных" на один и тот же IP-адрес. Количество виртуальных серверов Domino
ограничивается только имеющимся оборудованием компьютера и способностью используемой операционной системы поддерживать для сетевых устройств компьютера (сетевой карты или модема, которым поддерживается PPP-соединение) соответствующее количество IP-адресов.
На сервере Notes создается база данных DOMCFG.NSF по шаблону Domino Configuration (DOMCFG.NTF). В этой базе для каждого "очередного" виртуального сервера Domino создается документ Virtual Server. Чтобы выполненные изменения "вступили в силу", перезапускают задачу HTTP. Таким образом, настройки для "первого" сервера Domino задаются в секции HTTP Server из документа Server, а настройки "очередных" получаются из настроек "первого" сервера Domino
заменой значений одноименных полей на значения из соответствующего документа Virtual Server.
Рис. 10.8 Документ Virtual Server
Обратите внимание, что в базе DOMCFG.NSF
имеются еще три могущие оказаться полезными формы для создания документов:
· Mapping URL ®
Directory - для перемещения каталогов HTML, CGI, images и других в новое местоположение без изменения URL, используемых клиентами для доступа к ним;
· Mapping URL ®
URL - для автоматической замены входящего URL на другой, соответствующий реальному местоположению на этом же HTTP-сервере;
· Redirection URL ®
URL - для автоматической замены входящего URL на другой, в том числе и расположенный на другом HTTP-сервере.
Кратко об ID-файле пользователя
Каждый сервер или пользователь Notes имеет свой уникальный ID - ассоциированный с сервером или пользователем уникальный файл. ID-файл идентифицирует своего владельца, как паспорт гражданина.ID-файл создает сертификатор (certifier) - лицо, имеющее специальный ID-файл - так называемый ID-файл сертификатора. ID-файл сертификатора необходим только для сертификации ID-файлов пользователей и серверов. ID-файл сертификатора можно рассматривать как "печать-инструмент", с помощью которого сертификатор "ставит печать-оттиск" в ID-файл пользователя, т.е. добавляет в него сертификат.
При создании в ID-файл включаются:
· имя владельца ID (оно может быть изменено сертификатором в дальнейшем)
· тип и номер лицензии Notes
· сертификат ("печать-оттиск"), обеспечивающий серверу возможность аутентифицировать пользователя (устанавливать его подлинность), а станции пользователя в свою очередь аутентифицировать сервер. Когда вы впервые в сеансе работы пробуете открыть базу данных на сервере, сервер "заглядывает" в ваш ID, чтобы убедиться, имеете ли вы и этот сервер сертификат от одного и того же сертификатора. Если имеете, обычно доступ разрешается; если нет, доступ обычно отклоняется. Дополнительно на решение вопроса о предоставлении доступа могут повлиять взаимные сертификаты (но они хранятся не в ID-файлах, а в адресных книгах) и настройки в документе Server из общей адресной книги
· публичный ключ, используемый при шифровании почты и обеспечении "электронной подписи". Его копия заносится также в общую адресную книгу и становится доступной другим пользователям домена
· личный ключ, используемый при шифровании почты и обеспечении "электронной подписи". Он имеется только в ID-файле и нигде более. Невозможно извлечь личный ключ из ID-файла или создать новый ID-файл с таким же личным ключом. Однако сам ID-файл (вместе с хранящимся в нем личным ключом) может быть похищен
· пароль, применяемый для предотвращения неавторизованного доступа к базам на серверах с использованием вашего ID-файла.
После создания в ID-файле может быть:
· изменен пароль
· добавлены, удалены дополнительные ключи шифрования (они используются при шифровании полей в документах)
· заменены личный и публичный ключи.
Для исследования или изменения содержимого вашего ID-файла используйте диалоговое окно, получаемое из меню File - Tools - User ID.
Локальное шифрование баз данных
Пользователи с доступом менеджера к локальной базе данных (все, если опция Enforce a consistent Access Control List... не выбрана, или только указанные в ACL базы, если эта опция выбрана), могут "локально зашифровать" эту базу. Локальное шифрование осуществляется с использованием ID-файла пользователя (сервера). Такая возможность предотвращает доступ к данной базе или ее копии, сделанной средствами операционной системы, со станции Notes под другим ID-файлом.При локальном шифровании базы данных Notes генерирует случайный ключ шифрования, использует его для шифрования информации в базе (криптосистема DES), а сам этот ключ шифрования шифрует публичным ключом используемого ID-файла (криптосистема RSA) и добавляет в зашифрованном виде в базу данных. Когда пользователь (сервер) пытается обращаться к локальной базе данных, Notes обеспечивают доступ только тогда, когда личный ключ в ID-файле этого пользователя позволяет расшифровать ключ шифрования (криптосистема RSA), используемый для шифрования информации в базе (криптосистема DES).
Пользователь может выбрать один из трех уровней шифрования. Выбор уровня шифрования основан на компромиссе трех факторов: степень защиты, быстродействие при доступе к базе и возможность применять средства сжатия (не Notes) для этой базы.
| Уровень шифрования | Степень защиты | Быстродействие при доступе | Применение сжатия | ||||
| Simple | Минимальная | Высокое | Да | ||||
| Medium | Средняя | Высокое | Нет | ||||
| Strong | Высокая | Более низкое | Нет |
Шифрование Simple удобно для предотвращения доступа к базе "взломщика" среднего уровня, и оно допускает применение средств сжатия для базы. Шифрование Strong обеспечивает наибольшую степень защиты, но неблагоприятно отражается на скорости доступа. Шифрование Medium - значение по умолчанию - дает большую скорость доступа, чем при шифровании Strong, но предлагает сравнимую со Strong степень защиты.
Локальное шифрование баз данных разработано для того, чтобы предотвратить несанкционированный локальный доступ к базе, оно вовсе не предназначено для замены шифрования на уровне полей в документе.
Локальное шифрование выбирается кнопкой Encryption в окне свойств базы.
Рис. 9.11 Нажимаем кнопку Encryption…
Рис. 9.12 Выбор локального шифрования
В следующем окне выбираем локальное шифрование (радиокнопкой Locally encrypt this database using …) и его уровень (выпадающий список), используемый ID-файл (обычно, текущий) и нажимаем кнопку Ok. Начинается процесс шифрования, "прогресс" которого отображается в окне. В этом же окне можно отменить локальное шифрование для уже зашифрованной базы, выбрав Do not locally encrypt this database.
Если другой пользователь (под другим ID-файлом) попытается получить доступ к базе с локальным шифрованием, он получит следующее диалоговое окно.
Рис. 9.13 Вашему ID-файлу к этой базе данных доступа нет
Mail-In Database - база, способная получать почту
Документы формы Mail-In Database используются для описания баз данных, в которые пользователи могут посылать почту. Документ означает, что любое письмо, отправленное по адресу, который совпадает с указанным в поле с меткой Mail-in name:, должно доставляться на сервер Server: из домена Domain: и помещаться на нем в базу данных Filename:. Исполняет "содержащееся в документе утверждение" серверная задача Mail Router.
Рис. 4.15 Пример документа Mail-In Database
Mail Transfer Agent's - агенты передачи почты
Функция агента передачи почты состоит, во-первых, в преобразовании сообщений Notes в формат "чужой" почтовой системы и доставке их по этой почтовой системе адресату, и, во-вторых, в приеме сообщений из другой почтовой системы, преобразовании их в формат сообщений Notes и доставке адресату по почте Notes. В отличие от почтового шлюза (mail gateway) агент как бы "двулик": со стороны "чужой" почтовой системы он "выглядит" как полнофункциональный почтовый сервер этой системы, а со стороны Notes - как сервер Notes, выполняющий функцию доставки почты. Шлюз же, в отличие от агента, не имеет в своем составе почтовый сервер "чужой" почтовой системы. Он способен лишь конвертировать сообщение в "чужой" формат и передать его, как файл, почтовому серверу "чужой" почтовой системы для доставки, и, в обратную сторону, получив как файл, сообщение от почтового сервера "чужой" почтовой системы, преобразовать его в формат Notes и организовать доставку.В настоящее время компанией Lotus выпущены следующие MTA:
· SMTP MTA - обмен сообщениями с почтовыми системами, поддерживающими протокол SMTP (платформы Windows NT, OS/2, UNIX, версия 1.06),
· Х.400 MTA - обмен сообщениями с почтовыми системами стандарта Х.400 (платформы Windows NT и OS/2, версия 1.01),
· cc:Mail MTA - обмен сообщениями с cc:Mail (платформы Windows NT и OS/2).
Далее подробно рассматривается принцип работы SMTP MTA и документы, которыми выполняется его настройка.
Мониторинг доставки почты
Нормальная работа системы доставки почты слишком критична для пользователей. Поэтому администратор должен ежедневно наблюдать за функционированием системы доставки.MAIL.BOX
В нем следует обращать внимание на количество ждущих отправки сообщений, на "мертвые" сообщения, а так же на количество свободного места на диске, содержащем эту базу.
Notes Log
В протоколе работы сервера есть вид Mail Routing Events, содержащий относящиеся к доставке почты события. Можно также управлять подробностью протоколирования в этом виде почтовых событий.
Серверная задача Reporter
Если она используется, то регулярно протоколирует статистику доставки почты в базе Statistics Reporting (STATREP.NSF). Администратор должен просматривать соответствующий вид в этой базе.
Серверная задача Event
Позволяет протоколировать отдельные группы событий, в том числе и связанные с доставкой почты.
Команды, передаваемые Mail Router
· Tell Router Delivery Stats - показывает статистику о доставке почты.
· Tell Router C
- уплотняет MAIL.BOX.
· Tell Router Show Queues - показывает сообщения, передаваемые на другие серверы.
· Tell Router Quit
- завершает задачу.
> tell router delivery stats
Message Sizes Minimum Average Maximum
1 K 214 K 40010 K
Delivery Times Minimum Average Maximum
00:00:01 00:03:56 07:31:14
Server Hops Minimum Average Maximum
1 Hops 1 Hops 8 Hops
> tell router C
03.09.96 18:13:40 Router: Shutdown is in progress
03.09.96 18:13:40 Router: Beginning mailbox file compaction
03.09.96 18:13:45 Router: Completed mailbox file compaction
> tell router show queues
Server Name Msgs Ready
Max Threads = 4; Total Threads = 1; Inactive Threads = 0
Настройка сетевых портов
Если сервер должен работать по нескольким сетевым протоколам, необходимо настроить порты. Настройки сетевых портов для сервера выполняются со станции Notes, запущенной на компьютере, где установлен сервер Notes, но при условии, что программа сервера Notes остановлена. Аналогично выполняются и настройки сетевых портов для станции Notes.Выбор в меню File - Tools - User Preferens и далее закладки Ports даст диалоговое окно, используемое для настройки портов.
Рис. 2.18 Настройка портов
В списке Communication Ports: перечислены имеющиеся порты. Галочкой отмечены используемые порты. Часть портов в этом списке не используется. Чтобы задействовать неиспользуемый порт, достаточно выбрать порт в списке и включить флажок Port Enabled или дважды щелкнуть мышью по названию порта. Аналогично поступают, чтобы сделать порт неактивным. Кнопка New служит для добавления нового порта, Rename - для изменения имени существующего порта, Delete Port - для удаления порта, а Show Status - для отображения текущего состояния порта.
Рис. 2.19 Добавление нового порта
Имя порта (при добавлении нового порта или изменении имени существующего) можно задать любым. "Область действия" имени порта - только данный сервер или станция. Драйвер - название драйвера Notes, который должен обслуживать данный порт: NETBIOS - драйвер для поддержки протокола NetBIOS, NWSPX - драйвер для поддержки протокола Novell SPX, TCP - драйвер поддержки протокола TCP/IP (Windows 95/NT, Novell NetWare, OS/2), XPC - драйвер для поддержки последовательного порта и управления подключенным к нему модемом. Ошибиться в имени драйвера при создании нового порта невозможно - в версиях 4.х оно выбирается из раскрывающегося списка. Каждый драйвер порта реализуется соответствующей библиотекой динамической компоновки, входящей в комплект поставки. Только драйверы портов X.25 и SNA поставляются отдельно, а не в комплекте поставки Notes.
Для некоторых портов (это зависит от используемого драйвера порта) становится доступной кнопка <имя драйвера> Options. При нажатии кнопки появляется окно для задания специфической информации для конкретного драйвера.
Рис. 2.20 Для драйвера NETBIOS на сервере необходим номер Unit/Lana
Рис. 2.21 Для драйвера NETBIOS на станции возможно автоматическое определение номера Unit/Lana
Для портов сервера Notes, обслуживаемых драйвером NETBIOS, необходимо явно задавать номер Unit/Lana. Номер Unit/Lana используется только драйвером NETBIOS. Это связано с тем, что NetBIOS - "высокоуровневый интерфейс", и он всегда реализуется по какому-то "более низкоуровневому" протоколу (Novell IPX, TCP/IP, NETBEUI…). На одном компьютере (обычно, сервере Notes) может быть установлено несколько интерфейсов NetBIOS, но при этом каждый из них реализуется по разным "низкоуровневым" протоколам. Чтобы различать "разные реализации" NetBIOS, используется номер Unit/Lana.
Наиболее наглядно значения Unit/Lana можно наблюдать в настройках интерфейсов NetBIOS для компьютера под Windows NT (Рис. 2.22 - Рис. 2.24). В этом примере на сервере имеется два порта NETBIOS, например, с именами LAN0 и LAN4. Пусть для порта LAN0 задан Lana Number 0, что соответствует интерфейсу NetBIOS, реализуемому "поверх" Novell IPX, а для порта LAN4 - Lana Number 4, что соответствует интерфейсу NetBIOS, реализуемому "поверх" NETBEUI. Таким образом, к этому серверу могут получить доступ два типа клиентов Notes.
Во-первых, клиенты Notes, на компьютерах которых установлена поддержка протоколов Novell IPX/SPX
и интерфейса NetBIOS поверх Novell IPX (например, NetWare Client for Windows 3.1). На таком клиенте Notes в настройках порта, обслуживаемого драйвером NETBIOS
(обычно порт с именем LAN0), выбирают Automatic setup. Такой клиент будет получать доступ к серверу по "серверному" порту, поддерживающему интерфейс NetBIOS "поверх" Novell IPX (порт сервера LAN0).
Рис. 2.22 Несколько интерфейсов NetBIOS, каждый реализуется по своему "низкоуровневому" протоколу
Рис. 2.23 NetBIOS "поверх" NW Link IPX имеет Lana Number 0
Рис. 2.24 NetBIOS "поверх" NETBEUI (NBF) имеет Lana Number 4
Во-вторых, клиенты Notes, на компьютерах которых установлена поддержка сети Microsoft c интерфейсом NetBIOS (например, Windows 3.11 или Windows 95). При этом неявно имеется в виду, что интерфейс NetBIOS реализуется "поверх" NETBEUI. На таком клиенте Notes в настройках порта, обслуживаемого драйвером NETBIOS
(обычно порт с именем LAN0), также выбирают Automatic setup. Такой клиент будет получать доступ к серверу по "серверному" порту, поддерживающему интерфейс NetBIOS "поверх" NETBEUI (порт сервера LAN4).
Для драйвера NWSPX "вопросы" касаются использования NDS (Novell NetWare версий 4.х) и (или) Bindery Services (Novell NetWare версий 3.11, 3.12). Учтите, что работа сервера Notes по протоколу SPX в сети на базе Microsoft Windows NT, имеющей несколько сегментов, но не имеющей ни одного файл-сервера Novell NetWare, невозможна. Кроме того, для клиентов Notes на станциях Windows NT в такой ситуации желательно устанавливать NetWare Client for Windows NT, причем самых последних версий, за которыми рекомендуем обращаться на сервер www.novell.com компании Novell.
Рис. 2.25 Настройки для драйвера NWSPX
Для драйвера TCP задается только величина таймаута (в секундах) при попытке установить соединение.
Рис. 2.26 Настройки для драйвера TCP
Все выполненные вами настройки портов "запоминаются" в файле NOTES.INI (см. 2.3).
Для сервера информацию о сетевых портах необходимо также вручную перенести в документ Server в адресной книге, в таблицу Network Configuration. Если этого не сделать, то сервер будет использовать только один порт и сеть Notes, занесенные в таблицу во время установки сервера. Ниже дается пример таблицы Network Configuration.
Рис. 2.27 Фрагмент документа Server - используются три порта
В этой таблице Port
- имя порта - вводится точно так, как вы его задали или выбрали при настройке порта. Notes Network - название поименованной сети Notes (см. пункт 1.4.3), доступной по этому порту. Net Address - сетевой адрес - для драйверов NETBIOS и NWSPX указывается крайняя левая компонента (CN) из полного имени сервера Notes, для драйвера TCP - IP-адрес или хост-имя этого сервера Notes (подобно 197.94.222.84 или flintstone.acme.com), для иных драйверов - смотрите во входящей в комплект поставки сервера книге Network Configuration Guide. И, наконец, Enabled - флажок, разрешающий или не разрешающий серверу использовать данный порт.
После произведенных исправлений в документе Server запустите сервер и проверьте работоспособность его портов - либо со станции администратора, запущенной на том же компьютере, используя в окне Рис. 2.18 кнопку Show status, либо командой консоли Show Port
имя_порта.
Назначение ID-файлу множественных паролей
Если вы имеете информацию, которая должна охраняться так, чтобы только несколько одновременно присутствующих пользователей, но не каждый в отдельности, смогли получить к ней доступ, вы можете зарегистрировать фиктивного пользователя и назначать его ID-файлу множественные пароли. Имя фиктивного пользователя может быть указано в ACL баз для обеспечения доступа к ним, в ID-файле фиктивного пользователя могут содержаться ключи шифрования, обеспечивая шифрование документов в базах, и, наконец, фиктивный пользователь может получать шифрованную почту. Затем вы "добавляете реальных пользователей" в этот ID-файл. Каждому из реальных пользователей назначается свой собственный пароль. В свойствах ID-файла с множественными паролями указывается количество реальных пользователей (как минимум один, но обычно два или более), которые должны собраться вместе и последовательно ввести свои пароли, чтобы стало возможным воспользоваться таким ID-файлом. Например, вы можете назначать четыре пароля для ID-файла, но требовать ввода только любых двух из четырех паролей, чтобы воспользоваться этим ID-файлом. Но возможен и "вырожденный" вариант, когда назначается несколько паролей, но для того, чтобы воспользоваться ID-файлом, необходимо ввести любой из этих паролей. Множественные пароли могут быть назначены и существующему ID-файлу. Любой пароль, назначенный ID-файлу до назначения ему нескольких паролей, после назначения нескольких паролей перестает действовать.Такая возможность полезна, когда вы не хотите давать полномочий пользоваться ID-файлом сертификатора одному лицу, а как минимум двум одновременно присутствующим лицам.
Вы можете также использовать эту возможность, чтобы создать "безопасный" архив ID-файлов пользователей в виде присоединенных файлов в документах некоторой базы данных. Для этой базы рекомендуется применить "локальное шифрование" на основе ID-файла, для использования которого требуется несколько паролей. Тогда, чтобы обратиться к этой базе за ID-файлом пользователя, который забыл свой пароль, "испортил" или "утерял" свой ID-файл, будет необходимо присутствие нескольких уполномоченных лиц, каждый из которых знает только свой пароль.
Назначение ключей шифрования к полям
Ключи шифрования могут назначаться документу разными путями.1. Разработчик может выбрать в окне свойств формы один или несколько ключей шифрования, используемых для шифрования документов, созданных по данной форме.
Рис. 9.28. Выбор ключей шифрования "по умолчанию" в форме
В каждом документе, созданном по этой форме, шифруемые поля будут шифроваться всеми выбранными для формы ключами.
2. Разработчик разрешает шифрование для полей, но не делает выбор ключей шифрования "по умолчанию" в форме. Создатель документа может выбрать ключи шифрования для каждого документа в отдельности в окне свойств этого документа
Рис. 9.29. Выбор ключа шифрования для документа
Если создатель документа не выберет ни одного ключа шифрования, шифрование полей выполняться не будет.
Если в форме нет шифруемых полей, а пользователь делает попытку шифровать создаваемый по форме документ, он получит следующее сообщение об ошибке "No encryptable fields found in document. Encryptable fields must be specified in form".
3. Разработчик добавляет в форму предопределенное поле с именем SecretEncryptionKeys. В это поле в формате текстового списка каким-либо способом добавляется список названий ключей шифрования.
4. Разработчик использует для назначения ключей шифрования документу возможности встроенных классов LotusScript.
По своей внутренней реализации в Notes все эти способы ничем не отличаются. В документе всегда появляется предопределенное поле SecretEncryptionKeys, содержащее текстовый список названий ключей шифрования. Вместо каждого шифруемого поля появляется поле $SealData, в котором, используя окно свойств документа на закладке Fields, удается "прочитать" настоящее название соответствующего шифруемого поля. И, наконец, появляется только одно на весь документ поле $Seal, которое и содержит в зашифрованном виде информацию из всех шифруемых полей документа. Наблюдения за размером поля $Seal в зависимости от количества использованных ключей шифрования позволяют сделать вывод, что каждый новый ключ "добавляет" в поле $Seal еще один экземпляр зашифрованных этим ключом данных. Становится понятно, почему для того, чтобы расшифровать информацию, достаточно иметь всего один ключ.
Неиерархические (простые) сертификаты
Простой сертификат удостоверяет простое имя или общую часть иерархического имени. Простые сертификаты используются только тогда, когда хотя бы одна из двух участвующих в контакте сторон - сервер или пользователь - имеют простое имя.Очередной простой сертификат просто добавляется к набору сертификатов в ID-файле пользователя. Например, пользователь Mary Jones, работающая в Lotus Development, могла бы иметь в своем ID-файле сертификаты от сертификаторов с именами Lotus Development, Notes Domain и ADMIN_2. Каждый из этих сертификатов был получен от независимого сертификатора. Каждый из сертификатов устанавливает ассоциацию между именем Mary Jones и ее публичным ключом "за подписью" соответствующего сертификатора (см. Рис. 8.4). В результате Mary Jones получает возможность доступа к серверам, в ID-файлах которых имеется хотя бы один сертификат, выданный сертификатором с именем Lotus Development, Notes Domain или ADMIN_2.
Notes Named Network - поименованная сеть Notes
Поименованная сеть Notes (Notes Named Network, NNN) - группа серверов Notes из одного домена, использующих для "общения" между собой один и тот же сетевой протокол на постоянной основе (постоянное соединение). Серверы из одной поименованной сети Notes "могут в любое время напрямую" соединяться между собой по этому протоколу.При присвоении имен сетей Notes должно быть учтено следующее:
· серверы Notes, использующие один и тот же сетевой протокол и расположенные физически в одной и той же локальной сети, должны иметь одно и то же имя сети Notes
· серверы Notes, использующие разные сетевые протоколы, не могут принадлежать к одним и тем же сетям Notes
· серверы Notes, использующие один и тот же сетевой протокол, но расположенные физически в разных локальных сетях, должны принадлежать к разным сетям Notes. Серверы Notes, использующие один и тот же сетевой протокол, расположенные в разных локальных сетях и устанавливающие соединение между собой по модему (X.PC) или посредством Microsoft RAS с активизацией его из Notes, должны принадлежать к разным сетям Notes. Только в случае, если между этими двумя локальными сетями существует постоянно действующий мост (реализуемый сетевыми программными или аппаратными средствами, а не средствами Notes), по соображениям нагрузки на мост возможно соотнесение серверов из этих разных локальных сетей как в одну сеть Notes, так и в разные сети Notes
· серверы Notes, использующие два или более сетевых протокола, должны принадлежать к нескольким сетям Notes, по одной на каждый протокол.
Понятие "поименованная сеть Notes" существенно используется при передаче почты между серверами. Считается, что серверы, находящиеся в одной и той же поименованной сети Notes, всегда могут напрямую соединиться друг с другом для передачи почты. Поэтому сервер, обнаружив почту, которую необходимо передать на другой сервер в той же самой поименованной сети, передает ее "автоматически" - связывается с сервером назначения по общему протоколу и передает, игнорируя при этом приоритеты писем и не используя информации из документов Connection о расписании передачи почты. Если бы понятие "поименованная сеть Notes" не использовалось, то для того, чтобы "описать" все возможные варианты передачи почты между N серверами, администратору потребовалось бы создать в адресной книге N*(N-1) документов Connection типа Network (если N=10, то N*(N-1) = 90).
Пример 3. Организация (Рис 1.10) расположена в 4-х территориально-удаленных местах. В организации один домен. Локальные сети из офисов San Francisco и San Jose соединены внешним мостом, который обеспечивает свободное прохождение пакетов NETBIOS. Остальные соединения выполняются по обычным телефонным линиям с использованием модемов. Станции Notes на рисунке не приведены. Серверы Notes поддерживают протоколы:
|
A,D,E,I,H |
NETBIOS |
|
H,E |
TCP/IP |
|
A,B,C,F,G |
Novell SPX |
Рис. 1.10 Поименованные сети Notes в территориально-распределенной организации
Какие поименованные сети Notes присутствуют?
В Атланте: "AtlantaNetBIOSLAN" (серверы I, H)
"AtlantaTCPIPLAN" (сервер H)
В Далласе: "DallasNovellSPX" (серверы G, F)
В Сан-Франциско: "SanFranciscoTCPIPLAN" (сервер E)
"SanFranciscoSanJoseNetBIOSLAN" (серверы A, D, E)
В Сан-Хосе: "SanJoseNovellSPX" (серверы A, B, C)
"SanFranciscoSanJoseNetBIOSLAN" (серверы A, D, E)
Пример 4. В домене 3 сервера: InterTrust/InterTrustCorp/SU (под OS/2), поддерживающий протоколы SPX и NetBIOS, InterWork/InterTrustCorp/SU (под Novell Netware), поддерживающий протокол SPX, и NotesSrv400/InterTrustCorp/SU (под Windows NT), поддерживающий протоколы SPX и TCP/IP. Из документов Server (рис. 1.10 - 1.12) видно, что имеются три поименованных сети Notes (смотрите информацию в столбце Notes Network таблицы Network Configuration). На Рис. 1.13 дается графическая форма представления этих поименованных сетей.
Рис. 1.10 Сервер InterTrust принадлежит двум поименованным сетям Notes
Рис. 1.11 Сервер InterWork принадлежит одной поименованной сети Notes
Рис. 1.12 Сервер NotesSrv400 принадлежит двум поименованным сетям Notes
Рис. 1.13 Такая форма представления поименованных сетей используется в Notes View
Новый домен, первый сервер, но та же организация
Установка начинается как в варианте 2.1.1, т.е. без предварительной регистрации будущего сервера. В первом окне выбирают "Первый сервер Lotus Notes в вашей организации". Но в диалоговом окне Advanced Server Setup Options (Рис. 2.7) снимают пометку с опции Create Organization Certifer ID. В результате ID нового сервера будет сертифицирован уже существующим (например, созданным при установке первого сервера в организации) ID сертификатора - в процессе установки появится диалоговое окно, в котором администратор должен будет "предоставить" ID-файл сертификатора. Все остальное совершенно аналогично варианту 2.1.1.О двухбайтовой кодировке русских букв
Текстовая информация любого типа (в полях типа Text, RichText - кроме объектов и присоединенных файлов, Names ...) в базах данных Notes хранится в кодировке LMBCS (Lotus MultiByte Character Set). В кодировке LMBCS один символ кодируется, вообще говоря, несколькими байтами: английские буквы - одним байтом, русские - двумя, китайские, японские, корейские - тремя... В базе данных Notes в принципе допустимы тексты, в которых "рядом" могут встречаться и английские буквы, и русские буквы, и японские иероглифы.Однако при выводе текстовой информации из баз данных на экран клиента Notes происходит ее перекодирование из кодировки LMBCS в кодировку, поддерживаемую данным компьютером (так называемую native). Наоборот, введенная с клавиатуры текстовая информация (в кодировке native) при записи в базу данных перекодируется в LMBCS. Перекодировка ведется по таблицам перекодировки, которые хранятся в каталоге программ Notes в файлах с именами l_cp*.cls. При этом не на всех платформах такое преобразование может работать взаимно однозначно - в настоящее время в кодировке native символ обычно кодируется только одним байтом. Если какой-то символ из текстового поля в базе данных по используемой на станции таблице перекодировки не может быть сопоставлен символу в кодировке native, он заменяется на символ с кодом 128 (0х7F), который обычно "будет виден" на экране на Windows-платформах как "Ђ" или "черный прямоугольник" под OS/2.
Кроме того, при построении индексов видов в базах сортировка текстовой информации выполняется с использованием таблиц сортировки, которые хранятся в каталоге программ Notes в файлах с именами coll* .cls.
Станция и сервер Notes используют в качестве "активных" таблиц перекодировки файлы l_cpdos.cls (Windows и OS/2), l_cpnlm.cls (только сервер под Novell NetWare), l_cpwin.cls (только Windows), а сортировки - collstd.cls. Для "правильной" поддержки русского языка сразу после первой фазы установки сервера или станции Notes вам необходимо "записать" в эти файлы соответствующие таблицы:
· Windows-подобные платформы:
l_cp866.cls ® l_cpdos.cls
l_cp1251.cls ® l_cpwin.cls
collcyr.cls ® collstd.cls
· OS/2:
collcyr.cls ® collstd.cls
· Novell NetWare:
l_cp866.cls ® l_cpnlm.cls
collcyr.cls ® collstd.cls
Выполнять эту операцию на Windows-платформах проще всего следующим BAT-файлом
REM Двухбайтовая кодировка русских букв
copy l_cp866.cls l_cpdos.cls
copy l_cp1251.cls l_cpwin.cls
copy collcyr.cls collstd.cls
Поместите BAT-файл в каталоге программ Notes. Файлы l_cp866.cls, l_cp1251.cls, collcyr.cls входят в состав интернациональной версии Notes. Выполнение файла перед запуском Notes обеспечит двухбайтовую кодировку русских букв и правильную сортировку по русским буквам. BAT-файл выполняется однократно - и впоследствии Notes при старте использует информацию из файлов l_cpdos.cls, l_cpwin.cls, collstd.cls. Такая же операция должна быть однократно проделана и на сервере Notes, причем желательно сразу после его установки. Обратите внимание, что после upgrade существующего сервера или станции на более новую версию Notes файлы l_cpdos.cls, l_cpwin.cls, collstd.cls заменяются одноименными файлами с дистрибутива, поэтому перед запуском "обновленных" сервера или станции необходимо снова однократно выполнить "русифицирующий" BAT-файл.
Разрабатывайте новые приложения Notes только с использованием двухбайтовой кодировки русских букв.
Признаком того, что текущая установленная на станции или сервере кодировка русских букв не соответствует кодировке текстовой информации в базе данных, является появление на экране вместо русских букв символов "Ђ" (или "черных прямоугольников" под OS/2). Однако "отображение греческих букв вместо русских" - уже проблема, связанная со шрифтами, и не имеющая никакого отношения к используемой в Notes "внутренней" кодировке.
И, наконец, практика показывает, что для правильного экспорта русскоязычных текстов из Notes через буфер обмена в Microsoft Word достаточно скопировать файл l_cp1251.cls в l_cp1252.cls.
Обновление дизайна почтовых ящиков при переходе от Notes версий х к версиям х
Для почтовых ящиков в версиях 4.х (но до версии 4.5) используется новый дизайн-шаблон StdR4Mail (MAIL4.NTF). Он предоставляет такие новые возможности, как папки для хранения входящих и отправленных писем, черновиков писем, удаляемых писем; кнопки акций для быстрого доступа к возможностям; пиктограммы в видах и формах для индикации типа письма; удобные средства для адресации писем и агенты, выполняющие команды автоматически.Возможны два способа обновления дизайна ПЯ:
· использование администратором серверной задачи-утилиты Convert,
· замена дизайна пользователем "вручную" с последующим использованием агента.
При использовании утилиты Convert производится обновление всех, части или только некоторых ПЯ на сервере. Утилита заменяет у почтовой базы текущий дизайн-шаблон на StdR4Mail, обновляет дизайн, создает папки из категорий, подпапки из подкатегорий, добавляет категоризированные документы в соответствующие папки и подпапки, а некатегоризированные - в Inbox. Этот метод предпочтительнее как при массовом обновлении почтовых баз, так и при обновлении одиночных, но больших по размеру почтовых баз.
"Ручное" обновление более предпочтительно для разового преобразования относительно небольших по размеру ПЯ. Вначале у базы заменяют шаблон на StdR4Mail, затем обновляют дизайн, и после этого запускают агента "(Convert Categories to Folders)". Агент создает папки из категорий, подпапки из подкатегорий, добавляет категоризированные документы в соответствующие папки и подпапки, а некатегоризированные - в Inbox.
Обновление реплик почтовых ящиков на станциях пользователей происходит за счет репликаций.
Обратите внимание, что в почтовом ящике допускается не более 200 папок (это принципиальное ограничение, оно не зависит от способа обновления).
При использовании утилиты Convert последовательность действий такова.
· Убедитесь, что вы обновили все (!) станции и серверы.
· Предупредите пользователей, имеющих в своих ПЯ собственные формы, виды и макросы, чтобы они сохранили дизайн во временных базах.
· Запустите сервер Notes.
· Остановите маршрутизатор почты командой Tell Router Quit
.
· Запустите утилиту преобразования почтовых ящиков. Примеры команд приведены ниже, а подробное описание синтаксиса можно найти базе Notes Migration Guide.
· По окончании работы утилиты вновь запустите маршрутизатор почты командой Load Router.
· Предупредите пользователей, что они могут скопировать свои собственные элементы дизайна из временных баз в обновленные почтовые ящики, однако их элементы дизайна не должны иметь имена, которые уже используются в обновленном дизайне, иначе почта не будет правильно функционировать.
Пример 1. Если база mail\user.nsf наследует дизайн с шаблона StdNotesMail, то шаблон заменяется на StdR4Mail (MAIL4.NTF) и выполняется обновление.
load convert mail\user.nsf stdnotesmail mail4.ntf
Пример 2. Для тех баз в каталоге \mail, которые наследуют дизайн с шаблона StdNotesMail, выполняется обновление.
load convert mail\*.nsf stdnotesmail mail4.ntf
> load convert mail\*.nsf stdnotesmail mail4.ntf
03.09.96 13:23:58 Mail Conversion Utility starting
03.09.96 13:24:00 Mail Convert: Started replacing design template 'stdnotesmail' with 'StdR4Mail' in 'mail\ADANILIN.NSF'
03.09.96 13:24:04 Adding '-' to database 'Alexandr V. Danilin' from template 'Mail (R4)'
03.09.96 13:24:05 Adding 'Archive Profile' to database 'Alexandr V. Danilin' from template 'Mail (R4)'
03.09.96 13:24:06 Adding 'Bouncy Earth' to database 'Alexandr V. Danilin' from template 'Mail (R4)'
… и так далее на 3 листа, какой-то элемент дизайна добавляет, какой-то заменяет.
03.09.96 13:24:25 Adding '($All)' to database 'Alexandr V. Danilin' from template 'Mail (R4)'
03.09.96 13:24:40 Deleting ' All by Person' from database 'Alexandr V. Danilin'
03.09.96 13:24:40 Deleting 'All by Size' from database 'Alexandr V. Danilin'
03.09.96 13:24:40 Deleting 'Attachments' from database 'Alexandr V. Danilin'
03.09.96 13:24:41 Deleting 'Drafts by Category' from database 'Alexandr V. Danilin'
03.09.96 13:24:41 Deleting 'Memo to Manager' from database 'Alexandr V. Danilin'
03.09.96 13:24:42 Deleting 'Received by Category' from database 'Alexandr V. Danilin'
03.09.96 13:24:42 Deleting 'Sent by Category' from database 'Alexandr V. Danilin'
03.09.96 13:24:42 Deleting 'To Do' from database 'Alexandr V. Danilin'
03.09.96 13:24:43 Mail Convert: Finished replacing design template in 'mail\ADANILIN.NSF'
03.09.96 13:24:45 Mail Convert: Started converting categories to folders in 'mail\ADANILIN.NSF'
03.09.96 13:24:45 Mail Convert: Building a categorized view
03.09.96 13:24:46 Mail Convert: Checking for the maximum number of categories
03.09.96 13:24:51 Mail Convert: Creating & populating folder 'Lotus'
03.09.96 13:24:58 Mail Convert: Opening & repopulating existing folder '$Inbox'
03.09.96 13:25:02 Mail Convert: Finished converting categories to folders in 'mail\ADANILIN.NSF'
03.09.96 13:25:05 Mail Convert: Started replacing design template 'stdnotesmail' with 'StdR4Mail' in 'mail\DVOLKOV.NSF'
. . .
03.09.96 13:27:02 Mail Convert: Finished converting categories to folders in ' mail\DVOLKOV.NSF '
03.09.96 13:31:34 Mail Convert: Skipping database mail\ykornvei.nsf, its design template 'StdR4Mail' does not match 'stdnotesmail'
03.09.96 13:31:34 Mail Conversion Utility shutdown
Пример 3. Для всех баз в каталоге \MAIL и рекурсивно всех его подкаталогах выполняется обновление.
load convert -r mail\*.nsf
Пример 4. В файле C:\TEMP\MAILLIST.TXT создается список всех почтовых баз на сервере.
load convert -l c:\temp\maillist.txt
Пример 5. Просматриваются все базы, перечисленные в файле c:\temp\maillist.txt, полученном в предыдущем примере, и в тех из них, которые наследуют дизайн с шаблона, первые три буквы названия которого STD (например, StdNotesMail) , шаблон заменяется на StdR4Mail (MAIL4.NTF) и выполняется обновление.
load convert -f c:\temp\maillist.txt std* mail4.ntf
При обновлении "вручную" последовательность действий такова.
· Запустите станцию Notes.
· Скопируйте модифицированные вами формы, виды и макросы во временную базу.
· Выберите пиктограмму базы и из меню File - Database - Replace Design.
· Выберите дизайн-шаблон Mail (R4).
· Нажмите кнопку Replace.
· Выберите из меню View - Go To Agents, затем агента с именем "(Convert Categories to Folders)", и далее из меню Actions - Run.
· Добавьте в базу из временной базы собственные элементы дизайна, но не заменяя при этом существующих.
Переход от Notes версий 4.х к версиям 4.5 тоже влечет изменение дизайна почтовых ящиков. Основные изменения здесь связаны с появлением системы календарного планирования и учета свободного времени. Для поддержки этих возможностей в язык LotusScript пришлось добавить несколько новых классов. Естественно, что новый дизайн-шаблон почтового ящика StdR45Mail (MAIL45.NTF) использует методы этих новых классов. Так же естественно, что станция Notes версий ниже 4.5 интерпретировать методы этих новых классов не может, "выдавая" при попытке открыть на ней почтовый ящик дизайна StdR45Mail многочисленные предупреждения об ошибках.
Однако такой "остроты" проблемы, как при переходе от версий 3.х к версиям 4.х, здесь уже нет. Сервер Notes версии 4.5 с одинаковым успехом поддерживает как почтовые ящики дизайна StdR45Mail, так и StdR4Mail. Замена дизайна осуществляется просто заменой используемого почтовым ящиком дизайн-шаблона. Если пользователь желает продолжать работать на станции версии 4.11а (обычно, потому что она русифицирована), обеспечьте, чтобы его почтовый ящик наследовал дизайн с шаблона StdR4Mail. При регистрации нового пользователя для него создается почтовый ящик дизайна StdR45Mail. Если этот пользователь будет работать на станции версии 4.11а, сразу после регистрации измените дизайн его ПЯ на StdR4Mail.
Обычные модемные соединения по коммутируемым линиям
Здесь мы предполагаем, что на вызывающем компьютере (станции или сервере) и на вызываемом сервере модемы подключены непосредственно к COM-портам, т.е. изображенные на Рис. 5.1 управляемые устройства УУ1 и УУ2 и скрипты "приобретения" и соединения отсутствуют.Рассмотрим действия, которые необходимо выполнить по настройке станции или сервера для работы с использованием модема, а так же некоторые аспекты такой работы со станции.
Установка COM-порта
Выбрав в меню File - Tools - User Preferences..., получаем диалоговое окно, в котором выбираем закладку Ports, а на ней COM-порт, к которому подключен модем.
Рис. 5.2 Настройка COM-порта начинается из окна User Preferens на закладке Ports
При нажатии кнопки COMx Options… получаем окно Additional Setup.
Рис. 5.3 Окно Additional Setup при использовании драйвера XPC
В нем выбираем тип используемого модема (из списка Modem Type:). Допустимые типы используемых модемов определяются наличием в каталоге NOTES\DATA\MODEMS файлов управления модемами (расширение *.MDM). Если в списке нет используемого вами модема, рекомендуем сначала попробовать подобрать "наиболее близко подходящий" к нему из числа имеющихся в списке. Если это не удается, выберите .Auto Configure (for unlisted modems, only), что соответствует файлу AUTO.MDM. Используя этот файл, драйвер XPC в процессе автоподстройки к модему "перебирает" несколько стандартных файлов управления модемами. Однако по нашему опыту, это не всегда "спасает". Даже если ваш модем и будет работать с файлом AUTO.MDM, скорее всего не все возможности вашего модема при этом будут задействованы, а в результате не будет получено хороших, а иногда даже и удовлетворительных результатов.
В поле Maximum port speed:
выбирается максимальная скорость, обеспечиваемая компьютером по COM-порту. Она должна превосходить скорость, на которой будет осуществляться соединение модемов, и должна быть согласована с установками для порта на уровне операционной системы (для Windows-платформ пиктограмма Ports в Control Panel). В поле Speaker volume: выбирается необходимый уровень громкости "звукового сопровождения" модема при установлении соединения, в поле Dial mode: - применяемый метод набора номера ("пульсовый" или "тоновый"). Протоколирование команд, посылаемых на модем, а так же ответов модема на них в базе LOG.NSF (опция Log modem I/O:) может быть полезна при отладке. Выбирать опцию Log script I/O:
в рассматриваемой нами ситуации бессмысленно - ведь никакие скрипты не используются. Опция Hardware flow control: обычно выбирается для современных модемов, но должна быть согласована с возможностями модема и установками для порта на уровне операционной системы (для Windows-платформ пиктограмма Ports в Control Panel). Значение в поле Dial timeout: определяет, сколько секунд ваш модем при установлении соединения после набора номера будет ожидать ответа вызываемого модема. Значение в поле Hang up if idle for: определяет количество минут "бездействия" при установленном соединении, по истечении которого принимается решение разорвать соединение. Администратор обычно "управляет" этим значением на сервере, чтобы последний автоматически разрывал соединения со станциями, пользователи которых "держат линию", не выполняя при этом полезной работы - обмена данными. Наконец, число в поле Port number: должно совпадать с номером используемого COM-порта.
Кнопка Modem File…
"открывает" окно редактора используемого файла управления модемом. Можно редактировать этот файл и любым текстовым редактором. В большинстве случаев требуются лишь незначительные корректировки строк инициализации модема - они даются в строках файла с префиксом "SETUP=". Команды и возможности вашего модема можно найти только в руководстве к модему. Чтобы осознанно редактировать файл управления модемом или создавать собственные файлы, вы должны знать используемый при этом язык. Для получения информации по языку файлов управления модемами просмотрите файл TEMPLATE.MDM.
Кнопка Acquire Script... "открывает" окно, в котором выбирается скрипт "приобретения", работающий перед тем, как начнутся посылки команд на модем. В рассматриваемой нами ситуации ("обычные модемные соединения") скрипт "приобретения" не используется, и вам лишь остается обратить внимание, выбрано ли в этом окне -NONE-. Кнопка Edit... станет активна только после того, как вы выберите существующий скрипт "приобретения", и "откроет" в окне редактора файл этого скрипта.
Рис. 5.4 Для обычных модемных соединений скрипт "приобретения" не используется
Документ Location в адресной книге станции
В персональной адресной книге создаем новый или модифицируем существующий документ Location (см. Рис. 5.5).
В поле Location type: выбираем Dialup Modem, в списке используемых в этом местоположении портов (Ports to use:) - используемый COM-порт. Задаем полные имена почтового сервера, сервера-посредника по умолчанию и InterNotes-сервера.
Обратите также внимание на префикс телефонного номера в поле с меткой Prefix for outside line:
(например: "9," для выхода в город с местной телефонной станции). В этом местоположении он будет автоматически добавляться к номеру телефона из документа Connection.
Если в поле Schedule: выбрано Enabled, то временные интервалы (Replicate daily between:), интервал повторения (Repeat every:) и дни (Days of week:) определяют моменты времени, когда станция должна автоматически связываться с сервером для выполнения фоновой репликации и передачи почты между станцией и сервером. Чтобы запретить автоматический вызов сервера (работу по расписанию), выберите Disabled в поле Schedule:.
В поле с меткой Mail file location: по финансовым соображениям обычно выбирают режим Local. Режим касается только способа передачи почты на сервер, но не вызова сервера с использованием модема. Проверьте в поле с меткой Mail file: путь и имя файла для используемого почтового ящика. Почтовые ящики пользователя на сервере и станции должны быть репликами (см. Рис. 5.6). Входящие письма пользователю сервер из своего MAIL.BOX помещает в почтовый ящик пользователя на сервере. Из него письма поступают в почтовый ящик пользователя на станции за счет репликаций. Исходящие письма пользователя, станция которого находится в режиме Local, создаются в почтовом ящике на станции и при отправке заносятся в MAIL.BOX на станции. Из MAIL.BOX на станции они в некоторые моменты времени переносятся в MAIL.BOX на сервере. Дальнейшей их доставкой занимаются уже серверы. Сохраненные пользователем копии отправленных писем из его почтового ящика на станции реплицируются также и в его почтовый ящик на сервере.
Рис. 5.5 Пример документа Location (версия 4.11a)
Рис. 5.6 Схема режима Local
Документ Connection
В локальной адресной книге инициирующего соединение сервера или станции создаем документ Connection. Основное в этом документе - номер телефона. В рассматриваемой нами ситуации ("обычные модемные соединения") скрипт соединения не используется, поэтому поля Login script filename: и Login script arguments: должны быть пусты.
Рис. 5.7 Пример документа Connection (версия 4.11а, персональная адресная книга)
Вызов сервера
Сервер вызывает другой сервер в соответствии с расписанием, указанным в документе Connection. Станция, в текущем документе Location которой в поле Schedule: выбрано Enabled, так же вызывает сервер в соответствии с заданным в этом документе расписанием.
Пользователь станции может в любое время "вручную" инициировать вызов сервера. Для этого, убедившись, что станция находится в соответствующем местоположении, пользователь выбирает в меню File - Mobile - Call server…
и в появившемся окне нажимает кнопку Auto Dial. Если все хорошо, должен произойти набор номера и, через несколько минут, соединение с сервером. Обратите внимание, что список серверов в окне Call Server станция "строит" по документам Connection типа Dialup Modem из локальной адресной книги, но с учетом текущего местоположения. Если список пуст, в локальной адресной книге нет ни одного документа Connection типа Dialup Modem, "применимого" в текущем местоположении.
Рис. 5.8 Окно вызова сервера
Инициировать вызов сервера можно и другими способами, например, кнопкой
Для принудительного завершения сеанса выбирают в меню File - Mobile - Hang Up ("повесить трубку") или нажимают кнопку
Работа со станции по модемному соединению
По модемному соединению возможны два стиля работы:
· интерактивная работа - работа во время активности соединения с сервером, точно так же, как по локальной сети, только медленнее, "со скоростью канала". Однако по финансовым соображениям этот стиль обычно нецелесообразен, поскольку пользователь не может "равномерно загрузить" открытый канал
· локальная работа с периодическим вызовом сервера - работа с локальными репликами имеющихся на сервере баз данных, подготовка почты в локальном почтовом ящике и вызов сервера только для выполнения репликаций с репликами баз на сервере и отправки почты. Этот стиль работы позволяет полностью загрузить открытый канал между станцией и сервером, и по финансовым соображениям обычно более целесообразен.
Наиболее удобно управлять процессом репликаций между станцией и сервером с закладки Replicator.
Рис. 5.9 Внешний вид закладки Replicator
Содержимое закладки "привязано" к местоположению, в котором находится станция. Когда вы создаете локальную реплику базы с сервера, ее пиктограмма автоматически добавляется на закладку Replicator. Если все-таки вам необходимо "вручную" добавить пиктограмму базы на закладку Replicator, просто перетащите ее туда мышью. Для удаления пиктограммы базы с закладки Replicator
выберите ее и нажмите клавишу Delele.
Для каждой имеющейся на закладке базы можно выбрать необходимые репликационные установки (правой кнопкой мыши).
Рис. 5.10 Как реплицируется локальная база
Можно реплицировать как "все" базы, так и только предварительно выбранные на закладке (отмечаются "галочкой"). Кнопка Send & Reseive Mail служит для пересылки ваших исходящих писем из локальной базы MAIL.BOX в базу MAIL.BOX на сервере и приема входящих писем из реплики почтового ящика на сервере в локальный почтовый ящик.
В режиме Local в репликационных установках локального почтового ящика рекомендуется выбрать:
· не реплицировать выполненные в локальном почтовом ящике изменения и удаления в почтовый ящик на сервере
· автоматически удалять документы, которые не изменились за последние XXX дней.
Для репликаций и передачи почты по расписанию следует предварительно "разрешить" работу по расписанию в документе Location. Это же можно сделать и непосредственно с закладки Replicator, "отметив галочкой" первый элемент (Start replication at:) на закладке.
Замечания
· Перед завершением работы станции Notes, функционирующей в режиме Local, появляется диалоговое окно с предложением обменяться почтой с сервером, если локальный MAIL.BOX не пуст. При положительном ответе происходит автоматическое соединение и обмен почтой.
· Документы в Notes версий 3.х передаются и реплицируются целиком, даже если в них изменилось только одно поле. В Notes версий 4.х репликации и сохранение документа выполняются на уровне полей - передаются только изменившиеся поля.
· При интерактивной работе с сервером виды передаются частями - приблизительно по 2 "экранных страницы". Хорошее впечатление оставляет выполнение запроса полнотекстового поиска к базе на сервере, так как вы получаете быстрый ответ.
· По опыту автора хороший модем (мы использовали модемы фирм US Robotics или ZyXEL) достаточно стабильно обеспечивает на обычных городских телефонных линиях скорость 19600 bps и выше. Интерактивная работа на такой скорости вполне приемлема. При скорости ниже 9600 bps
интерактивная работа происходит "мучительно медленно". Однако качество модема еще не решает все проблемы - очень многое зависит от используемых телефонных линий и автоматических телефонных станций.
Обзор баз данных, используемых администратором в своей работе
Администратор в своей повседневной работе наиболее часто использует базы данных:· NAMES.NSF - Public Address Book (PAB) - общая адресная книга,
· LOG.NSF - Notes Log - протокол работы сервера,
· CATALOG.NSF - Database Catalog - каталог баз данных на сервере,
· CERTLOG.NSF - Certification Log - протокол сертификаций.
Это далеко не полный список системных баз, но цель данной главы - подробное рассмотрение перечисленных баз данных, и прежде всего общей адресной книги.
Обзор обеспечения безопасности сервера Notes
Сервер или станция Notes (клиент A) обращается к серверу Notes (B), например, устанавливает соединение с сервером, открывает базу на сервере и работает с документами, выполняет репликацию или передачу почты. При этом клиенту, чтобы получить доступ к информации на сервере, образно говоря, приходится последовательно "пройти через пять следующих дверей и не споткнуться на дополнительных возможностях".Очередной сервер в домене
Процесс начинается с регистрации будущего очередного сервера. Администратор первого сервера домена со своей рабочей станции выбирает в меню File - Tools - Server Administration…, и далее в окне Administration выбирает в меню кнопки Server пункт Register Server…
Рис. 2.10 Большинство действий по администрированию выполняются из окна Administration…
Рис. 2.11 Первое диалоговое окно при регистрации очередного сервера в домене
В диалоговом окне Register Servers кнопкой Registration Server... администратор выбирает любой из уже функционирующих серверов домена: в общую адресную книгу этого сервера будет добавлен документ Server на создаваемый сервер. Регистрационный сервер - это сервер, в адресную книгу которого в ходе регистрации заносится информация о регистрируемом сервере, пользователе... Впоследствии при репликациях эта информация попадет и в адресные книги других серверов домена.
Кнопкой Certifer ID... администратор выбирает ID-файл сертификатора, которым должен быть сертифицирован ID будущего сервера. От этого выбора зависят старшие компоненты в имени нового сервера.
В поле Certificate expiration date можно изменить "дату истечения" сертификата - дату, до которой будет иметь силу сертификат, добавляемый в создаваемый ID сервера.
После этого нажимают кнопку Continue… и получают второе окно Register Servers, в котором две закладки.
Рис. 2.12 Второе диалоговое окно при регистрации очередного сервера в домене, закладка Basics
На закладке Basics
задают:
· имя создаваемого сервера (только имя сервера, без старших компонент, включающих названия оргединиц (OU), организации (O) и страны (С), поскольку эти компоненты будут "взяты" из уже выбранного ID-файла сертификатора и автоматически добавлены к введенному вами имени)
· имя домена, в состав которого будет входить сервер
· если необходимо, пароль для ID-файла создаваемого сервера. Если же пароль не нужен, очистите поля Password и Minimum password length.
· полное имя администратора создаваемого сервера.
На закладке Other
определяется (см. диалоговое окно на Рис. 2.13) имя поименованной сети Notes и "место", в которое следует поместить ID создаваемого сервера (в файл или/и в адресную книгу). Учтите, что если вы помещаете ID создаваемого сервера в адресную книгу, вам все равно придется защитить его паролем. Если же ID создаваемого сервера помещается только в файл, то очисткой полей Password и Minimum password length вы сможете создать "беспарольный" ID сервера.
В поле Local Administrator может быть указан список полных имен лиц, которым следует предоставить возможность редактировать документ Server создаваемого сервера, но не все другие документы из общей адресной книги. Этот список будет помещен в поле типа Authors создаваемого в ходе регистрации документа Server. Впоследствии эти лица смогут редактировать данный документ, имея к общей адресной книге лишь доступ автора. Однако удобнее добавить список этих лиц непосредственно в поле Administrators секции Administration в документе Server позже, после регистрации и установки сервера.
После этого нажатием кнопки Register администратор "запускает" процесс регистрации. В ходе процесса регистрации Notes:
· создает ID нового сервера и сертифицирует его выбранным ID сертификатора
· создает документ Server для нового сервера в общей адресной книге
· добавляет сервер в группу LocalDomainServers в общей адресной книге
Рис. 2.13 Второе диалоговое окно при регистрации очередного сервера в домене, закладка Other - дополнительные параметры
· добавляет имя администратора в соответствующее поле в документе Server нового сервера
· присоединяет ID сервера в документ Server в адресной книге или (и) записывает его в файл
· создает документ формы Certified User для сервера в базе данных "Протокол Сертификаций"
(Certification
Log, CERTLOG.NSF), если эта база была создана на регистрационном сервере. Не удивляйтесь названию формы Certified User - "сертифицированный пользователь". Во-первых, ID пользователя и сервера практически ничем не отличаются, а во-вторых, в базе Certification
Log только протоколируются все акты сертификаций, без различия, для "кого" (пользователя, сервера и др.) они выполнялись.
После регистрации появляется возможность внести некоторые изменения непосредственно в созданный документ Server. Но во избежание возможных проблем при последующей установке сервера рекомендуем сделать это уже после установки.
Только после этого на компьютере, который должен стать новым сервером Notes, начинают собственно процесс установки. После выполняемого программой INSTALL.EXE копирования информации на локальный диск сервера, выбора соответствующих стране и используемому языку таблиц перекодировки и сортировки и запуска программы станции в диалоговом окне Notes Server Setup
(Рис. 2.5) выбирают An addditional Lotus Notes server in your organization ("Дополнительный сервер в вашей организации"). В следующем окне (Рис. 2.14) необходимо указать имя нового сервера (такое же, как было указано при его регистрации), а также имя регистрационного сервера и способ связи с ним. Если ID устанавливаемого сервера при регистрации был записан в файл, нужно отметить опцию New server's ID supplied in a file. Если ID администратора сервера имеется в виде файла, а не присоединен к документу Person в общей адресной книге, в окне на Рис. 2.15 необходимо отметить опцию Administrator's ID is supplied in a file. Остальное аналогично варианту установки 2.1.1.
Рис. 2.14 Установка очередного сервера в домене
Рис. 2.15 Дополнительные параметры при установке очередного сервера в домене
В процессе инсталляции Notes:
· открывает сетевой или коммуникационный порт нового сервера
· подключается к регистрационному серверу
· извлекает ID устанавливаемого сервера из адресной книги регистрационного сервера или из файла. Обратите внимание, что если ID-файл извлекается из адресной книги, он вначале копируется в каталог данных на устанавливаемом сервере, а затем автоматически удаляется из документа Server
· реплицирует к себе адресную книгу с регистрационного сервера
· создает LOG.NSF
· добавляет адресную книгу и LOG.NSF в рабочее пространство (если инсталлируемый сервер одновременно рабочая станция администратора).
Отправка шифрованной почты в другой домен
Зашифрованное сообщение Notes может быть отправлено в другой домен. Чтобы шифрование было возможным, для получателя должен иметься документ Person в одной из адресных книг, которые "просматривает" Mailer - часть программного обеспечения станции, отвечающая за отправку почты. Это может быть личная или общая адресная книга. Кроме того, документ Person должен содержать публичный ключ получателя, если его имя простое (неиерархическое), или сертифицированный публичный ключ, если его имя иерархическое. Обычно получатель предварительно "присылает" будущему отправителю свой публичный ключ "открытым текстом", а тот создает в своей адресной книге документ Person на будущего получателя и вставляет в соответствующее поле публичный ключ.Отсоединение ПЯ от СПЯ
Если вы хотите удалить СПЯ, вы должны сначала "отсоединить" от него все ПЯ. Эта операция для каждого сообщения из ПЯ, которое содержит ссылку на тело сообщения в СПЯ, восстанавливает в этом ПЯ тело сообщения. Очевидно, при такой операции может быть "израсходовано" значительное количество дискового пространства.Для отсоединения всех ПЯ от СПЯ используют команду консоли:
Load Object Unlink SHARED.NSF ,
где SHARED.NSF - имя СПЯ.
Если же вы хотите удалить только некоторые ПЯ, которые были связаны с СПЯ, то следует сначала отсоединить эти ПЯ от всех возможных СПЯ, с которыми они могли быть связаны. Если не сделать этого перед удалением ПЯ, в СПЯ могут остаться "тела сообщений", на которые не ссылается ни один из ПЯ, и они будут продолжать храниться в СПЯ "вечно", поскольку функция Collect не может их удалить, ибо счетчик ссылок не равен нулю.
Для отсоединения только одного ПЯ от СПЯ используется команда консоли:
Load Object Unlink USERMAIL.NSF ,
где USERMAIL.NSF - имя отсоединяемого ПЯ.
Переменные из файла NOTES.INI, относящиеся к почте
· Log_MailRouting задает подробность протоколирования почтовых событий в Notes Log.· MailCompactDisabled разрешает/запрещает уплотнение MAIL.BOX на сервере.
· MailDisablePriority значение 1 предписывает Mail Router игнорировать установленный отправителем приоритет сообщения и доставлять сообщение как сообщение нормального приоритета.
· MailDynamicCostReset задает интервал в минутах, по истечении которого сервер восстанавливает в таблицах маршрутизации указанные в общей адресной книге стоимости соединений. Значение по умолчанию - 60 минут.
· MailEncryptIncoming требует шифровать всю почту, получаемую пользователями, почтовые ящики которых находятся на этом сервере.
· MailLowPriorityTime= Отрезок времени для передачи почты низкого приоритета. По умолчанию (когда в файле NOTES.INI нет этой переменной) Router передает почту низкого приоритета между полуночью и 6:00 часами утра. Для изменения этого отрезка времени установите в качестве значения переменной MailLowPriorityTime желаемый отрезок, используя в нем время в 24-х часовом формате. Пример - с 9 до 11 вечера: MailLowPriorityTime=21:00-23:00 . Обратите внимание, что должен быть указан именно отрезок времени. Почта низкого приоритета не будет передаваться, если указано конкретное время, например 4:00.
· MailMaxThreads задает максимальное число параллельно работающих подпроцессов (threads), которые Mail Router может создавать для доставки почты. Подпроцесс реализует акт передачи почты: устанавливает соединение с сервером назначения, открывает его MAIL.BOX, "переписывает" в него сообщение и удаляет оригинал в "своем" MAIL.BOX. По умолчанию один подпроцесс на порт.
· MailServer на станции задает имя сервера, на котором находится почтовый ящик пользователя.
· MailSystem задает почтовую систему, которую пользователь выбрал при установке станции.
· MailTimeout задает число дней, по истечении которых сервер возвращает недоставленную почту отправителю. По умолчанию 1 день.
· MailTimeoutMinutes задает число минут, по истечении которых сервер возвращает недоставленную почту отправителю. Используется вместо MailTimeout, когда необходим более короткий интервал.
· ReportUseMail разрешает серверной задаче Report использовать Mail Router для отправки своей статистики на другой сервер в том же домене.
· ServerTasks
дает список задач, запускаемых при старте сервера и работающих до его останова. Обычно содержит и задачу Router.
· SecureMail для станции требует, чтобы вся отправляемая этой станцией почта была подписана и зашифрована.
· Shared_Mail
указывает, использует ли, и как задача Mail Router СПЯ на сервере.
Переменные NOTES.INI, которые влияют на репликации
· Allow_Access Список пользователей, групп и серверов, имеющих доступ на этот сервер.· Create_Replica_Access Список пользователей и групп, которые могут создавать реплики на этом сервере.
· Deny_Access Список пользователей, групп и серверов, не имеющих доступа на этот сервер.
· Log_Replication Значение 1 требует протоколировать начало и конец репликационной сессии в протоколе и на консоли сервера, значение 0 - не протоколировать.
· Repl_Error_Tolerance задает количество ошибок одного и того же типа, которое может произойти при репликации двух баз, прежде чем сервер закроет репликацию.
· ReplicationTimeLimit Задает максимальное время (в минутах), которое может занимать репликация между данным сервером и другими серверами.
· Replicators Указывает количество задач Replicator, которые должны одновременно выполняться на сервере.
Переменные ServerPushReplication и ServerNoReplRequests
ServerPushReplication = 1Сервер с ServerPushReplication=1 будет выполнять все репликации по расписанию, начатые с этого сервера, по схеме Pull-Push. Другие серверы, которые начинают репликацию с этим сервером по схеме Pull-Pull, будут принимать изменения от этого сервера (первая фаза в схеме Pull-Pull), но этот сервер уже не станет принимать запросы на прием изменений от них (вторая фаза в схеме Pull-Pull).
Неприятность в том, что такой сервер "заставляет" все остальные серверы вести себя подобным ему образом - иначе изменения с других серверов по их инициативе не поступят на сервер с ServerPushReplication=1.
ServerNoReplRequests=1
Сервер с ServerNoReplRequests=1 отказывается от запроса на репликацию с другого сервера и вынуждает запрашивающий сервер выполнять репликацию типа Pull-Push.
Пусть сервер A имеет ServerNoReplRequests=1 в файле NOTES.INI, а сервер B не имеет. Будет происходить следующее.
· Когда сервер B, инициировавший репликацию по схеме Pull-Pull, принял изменения с сервера A, он будет выдавать запрос для A, чтобы теперь сервер A принял изменения с сервера B. Это "нормальное поведение" - вторая фаза в схеме Pull-Pull.
· Однако сервер A будет отказываться от этого запроса из-за наличия в его файле NOTES.INI переменной ServerNoReplRequests=1, и будет отвечать серверу B, что "тот сам должен послать изменения на сервер A, если хочет, чтобы репликация завершилась успешно".
· Серверу B "остается только согласиться с таким ответом" сервера А и самому "затолкнуть" (Push) на него эти изменения.
Вы также можете задать обе переменные на одном сервере. Результатом будет то, что этот сервер будет выполнять все инициированные им репликации по схеме Pull-Push, и отказываться от всех запросов на репликацию от других серверов по схеме Pull-Pull, вынуждая другие серверы выполнять репликацию по схеме Pull-Push, "даже если они этого не хотят".
Перенос ПЯ, использующего СПЯ, на другой сервер
Перенос осуществляется следующим образом:· отсоединить ПЯ от СПЯ (Unlink);
· создать реплику ПЯ на другом сервере (File - Replication - New Replica при условии, что ПЯ доступен локально);
· удалить ПЯ (File - Database - Delete при условии, что ПЯ доступен локально);
· изменить в общей адресной книге в документе Person пользователя почтовый сервер;
· сообщить пользователю, чтобы он исправил имя почтового сервера в своей персональной адресной книге.
Person - пользователь
Документы формы Person служат для редактирования информации о пользователях в домене. Документ этой формы создается автоматически при регистрации пользователя и уже рассматривался в 2.2.1.Первый сервер первого домена в организации
Вы выбираете "Первый сервер Lotus Notes в вашей организации" в окне на Рис. 2.5, нажимаете OK и получаете диалоговое окно First Server Setup.
Рис. 2.6 Диалоговое окно First Server Setup
В нем задаете:
· Server Name
- имя сервера
· Organization Name
- название организации (оно же станет и названием домена, если не внести никаких изменений в дополнительном диалоговом окне, "вызываемом" кнопкой Advanced Options...)
· Last Name, First Name and Middle Initial of the Notes Administrator - фамилия, имя и буква отчества (необязательно) администратора, ответственного за сервер и домен
· Password
- пароль для ID-файла администратора, который также будет использован как пароль ID-файла сертификатора организации CERT.ID
· Network Type
- тип сети - один из сетевых протоколов, который будет использоваться для доступа к серверу. Поддержка этого сетевого протокола на уровне операционной системы должна быть установлена предварительно, до установки сервера Notes.
· Serial Port
- последовательный порт (COM1, COM2,...), используемый одним из модемов, подключенных к серверу
· Modem Type -
тип модема, подключенного к выбранному последовательному порту (если модемы подключены к серверу)
· Server is also administrators personal workstation - сервер также будет использоваться и как рабочая станция для администратора.
Весьма желательно сразу и надолго решить вопрос об именах сервера, организации и домена. Их изменение в дальнейшем возможно, но относительно трудоемко. Имеются определенные правила и принципы для выбора имен.
Имена серверов должны быть уникальны в пределах организации и могут состоять из одного или более слов (до 79 символов) из любых символов, кроме "(", ")",
"@", "/",
"\", "=",
"+" . Символ "&" , хотя его можно использовать в имени сервера, может причинять серьезные проблемы на некоторых платформах и в некоторых сетях. Символ "пробел" также не рекомендуется в имени сервера - иначе вам придется в командах консоли сервера вводить имена серверов "в кавычках". Имя организации должно быть не короче 3 символов и не длиннее 64 символов. Имя домена - до 32 символов, причем пробелы и символ "точка" использовать не рекомендуется. Имена поименованных сетей Notes должны быть не длиннее 32 символов. Наконец, при использовании протокола NetBIOS первые 15 символов имен серверов должны быть уникальны в пределах поименованной сети, при использовании AppleTalk - первые 32 символа, SPX - первые 47 символов.
В "вызываемом" по кнопке Advanced Options... диалоговом окне Advanced Server Setup Options (см. Рис. 2.7) можно задать имя домена (по умолчанию оно совпадает с названием организации), название поименованной сети Notes (по умолчанию Network1), необязательный код страны, заказать регистрацию событий (репликации, сеансы пользователей, протокол работы модема) в базе-протоколе LOG.NSF, изменить минимальную длину пароля. Важно не убирать выставляемый по умолчанию выбор опций Create Organization Certifer ID, Create Server ID, Create Administrator ID.
Рис. 2.7 Диалоговое окно Advanced Server Setup Options
После этого останется только выбрать в последнем диалоговом окне часовой пояс (например, ZE3
- 3 часа к востоку от Гринвича). Это важно для правильного выполнения репликаций баз между серверами, расположенными в разных часовых поясах.
Что происходит при установке первого сервера в первом домене?
В каталоге данных Notes создаются базы данных:
· NAMES.NSF - общая адресная книга
· LOG.NSF - протокол работы сервера Notes
Создаются файлы:
· CERT.ID - ID- файл для сертификатора организации; сертификатор организации будет использовать этот файл для сертификации ID пользователей, ID дополнительных серверов и, если необходимо, для создания ID сертификаторов оргединиц
· SERVER.ID - ID-файл этого сервера, причем он автоматически сертифицируется, т.е. в него автоматически добавляется сертификат, создаваемый с использованием CERT.ID
· USER.ID - пользовательский ID-файл для администратора, причем он автоматически сертифицируется с использованием CERT.ID.
Файлы SERVER.ID и CERT.ID помещаются в каталог данных сервера. Если сервер не является одновременно рабочей станцией администратора, USER.ID администратора присоединяется к документу Person, созданному для администратора в общей адресной книге. Если же сервер одновременно является рабочей станцией администратора, его USER.ID помещается в каталог данных сервера. Введенный вами пароль устанавливается для файлов CERT.ID и USER.ID - при последующих обращениях к этим файлам Notes будет требовать ввода данного пароля.
В общей адресной книге создается документ Server, в него заносится имя сервера, домена, поименованной сети и администратора сервера. Имя сервера добавляется в создаваемый документ Group с именем LocalDomainServers ("серверы этого домена") в общей адресной книге. Имя администратора и имя сервера также добавляются в список управления доступом (ACL) общей адресной книги с доступом менеджера. Кроме того, в адресной книге создается документ Certifier для сертификатора организации (владельца CERT.ID).
Наконец, в каталоге данных создается подкаталог почты mail\ и в нем база данных "Почтовый ящик" для администратора.
Рис. 2.8 Вид рабочего пространства по завершении установки сервера
Если по каким-то причинам вторая часть установки не удалась, ее можно повторить, не выполняя заново первую часть установки - копирование файлов. Для этого вы должны удалить из файла NOTES.INI (обычно он находится в каталоге Windows) все строки, расположенные после приведенных здесь 4-х строк
[Notes]
KitType=2
Directory=f:\notes45\data
FileDlgDirectory=f:\LOTUSTMP.000
и удалить из каталога данных Notes файлы DESKTOP.DSK, NAMES.NSF, ADMIN4.NSF, LOG.NSF, CERT.ID, SERVER.ID, USER.ID и, если имеются, MAIL.BOX и CATALOG.NSF.
Если при попытке начать вторую часть установки вы не получаете диалогового окна Notes Server Setup, "найдите" оставшийся от предшествующих установок сервера или станции файл NOTES.INI и исправьте его подобно описанному выше.
После завершения установки сервера ...
Завершите программу станции и запустите сервер двойным щелчком по его пиктограмме. Несколько сообщений появится в его окне.
Рис. 2.9 Так выглядит окно консоли сервера при его первом запуске
Первые сообщения отражают инициализацию различных процессов сервера. Notes сообщает, какие задачи и процессы начинаются, выполняются или завершаются. Символ >
- "приглашение"
ввести команду сервера.
С имеющимися в этом окне "предложениями" изменить в реестре Windows NT значения двух параметров ("ключей") для улучшения производительности работы сервера Notes в принципе можно согласиться. Однако учтите, что предлагаемое изменение первого параметра (...\LargeSystemCache) в случае, когда оперативной памяти на компьютере только на уровне минимально допустимого количества, может повлечь совсем обратный эффект, поскольку усилится свопинг (страничный обмен между оперативной памятью и файлом pagefile.sys).
Сообщение о том, что для общей адресной книги не назначен сервер администрирования, побуждает администратора после ознакомления с серверной задачей Administration Process (3.2.14) выполнить необходимое назначение.
Если сервер работает, можно заняться установкой первой станции клиента. Если с этой станции удается обратиться к серверу (например, открыть базу данных на нем), скорее всего все нормально.
Планирование репликаций и приоритеты баз
Репликации между серверами не происходят автоматически, они должны быть запланированы. Расписание репликаций задается набором документов Connection в общей адресной книге. Вы должны обычно составлять расписание репликаций так, чтобы только один из двух серверов выполнял вызов другого. Ситуация, когда оба сервера вызывают друг друга поочередно, в принципе допустима, но требует наличия двух согласованных документов Connection, тогда как обычно можно обойтись только одним.Репликация может быть намечена на заданный отрезок времени с интервалом повторения или только на заданное время. Если вы намечаете репликацию только однократно на заданное время, вы должны задать интервал повторения равным "0". Если в документе Connection поле интервала повторения пустое, сервер принимает интервал повторения равным 60 минут.
1. Отрезок времени с интервалом повторения - 8:00-18:00 с инт. 180 мин.
R__.__.__R__.__.__R__.__.__R__.
8 9 10 11 12 13 14 15 16 17 18
Репликатор впервые вызывает другой сервер в 8:00. Если попытка неуспешна, он повторяет попытку соединения в течение интервала (180 мин.), пока она не будет успешной (см. ниже Randomized exponential backoff algorithm). Следующий вызов будет производиться через 180 мин после успешного завершения репликации. Такой вариант рекомендуется для баз, которые должны реплицироваться наиболее часто.
Рис. 6.13 На отрезке времени с интервалом повторения 60 минут
2. Отрезок времени без интервала повторения - 8:00-18:00 с инт. 0 мин.
Репликатор впервые вызывает другой сервер в 8:00. Если попытка неуспешна, он повторяет попытку соединения в границах отрезка (до 18:00), пока она не будет успешной. После успешного соединения сервер не будет производить новых вызовов. Такой вариант рекомендуется для баз, которые должны реплицироваться со средней частотой.
3. Заданное время
- 8:00 с инт. 0 мин.
Репликатор впервые вызывает другой сервер в 8:00. Если попытка неуспешна, он повторяет попытку соединения в течение часа, пока она не будет успешной (обычно не более 4 попыток). После успешного соединения сервер не будет производить новых вызовов. Такой вариант рекомендуется для баз, которые должны реплицироваться относительно редко.
4. Список заданных времен - 8:00 AM; 1:00 PM; 4:00 PM с инт. 0 мин.
Репликатор впервые вызывает другой сервер в 8:00 утра. Если попытка неуспешна, он повторяет попытку соединения в течение часа, пока она не будет успешной. После успешного соединения сервер не будет производить новых вызовов, пока не наступит следующий указанный в списке момент времени (1:00 дня). Такой вариант рекомендуется для баз, которые должны реплицироваться со средней частотой.
Рис. 6.14 Три раза в заданное время
В окне Replication Settings (Рис. 6.12) для каждой базы можно также задать приоритет участия базы в репликациях. Указывая приоритет, вы фактически относите эту базу в одну из трех групп баз: редко реплицируемые базы (Low); базы, реплицируемые со средней частотой (Medium); базы, реплицируемые часто (High). Соответствующим образом составляя расписание, вы можете реплицировать критические базы данных более часто, чем другие. Например, базы с приоритетом High - несколько раз в день, базы с приоритетом Medium - один раз в день ночью, а базы с приоритетом Low - один раз в неделю по субботам. Для этого потребуется создать несколько документов Connection: например, один для баз только высокого приоритета, один для баз высокого и среднего приоритета и один для баз всех трех приоритетов.
Учтите, что документы Connection для баз данных различного приоритета не должны содержать перекрывающиеся отрезки времени. Если отрезки времени накладываются даже всего на минуту, расписание репликаций считается составленным некорректно. В этом случае репликации могут происходить беспорядочно или могут быть пропущены части списков реплицируемых баз.
|
Результат |
High Высокий |
High & Medium Средний и высокий |
|
Это правильно |
03:00 A.M. - 04:59 A.M. |
05:00 A.M - 10:00 P.M. |
|
Возможны проблемы |
03:00 A.M. - 06:00 A.M. |
05:00 A.M - 10:00 P.M. |
Сервер создает в своей виртуальной памяти список запланированных вами репликаций (расписание) из скрытого вида ($Connections) в общей адресной книге. Этот вид нельзя изменять, ибо в противном случае репликаторы всего домена не будет работать должным образом.
В документах Connection следует задавать полные имена связывающихся серверов. Часто начинающие администраторы задают неполные имена инициирующих репликацию серверов (например, InterTrust вместо InterTrust/InterTrustCorp/SU) и удивляются, почему в заданное время не происходит вызов. А вызов не происходит потому, что сервер (в этом примере InterTrust/InterTrustCorp/SU) "считает", что этот документ Connection "просто не имеет к нему никакого отношения" - документ должен "исполнять" несуществующий сервер InterTrust.
Подключение и исключение ПЯ пользователя к (от) СПЯ
Вы можете использовать Shared Mail, но выборочно исключить ПЯ некоторых пользователей от использования ими СПЯ. Для этого используется команда консоли:Load Object Set -Never USERMAIL.NSF ,
где USERMAIL.NSF - имя исключаемого ПЯ или имя каталога, содержащего исключаемые ПЯ.
После того, как вы используете эту команду, все сообщения, направляемые в соответствующие ПЯ, будут сохраняться в них полностью. Однако такого не будет происходить с теми ПЯ, которые "подключены" к СПЯ.
Чтобы повторно подключить к использованию СПЯ ранее "исключенные" ПЯ, используется команда консоли:
Load Object Reset -Never USERMAIL.NSF ,
где USERMAIL.NSF - имя "вновь подключаемого" файла ПЯ или имя каталога, содержащего "вновь подключаемые" ПЯ.
Подписанная почта
Когда пользователь при отправке документа почтой требует подписывать сообщение, Notes сначала вычисляет контрольную сумму подписываемых полей сообщения, шифрует ее личным ключом отправителя и сохраняют в дополнительном поле $Signature. Когда другой пользователь получает подписанное сообщение, Notes при наличии поля $Signature декодирует его содержимое публичным ключом отправителя и сверяет с вновь вычисленной контрольной суммой по подписываемым полям принятого сообщения. Если совпадение не обнаружено, получатель предупреждается об этом (диалоговое окно с кнопкой Ок и предупреждением о нарушении подписи). В типовой форме письма Notes подписываются поля SendTo, CopyTo, BlindCopyTo, From, FromDomain, Logo, Subject и Body, если пользователь требует подписывать письмо.
Рис. 9.32 Предупреждение о нарушении подписи
Подписанные секции в документе
В процессе создания формы разработчик может выбрать для поля атрибут signable ("подписываемое"). Если этот атрибут назначен некоторому полю в форме, то поле будет подписано всякий раз, когда отправляют почту, используя эту форму. Если подписываемое поле не входит в состав секции с управляемым доступом, подпись будет действовать только при отправке документа этой формы по почте, тогда как документы этой формы будут сохраняться в базе "неподписанными". При отсутствии секций с управляемым доступом при посылке почтой подпись сохраняется в дополнительном поле $Signature.
Рис. 9.33 Выбор для поля формы атрибута "подписываемое"
Секция с управляемым доступом - область формы с ограниченным доступом на редактирование. "Внутри" секции находятся одно или несколько полей данных. Если хотя бы одно из этих полей имеет атрибут "подписываемое", после сохранения созданного документа при его новом открытии вы увидите на месте заголовка секции с управляемым доступом "электронную подпись".
Рис. 9.34 "Электронная подпись" на заголовке секции документа
Секция с управляемым доступом, в которой есть подписываемые поля, "подписывается" при сохранении документа. Подпись сохраняется в поле $Sig_SectionName, где SectionName - название поля секции с управляемым доступом.
Каждая секция с управляемым доступом "хранит" только одну подпись. Если документ с одной секцией последовательно "подписывают" несколько лиц, на секции всякий раз "стоит" подпись последнего сохранившего документ лица, заменяя подпись ранее сохранившего документ лица.
Секция с управляемым доступом не может содержать вложенных секций с управляемым доступом. Однако документ может иметь больше чем одну секцию с управляемым доступом. Например, каждому подписывающему документ лицу разработчик может предусмотреть свою секцию. В результате документ может иметь много подписей, каждая из которых хранится в собственном поле $Sig_SectionName. При открытии такого документа Notes проверяет все подписи. Чтобы при сохранении документа очередным подписывающим лицом сохранились подписи предыдущих (т.е. их секции не были "пере-подписаны" данным лицом), текущее лицо должно иметь доступ к "чужим" секциям только на чтение.
Рис. 9.35 Фрагмент документа, содержащего две "электронные подписи"
Поле Cutoff Date и история репликаций базы
Проверки поля Cutoff Date и истории репликаций позволяют репликатору максимально сократить множество документов, просматриваемых на предмет возможного участия в репликации.Поле Cutoff Date
(в версиях 4.х метка поля Only replicate incoming documents saved or modified after:) требует при репликациях принимать в данную реплику только те документы, которые имеют дату модификации позже указанной в поле.
Документы из других реплик этой базы с датой модификации до Cutoff Date никогда не включаются в списки реплицируемых документов и, следовательно, никогда не будут приняты в эту реплику. Репликатор всегда проверяет Cutoff Date и принимает в "свою" реплику только документы, созданные или измененные после этой даты. Аналогично и "окурки" документов, удаленных ранее Cutoff Date, не будут приниматься в реплику этой базы с других серверов. Даже если вы очищаете "историю репликаций".
Рис. 6.15 История репликаций - база на сервере NotesSrv400 в последний раз "отправляла" изменения на сервер InterTrust в 11:10:13, а принимала с него изменения в 10:47:49
Рис. 6.16 История репликаций - база на сервере InterTrust в последний раз "отправляла" изменения на сервер NotesSrv400 в 10:47:49, а принимала с него изменения в 11:10:13
История репликаций содержит время и дату последней успешной репликации с перечисленными в записях истории серверами. Notes при очередной репликации будет при составлении списков реплицируемых документов учитывать только документы, добавленные, измененные или удаленные по времени позднее времени из записи в истории репликаций для этого сервера. После очередной успешной репликации с этим сервером относящиеся к нему записи в истории репликаций заменяются. Если списки истории на обеих сторонах не согласованы (например, если вы очищаете историю на одной стороне), в базе данных будут проверены на предмет участия в репликации все документы, более новые, чем Cutoff Date базы.
При некоторых ситуациях может быть даже полезно очистить историю, потому что этим вы обеспечите полную проверку всех документов в базе на предмет репликации. Вот одна из множества таких ситуаций. Предположим, в документах базы имелись поля типа Readers, в которых использовались имена групп. Ваш сервер не входил ни в одну из этих групп, и такие документы были серверу "не видны", а потому и не реплицировались. Вы добавили имя сервера в состав групп, и теперь хотите реплицировать "прежде невидимые" документы. Но не тут то было... Теперь эти документы стали "видны" серверу, но не реплицируются, поскольку изменения в составе групп не привели к модификации самих документов, а согласно истории репликаций эти документы уже не учитываются.
Так что, если базы данных после репликации не синхронизированы или не имеют одинакового количества документов, причиной этого могли бы быть Cutoff Date или история репликаций. Но не только они.
Полнотекстовый поиск по многим базам данных
Для обеспечения этой возможности создается специальная база данных (типа Multi DB Search) - Search Site. Имеющиеся в базе Search Siteдокументы определяют область поиска
- набор баз данных, по которым должен осуществляться поиск информации. Эти базы данных могут находиться как на том же сервере, что и база Search Site, так и на других серверах домена или серверах из других доменов. Затем для базы Search Site
создается индекс полнотекстового поиска. Однако, поскольку мы имеем дело с базой типа Multi DB Search, в ее индекс полнотекстового поиска будет включена информация из баз, входящих в ее область поиска, а не из самой базы Search Site. Храниться же этот индекс, обычно немалого размера, будет в каталоге SEARCHSITE.FT, где SEARCHSITE
- имя файла базы Search Site.
Пользователь, чтобы осуществить поиск информации по многим базам данных, открывает базу Search Site. Обычно при этом автоматически открывается поисковая форма. Пользователь заполняет поля поисковой формы, вводя поисковый запрос и, если надо, уточняя подобласть поиска. Синтаксис поисковых запросов практически такой же, как и для поисковых запросов по обычным базам данных.
Рис. 10.13 Пример поискового запроса
"В ответ" пользователь получает "обзорный" документ, содержащий список названий удовлетворяющих его запросу документов и ссылок на них. Выполняя "переход по ссылке", пользователь может открыть найденный документ, если конечно имеет к содержащей его базе и самому документу доступ читателя.
Рис. 10.14 Пример "ответа" на поисковый запрос
Может быть создано несколько баз Search Site. Например, одна из них имеет область поиска по базам данных, содержащим информацию маркетингового характера, другая - в базах данных, содержащим информацию по вопросам технической поддержки, и т.п.
Рассмотрим шаг за шагом те действия, которые необходимо выполнить, чтобы создать, сконфигурировать и обеспечить работоспособность базы Search Site.
1. Разрешение на участие в полнотекстовом поиске по многим базам
· Domain - в область поиска включаются все базы данных на серверах из домена Domain, у которых выбрано свойство Include in multi database indexing.
Кроме того, для набора баз, "описываемого" таким документом, выбирается опция индексирования по умолчанию, обычно Index Full Document.
Рис. 10.16 Пример документа формы Search Score Configuration
После этого на сервере, содержащем базу Search Site, запускают задачу UPDALL со следующими параметрами
Load UPDALL SEARCHSITE [-B] ,
где SEARCHSITE
- имя файла базы Search Site, а -B - необязательный, но желательный в данной ситуации ключ. Ключи этой задачи, относящиеся к вопросам полнотекстового поиска по многим базам данных, рассматриваются ниже.
Задача UPDALL, обнаружив, что база SEARCHSITE имеет тип Multi DB Search, по содержащемуся в этой базе в документах Search Score Configuration "предварительному" описанию области поиска создает "рабочее" описание области поиска, в котором каждая входящая в область поиска база представлена своим документом Database Entry.
Рис. 10.17 Пример документа Database Entry
После этого в документе Database Entry можно изменить только используемую для конкретной базы опцию индексирования и вид, применяемый для поиска документов.
Следующие два примера позволяют лучше понять принцип формирования области поиска.
Пример 1. В домене имеется шесть серверов, и требуется обеспечить возможность поиска по всем базам данных, кроме баз данных на двух серверах. Для этого следует создать один документ Search Score Configuration с опцией индексирования Index Full Document для поиска в пределах домена, а затем создать два документа Search Score Configuration с опцией индексирования No Index для каждого сервера, в базах на котором не должен выполняться поиск. Все базы данных со свойством Include in multi-database indexing на всех серверах будут включены в "рабочую" область поиска, но для баз, расположенных на "не участвующих" в поиске серверах, в документах Database Entry будет выбрано No Index.
Пример 2. Имеется десять баз данных, по которым должен выполняться полнотекстовый поиск. Они находятся на двух серверах. Если только для этих баз данных выбрано свойство Include in multi-database indexing, достаточно создать два документа Search Score Configuration
для поиска в пределах сервера. Все базы данных, для которых выбрано свойство Include in multi-database indexing, будут включены в "рабочую" область поиска. Если же на серверах имеются некоторые базы данных, у которых выбрано свойство Include in multi-database indexing, но они не должны включаться в область поиска данной базы Search Site, опять следует создать два документа Search Score Configuration для поиска в пределах сервера. Но затем следует модифицировать в базе Search Site
документы Database Entry, выбрав для тех баз, которые не должны включаться в область поиска данной базы Search Site, опцию No Index.
Рассмотрим ключи задачи UPDALL, относящиеся к вопросам полнотекстового поиска по многим базам данных.
· Ключ - A требует для баз типа Multi DB Search не обновлять названия баз данных и список видов в документах Database Entry. Однако документы Search Score Configuration
типа Server и Domain, изменившиеся с предыдущего запуска задачи UPDALL, обрабатываются. Обновление индексов полнотекстового поиска выполняется как для баз типа Multi DB Search, так и для "обычных" баз.
· Ключ - B
требует для баз типа Multi DB Search обновить все "рабочее" описание области поиска, но не выполнять обновления индексов полнотекстового поиска. Обновление индексов полнотекстового поиска для "обычных" баз выполняется.
4. Создание индекса полнотекстового поиска базы Search Site
Создание индекса полнотекстового поиска для базы Search Site выполняется обычным образом. Один из вариантов - с закладки Full Text в окне свойств базы. Другой вариант - из окна Server Administration кнопкой Database Tools с последующим выбором "инструмента" Full Text Index. Следует только учитывать, что обычно такие индексы имеют достаточно большой размер и требуют немалого времени на их построение. Поэтому не следует выбирать "излишних" опций создаваемого индекса. Обновлять же такие индексы рекомендуется не чаще раза в день.
5. Передача базы Search Site в эксплуатацию
Убедившись, что база данных нормально функционирует, следует восстановить автоматическое открытие поисковой формы, выбрав в окне свойств базы на закладке Launch в поле On database open: значение Launch 1st doclink in "About database", и выбрать в списке управления доступом Reader для -Default-.
Пользователь изменяет свое имя по почте
1. Пользователь выбирает в меню File - Tools - User ID, затем закладку More Options и на ней кнопку Request New Name. Вводит новое имя и нажимает кнопку OK, затем выбирает адрес своего сертификатора, дописывает свой текст в письмо и отправляет его кнопкой Send.2. Сертификатор из открытого письма выбирает Actions - Certify Attached ID File, заполняет окно по изменению имени пользователя в документе Person, заполняет окно по формированию обратного письма, затем выбирает изменение имени в группах адресной книги, списках управления доступом почтового ящика и других баз, а так же в полях типа Readers и Authors вручную или с помощью задачи Administration Process.
3. Пользователь из открытого письма выбирает Actions - Accept Certificate. В любом случае после этого пользователя могут ожидать определенные проблемы, подобные рассмотренным при ресертификации с использованием почты. Однако если сертификатор возложил их решение на задачу Administration Process, они будут решены автоматически спустя некоторое время.
Пользователь заменяет свой публичный ключ
Обычно пользователь решает сменить публичный ключ в случае, когда знает или подозревает, что у него был похищен ID-файл и "злоумышленнику" известен его пароль.Прежде всего давайте обсудим, что собственно может дать смена публичного (и связанного с ним личного) ключа. Предварительно пользователь должен "расшифровать" зашифрованную почту в своем почтовом ящике и базы данных, для которых было применено локальное шифрование, иначе он рискует потерять все это. Все выпущенные для пользователя взаимные сертификаты станут недействительными (поскольку публичный ключ изменяется) и их придется получать снова. Незначительным преимуществом смены публичного ключа по сравнению с регистрацией заново, но под прежним именем, является сохранение имеющихся в ID-файле ключей шифрования. Однако их обычно можно "выгрузить" из прежнего ID-файла и "загрузить" в новый. Процесс установления подлинности (процедура аутентификации) будет с одинаковым успехом выполняться и для ID-файла пользователя с новыми ключами, и для похищенной копии со старыми ключами. Если вы сомневаетесь в справедливости последнего факта, еще раз внимательно рассмотрите алгоритм процесса установления подлинности в 8.3. Поэтому администратор может предотвратить доступ "злоумышленника" под похищенной копией ID-файла к серверам только в том случае, если во всех документах Server запросит сравнение значения публичного ключа из ID-файла со значением, сохраненным в документе Person. Администратор может сделать это, если к серверам имеют доступ только пользователи и другие серверы этого домена. Если же к серверам домена имеют доступ многие пользователи и серверы других доменов, такой путь по практическим соображениям отпадает. Тогда остается только возможность зарегистрировать пользователя под новым именем, а "старое" имя внести в группу Terminations, доступ членов которой запрещен ко всем серверам домена.
Элегантный выход из ситуации с похищением ID-файла имеется только при использовании Notes версий от 4.5. При этом не нужно менять публичный ключ - достаточно сменить пароль в ID-файле и обратиться к администратору, чтобы тот обеспечил доступ ко всем серверам только ID-файла с новым паролем (см. 8.5.9).
Техника смены публичного ключа такова.
1. Пользователь выбирает в меню File - Tools - User ID, затем закладку More Options и на ней кнопку New Public Key. В течение 1-3 минут происходит генерация пары ключей (публичного и личного). В следующем окне пользователь выбирает адрес администратора или своего сертификатора, дописывает свой текст в письмо и отправляет его кнопкой Send.
2. Сертификатор из открытого письма выбирает Actions - Certify Attached ID File, далее кнопку Recertify, после чего осуществляет формирование обратного письма.
3. Пользователь из открытого письма выбирает Actions - Accept Certificate.
протокол Internet, позволяющий любому клиенту,
POP3 Post Office Protocol версии 3 (POP3) - протокол Internet, позволяющий любому клиенту, поддерживающему POP3 (например, Microsoft Internet Explorer, Netscape Navigator, Eudora Pro и др.), получать почту с любого POP3-сервера.Чтобы использовать сервер Notes как POP3-сервер, на нем запускают задачу POP3, а для каждого POP3-пользователя создают почтовый ящик и документ Person в общей адресной книге. Задача POP3
функционирует на сервере постоянно и ожидает запросов на соединения от POP3-клиентов по протоколу TCP/IP на порту 110. Станция Notes
на компьютере POP3-клиента не запускается и может быть вообще не установлена. Клиент, используя приложение Microsoft Internet Explorer, Netscape Navigator или Eudora Pro, периодически соединяется с сервером по протоколу TCP/IP, порт 110, чтобы "забрать" к себе свою почту. Когда клиент устанавливает соединение, задача POP3 опознает клиента, используя стандарт POP3 для установления подлинности. Это сводится к правильному вводу имени клиента и соответствующего пароля. Если установление подлинности клиента прошло успешно, задача POP3 дает клиенту возможность "забрать" к себе новую почту из его почтового ящика на сервере.
Рис. 3.33 Доступ к почтовому ящику на сервере Notes по протоколу POP3
Вопросы настройки задачи POP3, создания почтового ящика и документа Person для POP3-клиента и настройки программного обеспечения POP3-клиента (на примере Microsoft Internet Explorer) рассматриваются в 10.3.
Пример применения кластера
Рассмотрим пример, в котором применение кластера решает сразу массу проблем. Этот пример позволит вам понять основные принципы применения кластеров, и далее, "через призму этого примера", легче воспринимать приводимый материал.Исходно в домене (см. Рис. 10.11) имелось два сервера баз данных (Navy и Royal) и один коммуникационный сервер. Сервер Navy использовался в основном как почтовый сервер - он содержал почтовые ящики всех пользователей домена. Сервер Royal содержал две "критические" для бизнес-процесса компании базы данных SALES.NSF и PARTS.NSF. Кроме того, на обоих серверах имелись и другие, менее часто используемые базы данных.
Из-за увеличения количества пользователей в домене резко возросла рабочая нагрузка как на почтовую систему, так и на базы данных, особенно SALES.NSF и PARTS.NSF. Кроме того, когда один из серверов останавливается на профилактику, пользователи теряют возможность обратиться к их почте на сервере Navy или к базам данных на сервере Royal.
Чтобы решить эти проблемы, создаем кластер из двух существующих серверов (Navy и Royal) и нового сервера True. При планировании кластера используем следующие соображения.
Рис. 10.11 Пример кластера из трех серверов Notes
· Выбираем аппаратную платформу нового сервера так, чтобы общая вычислительная мощность трех серверов с определенным запасом позволяла справиться с имеющейся рабочей нагрузкой.
· Создаем дополнительные реплики баз данных на серверах кластера так, чтобы при сбое или отключении на профилактику любого одного из серверов пользователи могли обратиться к их репликам на каком-то из серверов, продолжающих функционировать.
· Поскольку базы SALES.NSF и PARTS.NSF наиболее критичны для бизнес-процесса, создаем их реплики на каждом из трех серверов кластера. Посредством внутрикластерных репликаций изменения из одной реплики "в реальном времени" будут распространяются в реплики на других серверах. За счет переключений (failover) доступ к этим базам будет возможен, даже если откажут два из трех членов кластера. В нормальном же режиме работы пользовательские запросы к этим базам должны "распределяться" по всем трем серверам, благодаря чему будет обеспечено малое время отклика.
· Чтобы обеспечить доступность почты, создадим по две реплики почтового ящика каждого пользователя на разных серверах кластера. Распределим файлы почтовых ящиков так, чтобы на каждом сервере имелось примерно две трети от увеличенного вдвое общего количества файлов почтовых ящиков. В документах Person распределим почтовые серверы (поле Mail Server) внутри кластера так, чтобы на каждый сервер приходилось примерно одна треть пользователей. Имея две реплики каждого почтового ящика на разных серверах кластера и благодаря переключениям (failover), обеспечиваемым кластером, мы гарантируем, что пользователь будет способен и посылать и получить почту, даже если его почтовый сервер не функционирует.
· Может быть желательно создать дополнительные реплики некоторых других баз данных, чтобы обеспечить их более высокую доступность.
· В качестве дополнительной меры можно рекомендовать создание отдельного сегмента локальной сети между серверами кластера и настройку серверов кластера так, чтобы весь внутрикластерный обмен происходил именно по этому сегменту сети.
Примеры доставки почты при наличии документов Domain
Домен Dom1 состоит из 4 серверов в 2 поименованных сетях Notes - Net1 (серверы s1, s2, s3, протокол SPX) и Net2 (серверы s3 и s4, протокол NETBIOS). В адресной книге имеется два документа Connection: s2 ® s6 (домен Dom2) и s4 ® s5 (домен Dom2). Кроме того, имеется документ Non-adjacent Domain: почту, адресованную в домен Dom3, следует отправлять в домен Dom2.Домен Dom2 имеет 2 сервера s5 и s6 в одной поименованной сети (например, Net1, протокол TCP IP). В адресной книге 3 документа Connection: s6 ® s7 (домен Dom3), s6
® s2 (домен Dom1) и s5
® s4 (домен Dom1).
Домен Dom3 имеет 2 сервера s7 и s8 в одной поименованной сети (например, Net3, протокол NETBIOS поверх NETBEUI). В адресной книге один документ Connection:
s7 ® s6 (домен Dom2) и один документ Non-adjacent Domain, согласно которому почту, адресованную в домен Dom1, следует отправлять в домен Dom2.
Рис. 7.12 Конфигурация сети Notes
Обратите внимание, что в следующих примерах имеется в виду, но для простоты не оговаривается тот факт, что Router-ы работают с информацией из документов адресной книги, уже загруженной в таблицы маршрутизации в виртуальной памяти, а не с реальными документами из адресной книги.
Один домен, разные поименованные сети
Пользователь u1/Org1 из домена Dom1 (почтовый сервер s1) посылает сообщение пользователю u2/Org1 из домена Dom1 (почтовый сервер s4). В поле SendTo сообщения: u2/Org1.
1. Mailer на станции u1 проверяет адрес в поле SendTo. "Свой" домен. Получатель u2/Org1 имеется в адресной книге. Mailer помещает сообщение в MAIL.BOX на s1.
2. Router на сервере s1 проверяет адрес получателя сообщения и его документ Person, и определяет, что почтовый ящик получателя u2/Org1 находится на сервере s4. Router проверяет документы Server и узнает, что s1 в поименованной сети Net1, s4 в поименованной сети Net2, и s3 в обеих поименованных сетях Net1 и Net2. Router соединяется напрямую с сервером s3 и помещает сообщение в MAIL.BOX на s3.
3. Router на сервере s3 проверяет документ Person получателя и определяет, что его почтовый ящик на сервере s4. Router проверяет документы Server и "узнает", что s4 в той же самой поименованной сети Net2. Router соединяется напрямую с сервером s4 и помещает сообщение в MAIL.BOX на s4.
4. Router на сервере s4 проверяет документ Person и определяет, что почтовый ящик получателя находится "на нем самом". Router помещает сообщение в почтовый ящик получателя.
5. Mailer на станции u2 (если она работает и на ней запущен Notes) проверяет почтовый ящик пользователя каждые 15 минут. Он обнаруживает "непрочитанное" сообщение и информирует пользователя: "You have new mail".
Разные домены, разные поименованные сети
Пользователь u1/Org1 из домена Dom1 (почтовый сервер s1) посылает почту пользователю u3/Org3 из домена Dom3 (почтовый сервер s8). В поле SendTo сообщения: u3/Org3 @ Dom3.
1. Mailer на станции u1 проверяет адрес в поле SendTo. Mailer "видит", что сообщение адресовано в другой домен, следовательно, проверить адрес получателя не представляется возможным. Поэтому Mailer просто помещает сообщение в MAIL.BOX на s1.
2. Router на сервере s1 проверяет адрес в поле SendTo и "видит", что получатель в другом домене. Router проверяет документы Domain и "узнает", что почту в домен Dom3 следует отправлять в домен Dom2. Router проверяет документы Connection на любой сервер в домене Dom2 и находит, что сервер s2 может соединяться с сервером s6 из домена Dom2 и сервер s4 тоже может соединяться с сервером s5 из Dom2. Router определяет маршрут "наименьшей стоимости", в данном случае s1®s2®s6 (стоимость 1+5=6). Следующий сервер в маршруте s2. Router проверяет документы Server и находит, что s2 в той же самой поименованной сети, что и s1. Router напрямую соединяется с s2 и помещает сообщение в MAIL.BOX на s2.
3. Router на сервере s2 проверяет адрес в поле SendTo и "видит", что получатель в другом домене. Router проверяет документы Domain и обнаруживает, что почта в домен Dom3 должна отправляться в домен Dom2. Router проверяет документы Connection "на домен" Dom2 и находит, что сервер s2 ("он сам") может соединяться с сервером s6 из Dom2 и сервер s4 может соединяться с сервером s5 из Dom2. Router выбирает маршрут "наименьшей стоимости": s2®s6 (стоимость 5). Следующий сервер в маршруте s6. Router соединяется с сервером s6 (согласно документу Connection и с учетом приоритета сообщения) и помещает сообщение в MAIL.BOX на s6.
4. Router на сервере s6 проверяет адрес в поле SendTo. Разные домены. Router проверяет документы Domain и не находит ничего полезного. Router проверяет документы Connection "на домен" Dom3 и находит, что сервер s6 может соединяться с сервером s7 из Dom3. Router находит маршрут наименьшей стоимости на сервер назначения: s6®s7 (стоимость 5). Следующий сервер на маршруте s7. Router соединяется с сервером s7 (согласно документу Connection и с учетом приоритета сообщения) и помещает сообщение в MAIL.BOX на s7.
5. Router на сервере s7 проверяет адрес в поле SendTo. Получатель из "своего" домена. Router проверяет документ Person получателя и "узнает", что его почтовый ящик находится на сервере s8. Router проверяет документы Server и узнает, что s8 в одной с ним поименованной сети. Router напрямую соединяется с s8 и помещает сообщение в MAIL.BOX на s8.
6. Router на сервере s8 помещает сообщение в почтовый ящик получателя.
7. Mailer на станции u3 сообщает получателю: "You have new mail".
Примеры доставки почты
Рассмотрим различные варианты доставки почты в конфигурации, приведенной на Рис. 7.8. Имеется три домена. В домене X две поименованных сети Notes: в состав первой входят серверы A, B и C, в состав второй - серверы J, K и H. В адресной книге этого домена три документа Connection: два между серверами A и J (типа Dialup Modem), и один с сервера K на сервер Q из домена Y(тоже типа Dialup Modem). Все серверы домена Y в одной поименованной сети. В адресной книге домена Y два документа Connection: один с сервера Q на сервер K из домена X (типа Dialup Modem), а второй - с сервера S на сервер T из домена Z
(типа Local Area Network). В домене Z одна поименованная сеть, а в адресной книге один документ Connection - с сервера T на сервер S из домена Y (типа Local Area Network).
У пользователей один и тот же почтовый сервер
Jon, чей почтовый сервер - A, посылает сообщение Ed, чей почтовый сервер тоже A. Сообщение поступает из почтового ящика Jon в MAIL.BOX на сервере A. Обнаружив сообщение в своем MAIL.BOX, Router перемещает его в почтовый ящик Ed.
Рис. 7.8 Конфигурация сети Notes
Одна и та же поименованная сеть, но разные почтовые серверы
Jon посылает сообщение Peggy, чей почтовый сервер - C. Router на сервере А просматривает адресную книгу для определения местоположения почтового ящика Peggy. Он обнаруживает, что файл почты Peggy
находится на сервере C, который в той же поименованной сети, что и А, устанавливает соединение с сервером C
и передает сообщение в MAIL.BOX на сервере C. Router на сервере C перемещает сообщение в файл почты Peggy.
Разные поименованные сети
Peggy, чей почтовый сервер C, посылает сообщение Bud. Router на сервере C проверяет адресную книгу и обнаруживает, что почтовый сервер Bud называется H и находится в другой поименованной сети. Router проверяет документы Connection, находит, что сервер A имеет соединение с сервером J, который в одной поименованной сети с H, и передает сообщение с C на A. Когда наступает указанное в расписании время передачи почты, сервер А передает сообщение на сервер J. Router на сервере J проверяет адресную книгу и поставляет сообщение в MAIL.BOX на сервере H. Router на сервере H перемещает сообщение в файл почты Bud.
Разные домены
Peggy из домена X посылает сообщение Sue из домена Y. Документ Connection в адресной книге показывает, что сервер K из домена Peggy может связываться с сервером Q в домене Sue. Сообщение перемещается с почтового сервера Peggy, C, на сервер A, через модемное соединение на J, и далее на K по локальной сети. Сервер K передает сообщение на сервер Q. Router на Q находит в адресной книге домена Sue почтовый сервер Sue, R, и отправляет сообщение на сервер R. Router на R помещает сообщение в почтовый ящик Sue.
Одна и та же локальная сеть, но разные домены и поименованные сети
Sue из домена Y посылает сообщение Bob из домена Z. Router исследует адресную книгу домена Y и находит документ Connection, показывающий, что сервер S может соединяться с сервером T в домене Bob. Сообщение передается по локальной сети с почтового сервера Sue, R, на сервер S, и с него на T. Сервер T отправляет сообщение на почтовый сервер Bob, где Router помещает сообщение в файл почты Bob.
Принцип работы SMTP MTA
Рассмотрим принцип работы SMTP MTA - агента, осуществляющего обмен сообщениями между пользователями Notes и пользователями Internet.
Рис. 7.13 Принцип работы SMTP MTA
Задача SMTPMTA, ее подзадачи и используемые ими базы данных
Контроллер подзадач (SMTPMTA) - задача, загружаемая на сервере Notes, например, командой консоли Load SMTPMTA. При старте он запускает и далее "контролирует" выполнение всех других подзадач агента. Все команды, передаваемые задаче SMTPMTA по команде консоли Tell, передаются ею соответствующим "подчиненным" подзадачам.
Конвертор исходящих сообщений (Outbound Message Converter, SMTPMTA OMSGCNV) преобразует сообщения из формата Notes в формат SMTP/MIME, подготавливая их для передачи. Контроллер исходящих сессий (Outbound Session Controller, SMTPMTA OSESCTL) управляет процессами передачи преобразованных сообщений по соответствующим SMTP-адресам. Он запускает очередной и (или) сообщает первому свободному из числа уже запущенных драйверов исходящих сессий, чтобы драйвер выполнил передачу одного или нескольких исходящих сообщений конкретному адресату. Драйвер исходящей сессии (Outbound Session Handler, SMTPMTA OSESHLRn) выполняет фактическое соединение непосредственно с почтовым сервером адресата или следующим почтовым сервером в SMTP-системе и доставляет сообщения, а также сообщает контроллеру о любых ошибках временного или постоянного характера.
Контроллер входящих сессий (Inbound Session Controller, SMTPMTA ISESCTL) управляет получением сообщений от других SMTP-систем. Он постоянно ожидает запроса на установление соединения с ним по порту 25, используемому протоколом SMTP. Протокол SMTP - высокоуровневый протокол для передачи почты поверх протокола TCP/IP. Когда запрос на соединение принят, он запускает очередной и (или) "передает" соединение первому свободному из числа уже запущенных драйверов входящих сессий, а "сам возвращается" в режим ожидания новых соединений. Драйвер входящей сессии (Inbound Session Handler, SMTPMTA ISESHLRn) получает входящее соединение от контроллера входящих соединений. Он принимает передаваемое ему сообщение в соответствии с протоколом SMTP и записывает принятое сообщение в очередь входящих сообщений. Конвертор входящих сообщений (Inbound Message Converter, SMTPMTA IMSGCNV) преобразует сообщения, полученные драйверами входящих сессий, в формат Notes. При этом в формат Notes преобразовывается и адрес получателя, а также выполняется проверка, возможно ли это сообщение доставить. Если сообщение не удается конвертировать или если оно не может быть доставлено, формируется сообщение о недоставке. Если же сообщение не предназначено для Notes, оно перемещается в очередь на отправку.
По каждому сообщению каждая задача информирует задачу Delivery Report Task (SMTPMTA DRT), была ли ее работа успешно выполнена или произошла ошибка временного или постоянного характера. Delivery Report Task обрабатывает сообщения в очередях в зависимости от их состояния. Сообщения, которые были успешно посланы или получены, удаляются из очередей. На сообщения, для которых возникла ошибка постоянного характера, формируется отчет о недоставке или сообщение администратору о наличии "мертвой" почты.
База данных SMTP.BOX создается во время установки SMTPMTA по шаблону SMTPBOX.NTF. В эту базу серверная задача Router осуществляет доставку сообщений, подлежащих конвертации и отправке. Конвертор исходящих сообщений опрашивает эту базу данных с определенным интервалом. Конвертированные сообщения не удаляются из базы до тех пор, пока они не будут доставлены или пока для них не будет сгенерировано сообщение о недоставке.
База данных Outbound work queue (SMTPOBWQ.NSF) используется для временного хранения для конвертированных сообщений, которые или ожидают отправки, или для которых отправка завершилась неуспешно, и теперь они ожидают обработки задачей Delivery Report Task.
База данных Inbound work queue (SMTPIBWQ.NSF) используется для временного хранения принятых драйверами входных сессий и ожидающих конвертации сообщений, а так же сообщений, ожидающих обработки задачей Delivery Report Task.
База данных MTA Tables database (MTATABLES.NSF) используются совместно как SMTP MTA, так и X400 MTA, как поисковая таблица для выбора набора символов и идентификации типов файлов, а также как таблица перекрестных связей между типами/подтипами MIME и расширениями файлов.
Доставка сообщения из Notes в Internet
1. Пользователь Notes создает почтовое сообщение, но в поле адреса (поле SendTo, метка поля To:) задает адрес в формате SMTP, например, iontsev@inttrust.msk.ru. Сообщение отправляется по почте Notes.
2. Серверная задача Mail Router анализирует адрес сообщения и распознает, что адрес задан не в формате Notes, а в формате SMTP. Далее Mail Router использует информацию из документа Foreign SMTP Domain. В простейшем случае в этом документе "сказано", что все сообщения с SMTP-адресами должны передаваться в домен с некоторым именем, например, SMTPMAIL. Далее Mail Router использует информацию из документа Connection типа SMTP. В простейшем случае в этом документе "сказано", что некоторый сервер Notes из текущего домена Notes, например, NotesSrv400/InterTrustCorp/SU, "умеет" соединяться с почтовым сервером Internet из домена SMTPMAIL, а так же задано SMTP-имя этого почтового сервера Internet, например, inttrust.space.ru, и, возможно, его IP-адрес. В действительности и этот сервер Notes (в нашем случае NotesSrv400/InterTrustCorp/SU), и почтовый сервер Internet физически функционируют на одном и том же компьютере, причем роль почтового сервера Internet выполняет агент SMTP MTA - одна из задач сервера Notes.
3. Сообщение доставляется почтой Notes до такого сервера Notes, в данном случае NotesSrv400/InterTrustCorp/SU. Задача Mail Router на этом сервере помещает это сообщение в базу данных SMTP.BOX. Обратите внимание, что SMTP.BOX - предопределенное имя, оно не задается в настроечных документах.
4. Подзадача Outbound Message Converter периодически опрашивает базу SMTP.BOX на предмет появления новых сообщений. Период опроса задается в документе Server в секции Internet Message Transfer Agent (SMTP MTA) в поле с меткой Poll for new messages every [120] seconds. Когда подзадача находит в SMTP.BOX новое сообщение, она преобразует его в формат Internet (RFC 822) и записывает в базу Outbound Work Queue. При преобразовании адреса отправителя из формата Notes в формат SMTP используется информация из документа Global Domain. При этом исходящее сообщение не удаляется из SMTP.BOX - подзадача лишь "устанавливает" для данного сообщения в SMTP.BOX статус "Ожидает отправки".
5. Подзадача Outbound Session Controller считывает сообщение из очереди на передачу (Outbound Work Queue) и "сообщает" первой или очередной созданной ею подзадаче Outbound Session Handler идентификатор этого сообщения. Подзадача Outbound Session Controller может по умолчанию создать до трех подзадач Outbound Session Handler, а администратор может управлять их количеством. При возможности Outbound Session Controller группирует сообщения на один и тот же хост "в один пакет".
6. Подзадача Outbound Session Handler по адресу получателя сообщения (например, iontsev@inttrust.msk.ru), используя сервер DNS, определяет имя компьютера назначения и его IP-адрес (в нашем примере им окажется хост sequent.kiae.su,
193.125.152.6). Далее подзадача открывает соединение с компьютером назначения и передает данное сообщение, используя драйвер протокола SMTP. Если сообщение было успешно передано на компьютер назначения, подзадача Outbound Session Handler изменяет статус этого сообщения в очереди Outbound Work Queue на "Доставлено". Если же сообщение не удалось доставить - например, компьютер назначения в данный момент недоступен - сообщение "возвращается" в очередь Outbound Work Queue, где некоторое время ожидает очередной попытки доставки. Если сообщение не удалось доставить за определенное количество попыток, или если не удается определить IP-адрес компьютера назначения, или если адресат (в нашем примере это iontsev) на компьютере назначения неизвестен, сообщение получает статус "Невозможно доставить".
7. Доставленные сообщения (со статусом "Доставлено") подзадача Delivery Report Task удаляет из Outbound Work Queue и SMTP.BOX. Для сообщений, которые не удалось доставить (со статусом "Невозможно доставить") подзадача Delivery Report Task генерирует и отправляет отправителю почтой Notes уведомление о недоставке, и после этого также удаляет такие сообщения из Outbound Work Queue и SMTP.BOX.
Доставка сообщений из Internet в Notes
1. Подзадача Inbound Session Controller "пассивно прослушивает" (функция listen() в интерфейсе сокетов) используемый протоколом SMTP порт 25 в ожидании запроса на соединение от какого-нибудь почтового сервера Internet. Обнаружив запрос на соединение, она передает этот запрос для обработки первой или очередной созданной ею подзадаче Inbound Session Handler, и продолжает "прослушивать" порт 25. Подзадача Inbound Session Controller по умолчанию может создать до 3-х подзадач Inbound Session Controller, а администратор может изменить максимальное количество создаваемых подзадач.
2. Подзадача Inbound Session Handler принимает SMTP-сообщение и записывает его в очередь Inbound Work Queue в формате RFC822.
3. Подзадача Inbound Message Converter читает сообщение из Inbound Work Queue и анализирует адрес получателя. Если сообщение адресовано не в домены Internet, перечисленные в списках в документе (документах) формы Global Domain, подзадача переносит это сообщение Outbound Work Queue для последующей доставки в место назначения. Если же адрес принадлежит домену Internet из списка, адрес конвертируется в формат Notes. Если сообщение может быть доставлено по почте Notes, оно преобразуется в формат Notes и помещается в MAIL.BOX сервера. Дальнейшей доставкой такого сообщения будут заниматься задачи Mail Router на серверах Notes. Если же сообщение не может быть доставлено адресату в Notes или не может быть преобразовано в формат Notes, подзадача Inbound Message Converter передает идентификатор этого сообщения подзадаче Delivery Report Task.
4. Подзадача Delivery Report Task формирует в адрес отправителя сообщение о недоставке - Non-delivery Report - которое помещается в очередь Outbound Work Queue. Доставкой уведомления о недоставке далее занимаются подзадачи Outbound Session Controller и Outbound Session Handler.
Присоединение и "пере-присоединение" ПЯ к СПЯ
После того, как вы разрешаете использовать Shared Mail на сервере, Notesстанет автоматически сохранять тела всех новых сообщений в СПЯ.
Чтобы сохранять в СПЯ тела тех сообщений из ПЯ, которые были доставлены в них прежде, чем вы разрешили использование Shared Mail на сервере, или в то время, пока Shared Mail на сервере была временно заблокирована, следует "присоединить" файлы ПЯ к СПЯ. Часто это позволяет сохранить значительное количество дискового пространства. Для этого с консоли вводится команда
Load Object Link USERMAIL.NSF SHARED.NSF ,
где USERMAIL.NSF - имя ПЯ пользователя или имя каталога, содержащего ПЯ пользователей, а SHARED.NSF - имя СПЯ.
Команда перемещает тело каждого сообщения из ПЯ в СПЯ. Если из ПЯ в СПЯ будет перемещено более пяти тел сообщений, исходный ПЯ будет автоматически уплотнен, чтобы дисковое пространство, которое было занято телами сообщений в ПЯ пользователя, освободилось. Если вместо имени ПЯ в команде был указан каталог, операция будет выполнена на всех ПЯ из этого каталога (но не рекурсивно в его подкаталогах).
Имеется также и опция -Nocompact, "запрещающая" команде Object Link выполнять при присоединении уплотнение обработанных ПЯ.
> load object link mail\asavelye.nsf mail\shared.nsf
03.09.96 12:17:32 Object Store Manager: Process started
03.09.96 12:17:32 Object Store Manager: Linking mail\asavelye.nsf to object store mail\shared.nsf
> sh ta
Lotus Notes ® Server (International English R4.1 for Windows/32) 03.09.96 12:18:02
Server name: NotesSrv400/InterTrustCorp/SU - Win NT 3.51
Server directory: e:\notes400\data
Elapsed time: 01:44:41
Transactions/minute: Last minute: 2; Last hour: 6; Peak: 95
Peak # of sessions: 7 at 03.09.96 11:28:38
Transactions: 1388
Shared mail: Enabled for delivery
Shared mail database: e:\notes400\data\MAIL\Shared.nsf (18071552 bytes)
Pending mail: 0 Dead mail: 0
Task Description
Database Server Server for Pavel A. Puchkov/InterTrustCorp/SU on SPX
Database Server Perform console commands
Database Server Listen for connect requests on TCPIP
Database Server Listen for connect requests on LAN0
Database Server NetBIOS name server for LAN0
Database Server Listen for connect requests on LAN4
Database Server NetBIOS name server for LAN4
Database Server Listen for connect requests on SPX
Database Server Idle task
Database Server Server for Nikolay N. Iontsev/InterTrustCorp/SU on SPX
Database Server Server for Vladimir A. Panov/InterTrustCorp/SU on SPX
Database Server Server for InterTrust/InterTrustCorp/SU on LAN0
Object Store Manager Linking mail\asavelye.nsf to object store mail\shared.nsf
Admin Process Idle
Agent Manager Executive '1': Idle
Agent Manager Idle
Stats Idle
Indexer Idle
Router Idle
Replicator Idle
03.09.96 12:18:03 Object Store Manager: 48 of 50 notes processed
03.09.96 12:18:04 Object Store Manager: Begin compacting mail\asavelye.nsf
03.09.96 12:18:31 Opened session for InterTrust/InterTrustCorp/SU (Build 138)
03.09.96 12:18:31 Object Store Manager: Finished compacting mail\asavelye.nsf
03.09.96 12:18:31 Object Store Manager: Process shutdown
Чтобы сохранить в СПЯ все тела сообщений из ПЯ и тела сообщений, которые уже сохранены в различных других СПЯ, используют команду:
Load Object Link -Relink USERMAIL.NSF SHARED.NSF ,
где USERMAIL.NSF - имя ПЯ или каталог, содержащий ПЯ, а SHARED.NSF - имя СПЯ.
Опция -Relink означает, что все тела сообщений, как из ПЯ, так и присоединенные к другим СПЯ, будут присоединены к указанному в команде СПЯ. Эта опция полезна, когда у вас на сервере несколько СПЯ, и вы хотите "пере-присоединить" сообщения пользователя к новому СПЯ.
В следующем примере сообщения из ПЯ mail\niontsev.nsf "пере-присоединяются" к СПЯ mail\shared.nsf:
> load object link -Relink mail\niontsev.nsf mail\shared.nsf
15.08.96 15:12:57 Object Store Manager: Process started
15.08.96 15:12:58 Object Store Manager: Linking mail\niontsev.nsf to object store mail\shared.nsf
15.08.96 15:14:30 Object Store Manager: 431 of 431 notes processed
15.08.96 15:14:30 Object Store Manager: Begin compacting mail\niontsev.nsf
15.08.96 15:15:31 Object Store Manager: Error compacting mail\niontsev.nsf: File is in use by another program
15.08.96 15:15:31 Object Store Manager: Process shutdown
Продолжение процесса установления
Процесс установления подлинности (процедура аутентификации) не заканчивается рассмотренным выше. После того, как доверие публичному ключу клиента было установлено, выполняются следующие три шага.· Проверка, "знает ли" клиент свой личный ключ:
· сервер генерирует случайное число и посылает его клиенту
· клиент шифрует это число своим личным ключом и возвращает полученный код серверу
· сервер использует публичный ключ клиента для декодирования присланного клиентом кода. Если только декодированное число совпадает с оригиналом, сервер предполагает, что клиент подлинный.
· Установление клиентом доверия публичному ключу сервера. Этот процесс "зеркально аналогичен" рассмотренному выше процессу установления сервером доверия публичному ключу клиента. В случае использования взаимных сертификатов этот процесс может завершиться успешно только тогда, когда в локальной адресной книге клиента имеется взаимный сертификат, выпущенный клиентом или одним из предков клиента для сервера или одного из предков сервера.
· Проверка, клиентом, "знает ли" сервер свой личный ключ. Она "зеркально" повторяет процесс проверки сервером факта знания клиентом своего личного ключа.
Program - программа, запускаемая на сервере по расписанию
Документы формы Program содержат сведения о программах, выполняемых на сервере по расписанию. Документ этой формы уже рассматривался в 3.3.1.В приведенном ниже примере "разрешается" ежедневный однократный запуск в 9 часов вечера на сервере NotesSRV400/InterTrustCorp/SU командного файла UUPC.cmd. Его исполняет интерпретатор CMD.exe, "запускаемый" сервером с параметром /K ""UUPC.cmd"" (платформа OS/2).
Рис. 4.16 Пример документа Program для выполнения CMD-файла на сервере под OS/2
Производительность серверов Notes по платформам и протоколам
Следующая таблица содержит принципиальные ограничения на количество одновременно работающих с сервером пользователей в зависимости от операционной системы, под которой работает сервер, и протокола, используемого пользователем для доступа к серверу.Учтите, что поскольку сервер автоматически закрывает сессии пользователей, если они не проявляют никакой активности в течении некоторого времени, и автоматически восстанавливает их сессии при очередном проявлении активности, цифры в таблице задают именно максимальное количество одновременных активных сессий. Продолжительность интервала неактивности задается переменной Server_Session_Timeout=<количество минут> в файле NOTES.INI.
| OS/Protocol | TCP/IP | IPX/ SPX | NetBIOS | VINES® | Apple Talk | X.PC | X.25 | ||||||||
| OS/2 | ОТПК | ОТПК | 100 | 50. Более 50 с Banyan VINES patch 5.54(20) | 50 | 64 порта | 64 | ||||||||
| Windows NT (Intel, Digital Alpha) | ОТПК | ОТПК | 252 | ОТПК для Intel, НП для Digital Alpha | 255 | 64 порта | 64 | ||||||||
| Solaris® (SPARC®) | ОТПК | ОТПК | НП | НП | НП | 64 порта | НП | ||||||||
| HP-UX | ОТПК | ОТПК | НП | НП | НП | 64 порта | НП | ||||||||
| AIX® | ОТПК | ОТПК | НП | НП | НП | 64 порта | НП | ||||||||
| NLM | ОТПК | ОТПК | НП | НП | 120 | 64 порта | НП | ||||||||
| Windows® 95 | ОТПК | ОТПК | ОТПК | НП | НП | 64 порта | НП | ||||||||
| Solaris X86 | ОТПК | ОТПК | НП | НП | НП | 64 порта | НП |
· ОТПК - Ограничивается Только Производительностью Компьютера, на котором установлен сервер Notes. Прежде всего зависит от количества оперативной памяти и типа и количества процессоров. Более конкретные сведения - результаты тестирования компьютеров с использованием продукта NotesBench - доступны в базе знаний по Notes "Lotus Notes Knowledge Base".
· НП - протокол Не Поддерживается.
Просмотр статистики СПЯ на консоли сервера
Чтобы сгенерировать статистику о любом СПЯ "по требованию", используют командуLoad Object Info -Full SHARED.NSF ,
где SHARED.NSF - имя СПЯ. Чтобы генерировать статистику для активного СПЯ, можно указать или точное имя файла активного СПЯ, или MAILOBJ.NSF - указатель на файл СПЯ, который является активным.
Чтобы получить статистику о СПЯ на консоли, используют команду Show Stat Object .
> load object info -full mail\shared.nsf
20.08.96 16:12:20 Object Store Manager: Process started
20.08.96 16:12:20 Object Store Manager: mail\shared.nsf is an object store
20.08.96 16:12:31 Object Store Manager: 650 of 650 notes processed
20.08.96 16:12:31 Object Store Manager: Process shutdown
> show stat object
Object.FileName = mail\shared.nsf
Object.mail\shared.nsf.SharedBy.01 = 579
Object.mail\shared.nsf.SharedBy.02 = 51
Object.mail\shared.nsf.SharedBy.03 = 18
Object.mail\shared.nsf.SharedBy.04 = 0
Object.mail\shared.nsf.SharedBy.05 = 1
Object.mail\shared.nsf.SharedBy.06 = 1
Object.mail\shared.nsf.SharedBy.07 = 0
Object.mail\shared.nsf.SharedBy.08 = 0
Object.mail\shared.nsf.SharedBy.09 = 0
Object.mail\shared.nsf.SharedBy.10 = 0
Object.mail\shared.nsf.SharedBy.11 = 0
Object.mail\shared.nsf.SharedBy.12 = 0
Object.mail\shared.nsf.SharedBy.13 = 0
Object.mail\shared.nsf.SharedBy.14 = 0
Object.mail\shared.nsf.SharedBy.15 = 0
Object.mail\shared.nsf.SharedBy.16 = 0
Object.mail\shared.nsf.SharedBy.17 = 0
Object.mail\shared.nsf.SharedBy.18 = 0
Object.mail\shared.nsf.SharedBy.19 = 0
Object.mail\shared.nsf.SharedBy.20 = 0
Object.mail\shared.nsf.SharedBy.Greater = 0
Object.mail\shared.nsf.SharedBy.Total = 650
· Object.mailobj.nsf.SharedBy.x
дает количество сообщений в СПЯ, которые являются общими ровно для х ПЯ, где x может иметь значение от 1 до 20. Например, если Object.mailobj.nsf.SharedBy.3 = 5, то СПЯ MAILOBJ.NSF содержит 5 сообщений, которые являются общими для 3-х ПЯ.
· Object.mailobj.nsf.SharedBy.Greater
представляет число сообщений в MAILOBJ.NSF, являющихся общими больше чем в 20 ПЯ.
· Object.mailobj.nsf.SharedBy.Total
дает общее количество сообщений, сохраненных в MAILOBJ.NSF - оно равно сумме вышеупомянутой статистики.
Когда выполняется функция Collect, она автоматически генерирует статистику для активного СПЯ. Если на сервере выполняется задача Report, можно воспользоваться видом Single Copy Object Store Statistics в базе статистики (STATREP.NSF). Этот вид отображает статистику активного СПЯ в каждом интервале сбора статистики. Каждый документ-отчет показывает количество тел сообщений, совместно используемых данным количеством получателей (от 1 до 20);
количество сообщений, общедоступных больше чем 20 получателями, и общее количество совместно используемых тел сообщений.
Работа с сервером по протоколу X.PC
Первые спецификации протокола X.PC были выпущены в сентябре 1983 года компанией Tymshare (Cupertino, Калифорния). Немногим позже компанией Tymnet был разработан протокол X.PC с обнаружением и коррекцией ошибок. Этот общедоступный (public domain) протокол был использован фирмой Lotus при создании драйвера COM-порта, названного XPC, который вошел в состав с Notes еще с версии 2.0 и стал стандартным средством Notes для работы по коммутируемым последовательным линиям связи.В общем виде модель коммутируемой последовательной линии связи, используемая драйвером XPC, приведена на Рис. 5.1.
Рис. 5.1 Модель линии связи, используемая драйвером XPC
Между COM-портом вызывающей станции (сервера) и ее модемом может находиться Управляемое Устройство 1 (УУ1). Если УУ1 действительно имеется, "диалог" между вызывающим компьютером и УУ1 задается скриптом "приобретения" (Acquire), а имя скрипта указывается в настройках порта Notes. Обычное назначение этого скрипта - получить в монопольное владение ("приобрести") модем из модемного пула на коммуникационном сервере. Если же УУ1 отсутствует, то модем подключен непосредственно к COM-порту компьютера, а в настройках порта Notes никакой скрипт "приобретения" не выбран.
Драйвер XPC, "управляя" подключенным к вызывающему компьютеру модемом, использует специфическую для используемого модема информацию из файла управления модемом, а имя файла указывается в настройках порта Notes. Возможен также вариант, когда модемы отсутствуют, а COM-порт вызывающего компьютера соединен нуль-модемным кабелем с COM-портом вызываемого сервера
или Управляемым Устройством 2 (УУ2). В этом варианте в настройках порта Notes задают специальный файл управления (.Null modem).
Диалог между вызывающим компьютером и устройством УУ2, если последнее имеется, задается скриптом соединения (Connect). Скрипт соединения может иметь до четырех параметров. Имя используемого скрипта соединения и передаваемые ему параметры указываются в документе Connection из локальной адресной книги вызывающего компьютера (станции или сервера). Наиболее часто в качестве УУ2 выступает асинхронный ассемблер/дизассемблер пакетов (PAD), расположенный на узле провайдера Х.25. Своей "вторым стороной" PAD подключен к сети Х.25. В этом случае в вызываемом сервере должна быть установлена специальная карта X.25, также подключенная сети Х.25. Если же УУ2 отсутствует, то "принимающий вызов" модем подключен непосредственно к COM-порту вызываемого сервера, а в настройках порта Notes вызывающего компьютера никакой скрипт соединения не выбирается.
В общем случае вызывающий компьютер (станция или сервер) сначала выполняет скрипт "приобретения", затем, после успешного завершения скрипта "приобретения", устанавливает соединение с вызываемым модемом, используя при этом файл управления модемом, после чего выполняет скрипт соединения. Только после успешного завершения скрипта соединения начинается собственно работа по установленному соединению.
Файлы скриптов и файлы управления модемами представляют собой текстовые файлы и находятся в каталоге NOTES\DATA\MODEMS станции или сервера. Файлы скриптов имеют расширение *.SCR, файлы управления модемами - расширение *.MDM. Все возможные выборы скриптов "приобретения" и файлов управления модемами в диалоговом окне при настройке COM-порта, а также выборы скриптов соединения в документах Connection определяются наличием в этом каталоге соответствующих файлов.
Randomized exponential backoff algoritm
Вы составили прекрасное расписание. Однако не всегда удается установить соединение точно в запланированные моменты времени...Если сервер должен выполнять репликацию, но ему не удается установить соединение с вызываемым сервером, то:
· Если в документе Connection был задан диапазон (отрезок времени с интервалом повторения), сервер будет повторять попытки установления связи на основе "exponential backoff algorithm": сервер повторяет попытку установления связи через 10 минут после первой попытки, 20 минут после первой попытки, 40 минут после первой попытки, и т.д. Учтите, что здесь приведены средние значения. Слово randomized из названия алгоритма предупреждает вас, что в действительности сервер добавляет к средним значениям случайные поправки, чтобы избежать совпадения по времени встречных вызовов. Например, если начальная попытка была в 1:00pm, последующие попытки будут сделаны в 1:10+s pm, 1:20+s pm, 1:40+s pm, где s - случайное число. Если время очередной из попыток по "exponential backoff algorithm" превышает время начальной попытки плюс интервал повторения (из документа Connection), очередная попытка установления связи происходит в момент времени, равный времени начальной попытки плюс интервал повторения (в нашем примере, если интервал повторения равен 60 минут, сервер повторно вызывает в 2:00pm, и повторяет в 2:10+s pm, 2:20+s pm, 2:40+s pm, а затем снова в 3:00pm). Только в случае, если предыдущий вызов был успешен, интервал повторения определяет, через сколько минут после завершения последней репликации будет происходить следующий вызов. Если вы задали в документе интервал повторения "пустым", сервер принимает интервал повторения равным 60 минут
· Если в документе Connection задан не диапазон, а конкретное время типа 08:00am, или даже список конкретных времен, сервер повторяет вызовы в течение часа. В соответствии с Randomized exponential backoff algoritm за это время произойдет около 4 попыток соединения. Но независимо ни от чего попытка следующей репликации будет происходить в следующее намеченное время в списке. Это означает, что если вы наметили репликации на 8:00 и 9:00, даже если репликация, назначенная на 8:00, заканчивается в 8:37, очередная репликация будет начинаться в 9:00, а не будет отсрочена до 9:37.
Иногда запланированные репликационные события подавляются сервером. Это может случаться, если подобное репликационное событие произошло совсем недавно (в течение часа) или если подобный запрос на репликацию все еще находится в очереди. В выборе репликатора между новыми запланированными и уже имеющимися в его очереди запросами на репликацию новые запланированные запросы имеют более высокий "приоритет". Это напоминает стратегию "заваленного" работой исполнителя, который при завершении очередного задания переключается на вновь полученное задание в ущерб уже имеющимся в его очереди заданиям. Такой принцип гарантирует завершение всех запланированных запросов до обслуживания "ждущих" запросов из очереди. Если запрос внесен в очередь, но связь с нужным сервером прервалась, происходит или повторное соединение (при работе по локальной сети) или снятие запроса (при работе по соединению типа Dialup Modem или X.25).
Обратите также внимание, что когда репликатор установил с сервером соединение типа Dialup Modem или X.25, этот факт становится известен Router-у (серверной задаче, отвечающей за передачу почты) вызванного сервера. Если Router вызванного сервера имеет ожидающую отправки на вызывавший сервер почту, эта почта будет передана в течение репликационной сессии. Обратное силы не имеет - выполнение репликаций осуществляется только по расписанию.
Расписание доставки почты
Соединения серверов для доставки почты задаются набором документов Connection в адресной книге.· Документ Connection требуется только для соединения с серверами в разных поименованных сетях Notes внутри домена и соединения с серверами из других доменов; он не требуется для доставки почты в той же самой поименованной сети того же самого домена.
· Обычно документы Connection должны присутствовать на обеих сторонах соединения, чтобы имелась возможность инициализации связи каждым из серверов.
· Для сокращения количества документов Connection рекомендуется между двумя поименованными сетями Notes делать только пару документов - между одним сервером в одной сети и одним сервером в другой, а не между каждым сервером из одной и каждым сервером из другой.
· Фактический вызов согласно документу Connection осуществляется только при наличии почты на указанный в документе сервер назначения, поэтому можно не беспокоиться относительно "холостых звонков". По этой же причине рекомендуется задавать в документе Connection временной диапазон с коротким интервалом повторения.
· Расписание из документа Connection не принимается во внимание в случаях, когда достигнут порог "Route at once if..." ("Рассылать немедленно при..."), ожидает отправки почта высокого приоритета, или с консоли сервера введена команда Route <сервер назначения>.
· Соглашение о приоритетах следующее: High - отправка немедленно; Medium - отправка по расписанию или порогу; Low - использует соединения между 12:00 часами ночи и 6:00 утра (или как то указано в файле NOTES.INI в переменной MailLowPriorityTime).
· Приоритеты "соблюдаются" только для почты, передаваемой "согласно документа Connection" - почта в пределах поименованной сети Notes доставляется сразу, а приоритеты игнорируются.
Администратор составляет расписание передачи почты, руководствуясь следующими принципами.
· Необходимо учитывать существующее расписание репликаций, поскольку передача почты обычно сопровождает репликации. Не следует нужно создавать дополнительных документов Connection, если можно ограничиться существующими. Например, два вызова в день и для репликаций, и для передачи почты: утром и после полудня.
· Следует планировать вызовы для передачи почты среднего и низкого приоритета на время наименьшей загрузки сети. Например, до начала или после окончания рабочего дня в организации.
· По возможности следует стремиться ограничивать количество серверов, в одно и то же время вызываемых одним сервером, чтобы избежать перегрузки сервера большим количеством задач или подпроцессов. Производительность сервера может резко падать, когда этот сервер пытается выполнять излишне большое количество вызовов. Типичный признак перегрузки сервера - вызовы выполняются, но почта "не проходит". Поэтому рекомендуется "сдвигать по времени" диапазоны вызовов, например, вызов первого сервера для передачи почты с 8:00 до 10:00, второго сервера с 8:05 до 10:05, и так далее. Целесообразно также ограничивать возможность вызова одного и того же сервера только через один порт.
Передача почты, когда только один сервер может выполнять вызов другого
Иногда требуется, чтобы почта могла передаваться в обе стороны между серверами, но в условиях, что только один из серверов может выполнять вызов другого. Обычно эти условия определяется финансовыми соображениями, но могут быть и чисто технические причины. Например, если сервер B оснащен картой X.25, а сервер A лишь модемом, то сервер A
может вызывать сервер B через асинхронный PAD, тогда как сервер B не может вызывать сервер A.
Когда один сервер Notes соединяется с другим сервером по документу Connection типа Dialup Modem или X.25, задача Router вызываемого сервера получает об этом событии "уведомляющее сообщение" от программного обеспечения сетевого уровня. Если на вызванном сервере имеется ожидающая отправки на вызванный сервер почта, эта почта передается Router-ом вызванного сервера в MAIL.BOX на вызвавшем сервере по уже установленному соединению. Если входящий вызов "приходится" на диапазон времени для доставки почты низкого приоритета, "обратно" отправляется почта всех приоритетов. Если же вызов осуществлен во время вне диапазона для доставки почты низкого приоритета, "обратно" отправляется только почта высокого и среднего приоритетов.
Рассмотрим подробнее, как решить эту проблему.
Предположим, сервер A может вызывать сервер B, а сервер B не может вызывать сервер A.
Чтобы почта, предназначенная серверу A, "скапливалась" в MAIL.BOX на сервере B, приходится создать "макетный" документ Connection с сервера B на сервер A, указав в нем "неправильную" информацию, чтобы сервер B в самом деле не мог установить это соединение. В этом "макетном" документе Connection
нужно указать недопустимый телефонный номер, "разрешить" использование по расписанию, а в расписании выбрать вызов только один раз в день и всего один день в неделю. Кроме того, во избежание "бессмысленных" вызовов следует также позаботиться о том, чтобы пользователи либо не отправляли сообщений высокого приоритета, либо попросту не могли этого сделать.
Когда же сервер A установит соединение с сервером B, Router на сервере B воспользуется уже установленным соединением, чтобы передать "ожидающую" в своем MAIL.BOX на сервер A. Необходимо, чтобы сервер A вызывал сервер B хотя бы раз в сутки, чтобы "накопившаяся" на сервере B почта не возвращалась с уведомлением о недоставке. Более правильно планировать по крайней мере один вызов вне диапазона времени для доставки почты низкого приоритета и один вызов в диапазоне для доставки почты низкого приоритета. Если с сервера A на сервер B имеется "регулярный поток" почты, на сервере A можно обойтись документом Connection
только для передачи почты. Если регулярного потока почты нет, следует сделать по крайней мере один документ Connection для репликаций (чтобы обеспечить регулярность вызова) и передачи почты.
Различные варианты конфигурирования SMTP MTA
На Рис. 7.21 приведена самая распространенная конфигурация - в одном глобальном домене один домен Notes, а SMTP MTA может отправлять почту на любой хост в Internet. Конфигурация описывается четырьмя документами (см. Рис. 7.14), причем в документе Server Connection типа SMTP поле Optional network address: пусто.
Рис. 7.21 В одном глобальном домене один домен Notes
Конфигурация на Рис. 7.22 отличается от предыдущей только тем, что все серверы Notes находятся в закрытой внутрикорпоративной сети и не имеют прямого доступа к Internet. Обмен почтой с Internet здесь возможен только через корпоративный почтовый сервер, который доступен как из внутрикорпоративной сети, так и из Internet. На почтовом сервере функционирует Relay MTA - промежуточный агент передачи SMTP-почты (не Notes-архитектуры). Установленный на сервере Notes SMTP MTA может отправлять почту только на этот почтовый сервер, поэтому в документе Server Connection типа SMTP в поле Optional network address: должен быть указан IP-адрес сервера с Relay MTA. Сервер DNS у провайдера услуг Internet должен содержать запись MX, "адресующую" входящую почту на почтовый сервер с Relay MTA, и записи A как для сервера с Relay MTA, так и для сервера Notes с установленным SMTP MTA.
Рис. 7.22 Транспорт почты через промежуточный агент
В конфигурации на Рис. 7.23 в один глобальный домен входят несколько доменов Notes. Установленный только на одном из серверов Notes из домена Dom2 SMTP MTA может отправлять почту на любой хост в Internet. Конфигурация по прежнему описывается только четырьмя документами (см. Рис. 7.14) в адресной книге домена Dom2. В документе Server Connection типа SMTP
поле Optional network address: пусто. В документе Global Domain в поле-списке Notes domains and aliases: присутствуют все три домена Notes. Для простоты SMTP-адрес пользователя Notes формируется с включением имени домена Notes. Пользователь из домена Dom1 или Dom3, отправляя сообщение в Internet, задает адрес получателя наподобие intuser@acme.com@Dom2, где Dom2
- имя домена Notes с установленным SMTP MTA, а intuser@acme.com - собственно адрес получателя в Internet. В обратную сторону ( из Internet) сообщение пользователю Notes отправляется по адресу наподобие notuser%Dom2@omega.com, где omega.com
- имя домена Internet, к которому принадлежит принимающий сообщение SMTP MTA, Dom2
- имя домена Notes, а notuser
- имя пользователя Notes.
Конфигурация на Рис. 7.24 характерна для территориально-распределенных доменов Notes, поскольку по финансовым соображениям каждой "территориальной единице" удобнее пользоваться услугами "ближайшего к ней" провайдера услуг Internet. Конфигурация может описываться так. Документ Foreign SMTP Domain только один и дает "общее" для всех MTA имя домена SMTPMAIL. Документов Server Connection типа SMTP, естественно, три. Сообщение, отправляемое в Internet, доставляется почтовой системой Notes от сервера отправителя до сервера с SMTP MTA
маршрутом "наименьшей стоимости". Документов Global Domain три, а документ Server "каждого" MTA
привязан к своему глобальному домену. При этом все 10 документов находятся в одной адресной книге домена Notes.
Рис. 7.23 В одном глобальном домене несколько доменов Notes
Рис. 7.24 В одном домене Notes несколько глобальных доменов
Регистрация пользователей
Прежде, чем устанавливать станции, администратор должен зарегистрировать новых пользователей. Для этого администратор со своей станции нажимает в окне Administration кнопку People, выбирает меню кнопки пункт Register Person... и получает одно за другим два диалоговых окна.
Рис. 2.28 Первое диалоговое окно при регистрации пользователя
Рассмотрим первое диалоговое окно. Кнопка Registration Server... используется для выбора сервера, в адресной книге которого будет создаваться документ Person с информацией о пользователе. Кнопка Certifer ID... используется для выбора ID-файла сертификатора, которым будет сертифицироваться создаваемый ID пользователя. Появившаяся с версии 4.5 опция Add NT User Account(s) в случае, если регистрационный сервер Notes установлен на сервере Windows NT, являющемся контроллером домена Windows NT, обеспечит также регистрацию этого пользователя Notes как пользователя NT.
Перейдем к рассмотрению трех закладок второго диалогового окна.
В полях с метками First name:, MI: и LastName: вводят соответственно имя, букву отчества (можно с точкой) и фамилию регистрируемого пользователя. В версиях Notes ниже 4.11a не рекомендуется использовать в именах пользователей русские буквы. В поле с меткой Password: задается пароль для создаваемого ID-файла, в раскрывающемся списке License Type: - тип лицензии. Формально тип лицензии должен выбираться в соответствии с типом купленной лицензии, на практике обычно выбирают Lotus Notes, что обеспечивает полную функциональность клиента, или реже Lotus Notes DeskTop, что лишает пользователя
Рис. 2.29 Второе диалоговое окно при регистрации пользователя, закладка Basics
возможности изменять дизайн баз или разрабатывать новые базы. Раскрывающийся список с меткой Profile:
обсуждается в 2.2.5.
Рис. 2.30 Второе диалоговое окно при регистрации пользователя, закладка Mail
В раскрывающемся списке с меткой Mail type: выбирают тип почтовой службы - Lotus Notes. Если необходимо, в поле с меткой Mail file name: изменяют имя файла почтового ящика пользователя. Выбирают, когда должен быть создан почтовый ящик: Create files now - при регистрации, или Create files during setup - позже, при установке станции клиента. Раскрывающийся список Home server:
позволяет выбрать сервер, к которому пользователь будет подключаться в начале его работы и на котором создается база данных "Почтовый ящик пользователя" (ПЯ). В дальнейшем администратор может переместить почтовый ящик пользователя на другой сервер, а пользователь может изменить имя своего Home/mail
server в документе Location из персональной адресной книги.
Закладка Other
позволяет указать, куда следует поместить создаваемый ID-файл пользователя: в адресную книгу регистрационного сервера и (или) в файл (в группе Store User ID: селективные кнопки In Address Book и In file: и кнопка Set ID file...).
Рис. 2.31 Второе диалоговое окно при регистрации пользователя, закладка Other
Поле с меткой User unique organizational unit: позволяет добавить еще один дополнительный уровень к имени пользователя. Это может понадобиться, чтобы обеспечить уникальные имена для двух пользователей, имеющих одинаковое имя (CN) и сертифицированных одним и тем же сертификатором. Поскольку в этом поле в версиях 4.х "запрещен" символ "/", по сути, это поле позволяет добавить к имени пользователя только один дополнительный уровень, но не "подтверждаемый" сертификатором.
Кнопки Next, Previous и Delete служат для того, чтобы сначала ввести в окнах информацию о нескольких регистрируемых пользователях, а затем кнопкой Register сразу зарегистрировать их всех.
Кроме того, имеется возможность зарегистрировать сразу много пользователей, предварительно подготовив информацию о них в специальном формате в текстовом файле и выбрав в меню кнопки People в окне Administration
пункт Register from File...
Подробности о формате этого файла смотрите в базе данных Notes Administration Help.
Обратим внимание на документ Person, создаваемый в общей адресной книге в процессе регистрации пользователя.
Рис. 2.32 Фрагмент документа Person из общей адресной книги
Не рекомендуем изменять в этом документе информацию в полях с метками First name:, Middle initial: и Last name:. В конец поля-списка User name: можно добавить новые элементы - дополнительные имена пользователя. Тогда пользователь сможет получать почту, адресованную ему по любому из этих имен. Поля с метками Domain:, Mail server: и Mail file: содержат информацию о местоположении почтового ящика пользователя. Информацию в этих полях можно и нужно изменять в ситуациях типа перемещения почтового ящика с одного сервера на другой. Если поле с меткой Forwarding address: пусто, почтовая система Notes доставляет письма для пользователя в его почтовый ящик. Однако в этом поле можно задать иной почтовый адрес получателя. Тогда почтовая система Notes "автоматически переадресует" приходящие в адрес пользователя письма по указанному в поле с меткой Forwarding address: адресу. Это может быть как адрес в почтовой системе Notes, так и в других почтовых системах (SMTP, X.400...). В последнем случае почтовая система Notes должна включать агенты передачи почты (MTA) в соответствующие почтовые системы.
Регистрация сервера Notes на платформе Windows NT как сервиса
Регистрация сервера Notes версий от 4.5 как сервиса Windows NT автоматически происходит при установке сервера, если данная возможность была выбрана.Для регистрации сервера Notes версии ниже 4.5 как сервиса Windows NT необходимо в каталоге программ Notes выполнить программу ntsvinst.exe с параметром -c - ntsvinst -c. После этого сервер Notes "появляется" в списке сервисов Windows NT, получаемых из Control Panel "запуском пиктограммы" Services. Остается только кнопкой Startup выбрать нужный вариант его запуска.
Рис. 2.16 Сервер Notes версии 4.11а в окне сервисов Windows NT 3.51
Для "де-регистрации" та же программа запускается с параметром -d.
Кроме того, в каталоге программ Notes имеется файл notesreg.bat. Этот файл выполняет добавление в приложение Rerformance Monitor объект Lotus Notes, позволяющий отображать изменения параметров функционирования сервера Notes во времени. Учтите, что файл notesreg.bat работает с Windows NT "не ниже" 3.51 Service Pack 4. В файле notesreg.bat используются программы regini.exe (из Windows NT 3.51 Resource Kit) и lodctr.exe. Файл следует запускать из каталога программ Notes, обязательно указав ему параметр - полный путь на каталог программ Notes.
Рис. 2.17 Performance Monitor "отображает" изменения параметров сервера Notes
Репликации между сервером и станцией Notes
На станции нет явного аналога серверной задачи Replicator. Программное обеспечение станции при репликации сначала принимает изменения с сервера, а затем отправляет измененные документы на сервер (аналог схемы Pull-Push). Репликация между станцией и сервером для конкретной базы может быть инициирована со станции вручную выбором File - Replication - Replicate в основном меню или Replicate во всплывающем меню базы. Однако значительно более удобно пользоваться мощными возможностями закладки Replicator.Возможны и фоновые репликации по расписанию. Расписание фоновых репликаций определяется в документах Location из персональной адресной книги.
Репликации
Будем использовать термин "распределенная база данных Notes" для обозначения совокупности расположенных на разных серверах Notes реплик одной и той же базы.При этом термин "реплика базы":
· означает, что существует по крайней мере еще одна база, имеющая тот же самый идентификатор реплики (Replica ID), что и данная.
Рис. 6.1 Пиктограммы реплик адресной книги "стекированы" - расположены одна за другой
"Увидеть" идентификатор реплики можно на панели свойств базы.
Рис. 6.2 Эта база имеет идентификатор реплики C3256274:007061676
Идентификатор реплики (Replica ID) - уникальный идентификатор, позволяющий отличать реплики базы данных на различных серверах и станциях от обычных копий. Различные реплики одной и той же базы на различных серверах и станциях могут иметь разные названия и имена файлов, но у них одинаковый идентификатор реплики. Копия же базы, выполненная средствами Notes, гарантированно будет иметь другой идентификатор реплики, чем оригинал. Однако копия базы, выполненная средствами операционной системы, будет иметь тот же идентификатор реплики, что и оригинал
· предполагает, что за собственно созданием реплики последуют настроенные администратором и выполняемые автоматически по расписанию или по явному указанию администратора сервера или пользователя станции процессы репликации - обмена изменениями между репликами
· не означает, что содержание двух или более реплик базы будет совершенно одинаковым. Вообще говоря, это не так и во времени, и по наличию содержащихся в репликах документов.
Суть процесса репликации состоит в следующем. Реплики одной и той же распределенной базы находятся на разных серверах. Пользователи, имеющие доступ к репликам, изменяют их содержимое (изменяют документы, создают новые документы, удаляют существующие документы) параллельно и независимо друг от друга. В результате содержимое реплик становится неодинаковым. В определенное расписанием время на одном из серверов серверная задача Replicator ("репликатор") вызывает другой сервер. Если соединение состоялось, репликатор в первую очередь составляет списки баз, реплики которых присутствуют на обоих серверах.
Далее репликатор для каждой реплики сравнивает списки документов. Новые, модифицированные или удаленные в реплике на вызванном сервере документы принимаются в реплику на вызывавшем сервере. Затем, если осуществляется репликация по схеме Pull-Pull, репликатор вызывавшего сервера инициирует репликатор на вызванном сервере. Последний в свою очередь принимает в свою реплику новые, модифицированные или удаленные документы из реплики на сервере, инициировавшем процесс. Кроме того, в репликациях могут участвовать элементы дизайна и список управления доступом базы. По завершении этого процесса содержимое всех реплик баз на обоих серверах приходит в некоторое "установившееся" состояние. Однако это "установившееся" состояние, вообще говоря, не означает, что содержимое обеих реплик станет совершенно одинаковым. В частности, "неодинаковость" может создаваться за счет разных прав доступа серверов к репликам на других серверах или запланированного использования специальных формул, описывающих множество реплицируемых документов (селективные репликации).
Репликационные конфликты
Когда репликатор обнаруживает конфликт, он выбирает версию документа, имеющую более позднее время модификации, и сохраняет в "своей" реплике в качестве главного документа. Другая версия этого документа тоже сохраняется в "своей" реплике, но в качестве ответного документа (response) на главный. В ответный документ также добавляется поле с именем $Conflict и пустым значением. Ответные документы, имеющие поле $Conflict, "отмечаются" ромбиком на левом поле вида и сопровождаются пояснением [Replication or Save Conflict].
Рис. 6.22 Пример конфликтных документов в виде: "How to Migrate..." - конфликтный главный документ, ромбиком же отмечен конфликтный ответный документ.
Для разрешения возникших конфликтов в общем случае потребуется вмешательство лиц, вносивших изменения в документы, поскольку необходимо осмысление имеющихся изменений.
Технически же дело обстоит так. Если нет необходимости оставлять в базе конфликтный ответный документ, его попросту удаляют. Если нет необходимости оставлять конфликтный главный документ, нужно сначала открыть в режиме редактирования конфликтный ответный документ и заново сохранить его, а только потом удалять главный документ. Дело в том, что при "пересохранении" конфликтного ответного документа из него автоматически удаляются поля $Conflict и $Ref. Если же сразу удалить конфликтный главный документ, то конфликтный ответный окажется "документом без родителя" (его поле $Ref содержит универсальный идентификатор уже не существующего главного документа), и в результате перестанет отображаться в виде, поддерживающем иерархию ответных документов. Наконец, если должны остаться оба конфликтных документа, достаточно "пересохранить" конфликтный ответный документ.
Если в процессе эксплуатации базы наблюдается "усиленная" тенденция к образованию конфликтов, скорее всего, наступило время задуматься об изменении дизайна базы. Для "борьбы" с конфликтами имеется ряд приемов, среди наиболее простых из которых можно отметить имеющиеся в окне свойств формы опции Versioning - управление версиями документа и Merge replication conflicts - автоматическое слияние конфликтных документов, если разные пользователи изменяли в них разные поля.
Репликационные установки для базы данных
Репликационные установки для базы данных задаются в диалоговом окне, получаемом выбором в меню File - Replication - Settings (или множеством других способов). Чтобы изменять репликационные установки, вы должны иметь доступ менеджера к базе. Только для изменения формул селективной репликации вам достаточно доступа дизайнера.
Рис. 6.10 Закладка окна репликационных установок, отвечающая за "сохранение дискового пространства"
· Remove documents not modified in the last: XXX days. Установка опции "заставляет" автоматически удалять из данной базы все документы с датой сохранения или модификации более ранней, чем XXX дней назад от текущей даты. Документы, удаленные из данной реплики базы на основании этой установки, будут удалены в других репликах распределенной базы, если только вы не выбрали на закладке Send дополнительно опцию Do not send deletions made in this replica to other replicas. Если опция Remove documents not modified… не выбрана, "автоудаление" документов не выполняется, невзирая на значение XXX. Имеются нюансы, связанные с моментами выполнения "автоудаления". В частности, для баз на сервере условие "автоудаления" проверяется запускаемой ночью серверной задачей UPDALL, а на станции для локальных баз - в момент открытия базы.
Значение XXX из Remove documents not modified in the last: XXX days также определяет интервал запуска процесса удаления "окурков". Фактическое удаление "окурков" выполняется с периодом, равным 1/3 интервала удаления XXX. Так, если интервал удаления равен 30 дней, то тогда каждые 10 дней выполняется удаление всех "окурков", возраст которых более 30 дней.
· Replicate a subset of documents:. Опция используется, если в данную реплику должны поступать не все документы, а только документы или из некоторых видов и папок, или удовлетворяющие заданной вами формуле отбора документов (если дополнительно выбрана опция Select by formula). Подробнее эти и другие опции, относящиеся к вопросу селективных репликаций, рассматривается в 6.2.12.
Рис. 6.11 Закладка окна репликационных установок, отвечающая за отправку документов из этой реплики в другие реплики
· Do not send deletions made in this replica to other replicas. Выбор опции означает, что при репликации этой базы в ее другие реплики не должна передаваться информация об удаленных документах (т.е. "окурки"). В результате удаленные в этой реплике документы при репликации не вызовут удаления соответствующих документов в других репликах. Невозможно "описать множество" уже удаленных документов ("множество окурков") с помощью формулы отбора. "Окурки" можно только не реплицировать в другие реплики, и это достигается выбором данной опции. Если же опция не выбрана, то появляющиеся после удаления документов в этой базе "окурки" при репликациях попадают в другие реплики этой базы и вызывают в них удаления соответствующих документов.
· Do not send changes in database title & catalog info to other replicas. Опция требует не изменять название базы и информацию о том, следует ли создавать документ об этой базе в базе CATALOG.NSF, в других репликах, если они изменились в данной. Если опция не выбрана, то самые последние изменения должны замещать более старые значения во всех репликах. Однако для этого дополнительно необходимо, чтобы сервер данной реплики имел в репликах на других серверах доступ дизайнера или выше.
· Do not send changes in local sequrity prorepry to other replicas. Подобно предыдущему, но в отношении свойств, касающихся локальной безопасности этой реплики (поддержка локального функционирования списка управления доступом, локальное шифрование).
Рис. 6.12 Закладка дополнительных репликационных установок
· Temporary disable replication. Выбор опции запрещает участие базы в любых репликационных процессах. Сервер выдает сообщение Replication is disabled for <имя>, а станция: Unable to Replicate with Server <имя>: None of the Selected Databases has a Replica on the Server. Опция может быть полезна администратору, если база по каким-то причинам оказалась поврежденной и требуется ее восстановление, прежде чем для нее будут возобновлены репликации.
· CD-ROM publishing date:. Если база данных поступила к вам на CD-ROM, после ее копирования на диск рекомендуется указать в этом поле "дату публикации" базы. Тогда при первой репликации базы с оригиналом на сервере поставщика на предмет участия в репликации будут просматриваться только документы, появившиеся после даты публикации, а не все множество документов (поскольку в историях репликаций в этот момент нет сведений о вашей копии). В результате первая репликация будет выполнена быстрее. Если же вам предстоит записать базу данных на CD-ROM, предварительно рекомендуется задать дату публикации базы, чтобы снять заботу об этом с потребителя.
Приоритеты баз (Scheduled replication priority:), поле Only replicate incoming documents saved or modified after: (в версиях до 4.х известное как Cutoff Date), история репликаций и селективные репликации будут рассмотрены ниже.
Ресертификация без использования почты
1. Если у пользователя истекает срок действия сертификата или пользователь "переходит" из одного подразделения в другое, он делает безопасную копию своего ID-файла: выбор в меню File - Tools - User ID - закладка More Options - кнопка Create Safe Copy. Безопасная копия записывается в файл (обычно SAFE.ID) на дискете. Дискета передается сертификатору.2. Сертификатор выбирает в меню File - Tools - Server Administration - кнопка Certifiers - пункт меню Certify ID File. Затем в окне выбирает ID-файл сертификатора. После этого в новом окне выбирает ID-файл, который надо ресертифицировать - это файл на дискете из пункта 1. Появляются рассмотренные выше окна Certify и Certify ID. Нажимается кнопка Re-certify... Теперь безопасная копия пользовательского ID ресертифицирована. Дискета возвращается владельцу.
3. Пользователь выбирает в меню File - Tools - User ID - закладка More Options - кнопка Merge A Copy. В диалоговом окне выбирает ID-файл с дискеты. Если ID-файл имеет иерархический сертификат, пользователь получает окно Accept New ID Information и нажимает в нем кнопку Ok. Если ID-файл имеет неиерархический сертификат, пользователь получает диалоговое окно Merge Certificate Into Your ID File и нажимает в нем кнопку Merge.
Если ресертификация была связана с переходом в другое подразделение и повлекла изменение полного иерархического имени в ID-файле, могут возникнуть те же самые проблемы, что и при ресертификации с использованием почты...
Ресертификация ID-файлов
Ресертификация имеющихся ID-файлов может потребоваться в следующих случаях:· истекает или просрочен срок действия сертификата;
· старый неиерархический сертификат преобразуется в новый иерархический;
· владелец сертификата изменяет свое подразделение, имя или публичный ключ.
Ресертификация с использованием почты
1. Если у пользователя истекает срок действия сертификата или пользователь "переходит" из одного подразделения в другое, он присылает сертификатору запрос на сертификацию. Для этого пользователь выбирает в меню File - Tools - User ID, далее закладку Certificatesи на ней нажимает кнопку Request Certificate. В окне Mail Certificate Request
вводит адрес сертификатора, "поясняет" причину запроса и нажимает кнопку Send.
Рис. 8.14 Создание запроса на ресертификацию по почте
2. Сертификатор получает в своем почтовом ящике письмо, к которому присоединена "безопасная копия" ID-файла пользователя.
Рис. 8.15 Письмо с запросом на ресертификацию
Сертификатор выбирает в меню Actions - Certify Attached ID file... В появившемся диалоговом окне сначала выбирает тот ID-файл сертификатора, которым собирается ресертифицировать присланный ID-файл. Если требуется только продлить срок действия сертификата, должен выбираться тот же самый ID-файл сертификатора, который был использован при регистрации пользователя. При переходе пользователя из одного подразделения в другое должен выбираться ID-файл сертификатора нового подразделения.
Если присланный ID-файл имеет иерархическое имя, появится диалоговое окно Certify.
Рис. 8.16 Диалоговое окно Certify
Текст в окне Certify - "вы можете выпустить взаимный сертификат на это иерархическое имя и сохранить его в адресной книге или же вы можете заменить иерархию в ID-файле путем ресертификации" - предупреждает о возможности двух вариантов дальнейшего развития событий. Кнопка Cross-certify используется для выпуска взаимных сертификатов... Но в рассматриваемом случае необходима ресертификация - замена всей цепочки сертификатов-компонент иерархического сертификата в содержащемся в письме ID-файле. По нажатию кнопки Re-certify появится окно Certify ID.
Рис. 8.17 Диалоговое окно Certify ID
После возможного изменения срока истечения создаваемого иерархического сертификата, корректировки кнопкой Server имени сервера, в адресной книге которого будут выполнены изменения в документе Person пользователя, и нажатия кнопки Certify появляется окно для отправки ресертифицированного ID-файла его владельцу.
Рис. 8.18 Диалоговое окно Mail Certified ID
3. Пользователю остается "вставить" новый сертификат из возвращенной ему ресертифицированной "безопасной копии" в свой ID-файл. Он находит в своем почтовом ящике письмо с присоединенным ресертифицированным ID файлом. Выбирает в меню Actions - Accept Certificate. При иерархических сертификатах получает окно Accept New ID Information, при неиерархических - Merge Certificate Into Your ID File. Нажимает соответственно кнопки Ok или Accept.
Рис. 8.19 Письмо с ресертифицированной безопасной копией ID-файла
Однако в этот момент, если ресертификация была связана с переходом в другое подразделение и повлекла изменение полного иерархического имени в ID-файле, пользователя могут подстерегать серьезные неприятности. Обычно в списке управления доступом (ACL) почтового ящика пользователя указано, что только он (еще под "старым" именем) и его почтовый сервер являются менеджерами, а остальные вообще не имеют доступа к почтовому ящику. Сменив имя на новое и закрыв почтовый ящик, пользователь более не получит к нему доступа. Чтобы избежать этой достаточно неприятной ситуации, пользователю рекомендуется непосредственно перед сменой имени добавить в ACL своего почтового ящика себя же, но под новым именем. Уже после изменения имени старое имя из ACL можно удалить.
Аналогичная ситуация может иметь место и с другими базами данных. Более того, старое имя пользователя могло использоваться в ряде документов из общей адресной книги и в полях типа Readers и Authors документов из самых различных баз... К сожалению, при выбранном способе ресертификации эту работу по изменению старого имени на новое придется проделать вручную.
Резервное копирование с применением механизма репликаций
Не секрет, что любая автоматизированная система работает до первого сбоя. Сбой произойдет всегда, как бы все не казалось надежным. Вопрос стоит лишь в быстроте устранения сбоя, в количестве потерянной при сбое информации и в мере ответственности эксплуатирующих ее лиц за последствия сбоя.В документации упоминаются следующие способы резервного копирования баз данных:
· выгрузка на стример,
· выгрузка на файл-сервер,
· использование репликаций для поддержки резервных реплик.
По первому и второму вариантам, прежде чем начинать резервное копирование, необходимо остановить сервер Notes. Если же остановка "рабочего" сервера недопустима, предлагается "завести" выделенный сервер, "несущий" реплики баз всех рабочих серверов, а собственно резервное копирование выполнять на нем.
По третьему варианту также необходим отдельный архивный сервер, "несущий" реплики баз со всех рабочих серверов. Рассмотрим настройки в списках управления доступом (ACL) реплик баз, рекомендуемые в этой ситуации:
· ACL "рабочей" реплики:
· -Default- - редактор с правом удалять документы,
· архивный сервер - читатель,
· рабочий сервер - менеджер с правом удалять документы;
· ACL архивной реплики:
· -Default-
- читатель,
· архивный сервер - менеджер с правом удалять документы,
· рабочий сервер - дизайнер или редактор.
Кроме того, в репликационных установках находящихся на архивном сервере реплик баз следует выбрать опцию Do not send deletions made in this replica to other replicas.
Еще один способ решения проблемы резервного копирования состоит в использовании кластеров из серверов Notes (см. 10.4).
Селективные репликации
Начиная репликацию базы, ваш репликатор (или станция) прежде всего строит по документам в реплике на вызванном сервере вид, содержащий все документы, которые могли бы быть приняты вашей стороной. Для этого вида используется отбора SELECT @All.При селективной репликации ваш репликатор (или станция) строит такой вид по документам в реплике на вызванном сервере, используя заданную вами формулу отбора и обычно "отфильтровывающую" меньшее количество документов, чем по формуле SELECT @All.
Для изменения формул селективной репликации необходимо иметь в вашей реплике базы доступ не ниже дизайнера. Чтобы определить формулу, выбирают в окне Replication Settings на закладке Space Savers опцию Replicate a subset of documents:. Далее возможны два варианта. Если не выбирать опции Select by formula, можно выбрать один или несколько видов или папок, документы из которых должны приниматься в вашу реплику. По сути дела, этим вы "сообщаете", что формула отбора селективной репликации является объединением формул отбора выбранных видов плюс объединение коллекций документов из выбранных папок.
Рис. 6.19 В данную базу принимаются только документы из выбранных вида и папки
Если выбрать опцию Select by formula, можно явно указать формулу отбора селективной репликации. В результате в вашу реплику будут приниматься только документы, удовлетворяющие этой формуле.
Рис. 6.20 В данную базу принимаются только документы, удовлетворяющие формуле отбора
Дополнительные возможности по определению формул отбора селективной репликации имеются в окне Replication Settings на закладке Advanced.
Прежде всего, там имеется возможность задать разные формулы отбора для разных пар принимающих изменения (When Computer:) серверов или станций и серверов или станций, с которых принимаются изменения (Receives from:). Если вы уже определили для вашей реплики формулу отбора на закладке Space Savers, то эта формула "окажется" на закладке Advanced как формула отбора в случае, когда в поле When Computer: выбран ваш сервер (или станция), а в поле Receives from: выбрано -Any Server-, т.е. когда в вашу реплику принимаются изменения с любого сервера.
Рис. 6.21 Возможности закладки Advanced
Кроме того, для разных пар When Computer: и Receives from:
можно указать, что должно происходить при репликации списка управления доступом, элементов дизайна, а также конкретизировать вопрос репликации документов. Это достигается выбором опций Replicate incoming:
· Access Control List - принимаются изменения в списке управления доступом;
· Forms, Views, еtс. - принимаются все элементы дизайна, кроме макросов и репликационных формул;
· Agents
- принимаются агенты;
· Replication formula - принимаются репликационные формулы;
· Deletions
- принимаются "окурки", вызывая тем самым удаление документов;
· Fields - принимаются не все поля документов, а только выбранные из списка (это возможно с версии 4.5).
Только имейте в виду, что эти опции должны быть согласованы со списком управления доступом базы. Так, если выбрали на закладке Advanced "прием" в вашу базу элементов дизайна, но в списке управления доступом базы предоставили "поставляющим" эти изменения серверам только доступ редактора, то никаких изменений дизайна вы не получите. Наоборот, даже если "поставляющий" изменения сервер имеет в ACL вашей базы доступ менеджера, но вы не выбрали на закладке Advanced "прием" в вашу базу "окурков", они не будет приниматься в вашу базу.
Опция Replication Formula разрешает принимать в базу назначения (When Computer:) формулы селективной репликации, имеющие более позднее время модификации. В принципе это позволяет менеджеру "центральной" реплики базы разрабатывать формулы селективной репликации для всех других серверов, перебирая всевозможные сочетания When Computer: и Receives from:.
Таким образом:
· селективная репликация будет фактически уменьшать количество принимаемых в данную реплику документов, если вы создаете более ограничительную формулу, чем SELECT @All;
· использование ... | @IsResponseDoc в формуле отбора будет реплицировать вообще все ответные документы (responses), независимо от того, соответствуют ли они отбираемому главному документу или нет;
· использование ... | @AllDescendants в формуле отбора будет реплицировать все ответные документы (responses) на отбираемые главные документы и, рекурсивно, на их ответные документы;
· использование ... | @AllChildren в формуле отбора будет реплицировать только ответные документы (responses) непосредственно на отбираемые главные документы;
· информация о формуле отбора принимаемых в базу документов сохраняется в той базе, в которой она создана, но может реплицироваться в другие базы, если у них выбрана опция Replication Formula и предоставлен необходимый уровень доступа.
Сервер Domino - серверная задача HTTP
HTTP Сервер Domino с консоли сервера Notes "запускается" как серверная задача HTTP - командой Load HTTP. Сервер Domino (конкретнее его компонента HTTP Server, а более точно, первый свободный из многочисленных подпроцессов HTTP Server) ожидает установления соединения по протоколу HTTP с клиентом Web, обычно "оснащенным" броузером наподобие Microsoft Internet Explorer или Netscape Navigator, и затем запроса от клиента Web на нужный ресурс (GET URL). HTTP Serverанализирует URL входящего запроса и определяет, требуется ли клиенту единица информации из базы данных Notes или HTML-файл из файловой системы. Если был запрошен HTML-файл, HTTP Server, действуя точно так же, как любой другой из множества применяемых в настоящее время HTTP-серверов, передает запрошенный файл клиенту. Если же была запрошена единица информации из базы данных Notes, HTTP Server
через Domino Engine обращается к соответствующей базе, извлекает из нее необходимую информацию, преобразует эту информацию в формат HTML и передает клиенту, или же, наоборот, помещает информацию от клиента в базу данных Notes.
Рис. 3.30 Укрупненная архитектура сервера Domino
Domino, формально оставаясь в рамках соглашения о синтаксисе URL, интерпретирует его более широко, что и позволяет клиенту использовать функциональные возможности Notes.
Например, URL http://www.inttrust.ru/Site/intrnews.nsf?OpenDatabase "открывает"
базу данных Site/intrnews.nsf на сервере Notes.
Рис. 3.31 Так выглядит база данных Notes стандартного оформления в окне броузера
Domino автоматически транслирует такие конструкции Notes, как навигаторы, виды, документы, связи (Document Link, View Link, Database Link)
и некоторые кнопки действий, в формат HTML и затем предоставляет их клиенту Web. Например, связи и кнопки действий Notes "станут"
URL "у Web-клиента". Нажав на странице броузера кнопку, соответствующую созданию нового документа (ee URL "заканчивается" на ?OpenForm), пользователь может создать новый документ в базе данных Notes.
Рис. 3.32 Создание нового документа в базе данных Notes из окна броузера
Вопросы настройки задачи HTTP подробно рассматриваются в 10.2.
Server - сервер домена
Документы формы Server содержат информацию о серверах данного домена. Они создаются автоматически при установке первого сервера и регистрации новых серверов в данном домене. В адресной книге домена такие документы обязательно должны присутствовать для всех серверов в домене - каждый домен "полностью знает" свою топологию. Обычно необходимости в наличии в адресной книге документов Server для серверов из других доменов нет - домен "не знает" полную топологию других доменов, кроме информации из документов Connection о тех внешних серверах, с которыми могут соединяться серверы данного домена. Единственный случай, когда в адресной книге все-таки приходится создавать документы Server для серверов из других доменов - в одном или нескольких документах Server данного домена выбрана опция Compare public keys against those stored in Address Book (рассматривается ниже).Приступим к рассмотрению документа Server.
Рис. 4.17 Заголовок и секции документа Server
В заголовке документа:
· Server name:
- имя сервера;
· Domain name: - имя домена, членом которого является этот сервер;
· Cluster name: - имя кластера, которому принадлежит сервер, или пусто, если сервер не является членом кластера. Не рекомендуется "вручную" корректировать это поле - оно изменяется задачей Administration Process при добавлении сервера в кластер или выводе сервера из кластера;
· Master address book name: - имя файла базы данных Master Address Book или пусто, если возможность не используется. Не рекомендуется "вручную" корректировать это поле - это делает задача Administration Prоcess. Подробнее применение Master Address Book рассматривается в 10.1;
· Administrators:
- администраторы сервера. Это поле-список, его члены (пользователи или группы) имеют привилегию передавать на сервер команды с удаленной консоли;
· Routing tasks: - задачи по передаче почты, выполняемые сервером. Обычно в поле выбрано Mail Routing - сервер выполняет передачу почты Notes. Если на этом сервере установлены другие агенты передачи почты (MTA), дополнительно, в соответствии с наличием агентов, нужно выбрать X.400 Mail Routing, SMTP Mail Routing, ccMail Routing.
Перейдем к рассмотрению секций документа.
Рис. 4.18 Информация о местоположении сервера
Обычно секция Server Location Information не требует корректировок. Поле Prefix for outside line: может содержать префикс, автоматически добавляемый к телефонному номеру из документа Connection, когда сервер выполняет исходящие вызовы. Поля Mail server:, Passthry server: и InterNotes server: используются на станции, запущенной на компьютере сервера, и трактуются аналогично одноименным полям в документе Location из персональной адресной книги. Однако поле Passthry server: используется также и сервером: если сервер не сможет установить соединение с сервером назначения, он попытается воспользоваться услугами сервера-посредника по умолчанию, указанного в этом поле.
Рис. 4.19 Сетевая конфигурация
Секция Network Configuration уже рассматривалась нами в 1.4.3 и 2.1.5.
Рис. 4.20 Секция Proxy Configuration
Секция Proxy Configuration появилась в документе Server, начиная с версии 4.5, и связана с тем, что теперь сервер (и клиент) Notes может соединяться по протоколу TCP/IP с другим сервером Notes или осуществлять доступ к Web-серверам не только "напрямую", но и через proxy-сервер. В последнем случае сам сервер Notes (или клиент)
обычно находится во внутрикорпоративной сети, но имеет доступ "во внешний мир" через корпоративный proxy-сервер по некоторым портам, оставаясь "невидимым из внешнего мира".
Рис. 4.21 Сервер и клиент Notes, начиная с
версии 4.5, способен работать по протоколу TCP/IP
через proxy-сервер
Если вы вообще не используете proxy-сервер, все поля в секции Proxy Configuration должны быть пусты. Если используете, то указываете в соответствующих полях его IP-адрес или хост-имя и порт, разделяя их двоеточием, например, proxy.company.com:8080.
Поля HTTP proxy:,
FTP proxy: и Gopher proxy: заполняются, если выполняющаяся на вашем сервере задача WEB осуществляет доступ к Web-серверам в Internet не напрямую, а через proxy-сервер (см. 3.2.15).
Поле SSL Security proxy:
заполняется, если выполняющаяся на вашем сервере задача WEB осуществляет доступ к Web-серверам в Internet
по протоколу SSL через proxy-сервер.
Поле Notes RPC proxy: заполняется, если ваш сервер Notes связывается по протоколу TCP/IP с другими серверами Notes
не напрямую, а через HTTP proxy-cepвер с поддержкой SSL Tunneling Specification. Все выполняемые сервером Notes RPCs (Remote Procedure Calls) в этом случае передаются серверу назначения посредством протокола HTTP.
Поле SOCKS proxy: заполняется, если для доступа к WEB-серверам или серверам Notes ваш сервер Notes использует SOCKS proxy-сервер.
Поле No proxy for these hosts and domains: может содержать список тех
хостов, доступ к которым должен осуществляться напрямую, а не через proxy-сервер. В поле допустимы хост-имена, имена доменов Internet и содержащие символ "*" шаблоны, но не IP-адреса. Например, "inttrust.rinet.ru; lotus.com;*.ibm.*".
Рис. 4.22 Секция Security
Секция Security позволяет выбрать для данного сервера дополнительные возможности по обеспечению безопасности.
· Compare public keys against those stored in Address Book: - если выбрано Yes, то в процессе установления подлинности (аутентификация) пользователя или сервера, связывающегося с данным сервером, публичный ключ этого пользователя или сервера из его ID-файла будет сравниваться с его публичным ключом из документа Person или Server в общей адресной книге данного сервера. Это нововведение версии 4.х, существенно повышающее общую безопасность. Теоретическая причина появления такой возможности заключена в самой процедуре установления подлинности, которая рассматривается в 8.3. Практическое применение этой возможности требует наличия в общей адресной книге документов Person и Server, содержащих публичные ключи пользователей и серверов. Если к серверу имеют доступ только пользователи и серверы этого домена, проблем не возникает, поскольку соответствующие документы присутствуют в общей адресной книге. Но если к серверу должны иметь доступ пользователи и серверы из других доменов, то потребуется предварительно поместить в адресную книгу данного домена необходимые документы Person и Server
из адресных книг других доменов.
· Check passwords: - если выбрано Yes, данный сервер будет дополнительно сравнивать пароль, который хранится в ID-файле пользователя, осуществляющего доступ к серверу, со значением пароля, которое хранится в зашифрованном виде в документе Person данного пользователя. Это нововведение версии 4.5, позволяющее предотвратить доступ к серверу тех пользователей, которые ранее имели копию ID-файла данного пользователя и знали ее пароль. После смены пароля законным владельцем в своем ID-файле и его первого контакта с сервером, на котором включена опция Check passwords, "незаконные" владельцы, используя имеющиеся у них копии ID-файла этого пользователя, уже не смогут получить доступ к данному серверу. Возможность работает не для всех пользователей, перечисленных в адресной книге, а только для тех, в документах Person которых она предварительно включена. Применение этой возможности дополнительно обсуждается в 8.5.9.
· Allow anonymous connection: - выбор Yes, напротив, позволяет любому серверу или клиенту, даже если для него процедура установления подлинности завершилась неуспешно, получать доступ к данному серверу. Такой "не аутентифицированный" пользователь или сервер получает доступ к данному серверу под именем Anonymous. Соответственно, имя Anonymous
может использоваться в списках управления доступом расположенных на сервере баз для конкретизации уровня доступа в них. Это нововведение версии 4.х позволяет делать сервер Notes "общедоступным".
Остальные поля секции Security касаются задачи HTTP, а потому рассматриваются в 10.2.
Рис. 4.23 Список управления доступом к серверу
Секция Restrictions управляет доступом к серверу и возможностями, предоставляемыми данным сервером его клиентам. Поэтому эту секцию часто называют списком управления доступа к серверу (Server Access List). Перейдем к рассмотрению полей секции.
· Only allow server access to users listed in this Address Book: - если выбрано Yes, то к этому серверу могут иметь доступ только пользователи и серверы, для которых в общей адресной книге имеются документы Person или Server. Позволяет легко "закрыть" сервер от любых внешних пользователей и серверов.
· Access server:
- если список пуст, к серверу получают доступ все пользователи и серверы, для которых процесс установления подлинности, с учетом уже рассмотренного в секции Security
и предыдущем поле, завершился успешно. Если список не пуст, доступ к серверу получают только перечисленные в нем. В поле можно указывать серверы, пользователей и группы. Отдельный символ "*" означает всех пользователей из скрытого вида ($Users) в адресной книге (учтите, что в этом виде отсутствуют серверы). Конструкция *имя_вида
означает всех из указанного вида адресной книги. Например, *People обозначает всех из вида People. Иначе трактуется использование символа "*" в иерархическом имени. Например, */Sales/Acme обозначает всех, имена которых заканчивается на /Sales/Acme.
· Not access server: - список тех, кому запрещен доступ к серверу. Содержащиеся в списке не получат доступа к серверу, даже если для них процесс установления подлинности, с учетом всех уже рассмотренных нюансов, завершился успешно. По умолчанию поле пусто, т.е. доступ к серверу никому явно не запрещен. Если кто-то явно или как член группы одновременно присутствует и в поле Access server:, и в поле Not access server:, он не получит доступа к серверу. Если в вашей адресной книге имеется группа наподобие Terminations, рекомендуется указать ее в поле Not access server:.
· Create new databases: - список тех, кто имеет право создавать новые базы данных на этом сервере. Если пусто, могут все пользователи, имеющие доступ к этому серверу.
· Create replica databases: - список тех, кто может создавать реплики баз данных на этом сервере. Если пусто, то НИКТО не может (кроме работающего локально на этом компьютере). Обычно только сервер и его администратор должны иметь возможность создавать реплики баз. Если имеется группа наподобие Replica Makers, рекомендуется включить ее.
· Access this server: (Passthru Use) - по умолчанию это поле пусто, означая, что никто не получит доступа на данный сервер, если он использует для этого какой-то другой сервер-посредник. Чтобы разрешить доступ к этому серверу через один или несколько других серверов-посредников, укажите в поле всех пользователей и все серверы, которым это разрешено. Можно вводить имена пользователей, серверов, групп. Чтобы позволить всем пользователям, даже если они не перечислены в общей адресной книге, иметь такой доступ, используют символ "*". Конструкция *имя_вида, например, *People, означает всех из указанного вида общей адресной книги. Чтобы позволить всем пользователям, сертифицированным конкретным сертификатором, иметь доступ, введите звездочку и затем через наклонную черту вправо имя сертификатора, например, */Acme. Наконец, учтите, что если это поле пусто, то его значение берется сервером из переменной Allow_Passthru_Access в файле NOTES.INI, если, конечно, переменная там имеется и не пуста. Если же поле не пусто, значение из него "перекрывает" значение переменной Allow_Passthru_Access.
· Route through: (Passthru Use) - по умолчанию это поле пусто, что означает, что никто не может использовать этот сервер как сервер-посредник для доступа к другому серверу. Применяя аналогичные рассмотренному выше полю конструкции, укажите список тех, кому данный сервер должен предоставлять посреднические услуги для доступа к другим серверам.
· Cause calling: (Passthru Use) - по умолчанию это поле пусто, означая, что данный сервер "не позволяет" пользователям и другим серверам "вынуждать" его выполнять телефонный вызов на сервер назначения. Поле позволяет управлять "телефонными расходами" данного сервера-посредника. Оно должно включить всех пользователей и все серверы, которым разрешается "вынуждать" данный сервер на выполнение телефонного вызова другого сервера. Например, если сервер A, выполняя репликации с сервером C, использует модем на сервере-посреднике B, чтобы связаться с сервером C, следует задать имя сервера A в поле Cause calling:
на сервере-посреднике B. В поле допустимы и шаблоны наподобие */Acme.
· Destinations allowed: (Passthru Use) - если поле пусто, то данный сервер, функционируя как посредник, может вызывать любые серверы назначения (конечно, только в пределах доступных ему серверов). Если вы хотите разрешить доступ через данный сервер только к конкретным серверам, укажите в этом поле имена этих серверов. Обратите внимание, что можно также ограничивать доступ к серверам назначения в поле Access this server: (Passthru Use) документов Server самих серверов назначения; однако это будет ограничивать доступ к ним через любые серверы-посредники, а не только через конкретный сервер-посредник.
Секции Agent Manager,
Administration Process и Web Retriever Administration нами уже рассматривались соответственно в 3.2.3, 3.2.14 и 3.2.15. Секция HTTP Server рассматривается в 10.2.
Если на сервере не установлено программное обеспечение ни одного из дополнительных агентов передачи почты, секции Internet Message Transfer Agent (SMTP MTA), X.400 Message Transfer Agent (X.400 MTA)
и cc:Mail Message Transfer Agent (cc:Mail MTA) попросту пусты. Информация в них "появится" только после установки на сервер необходимого агента передачи почты. При установке соответствующая "пустая" субформа, имеющаяся в штатном шаблоне общей адресной книги, заменяется входящей в комплект поставки агента субформой, в полях которой и задается относящаяся к агенту настроечная информация. Отметим, что секция Internet Message Transfer Agent (SMTP MTA) подробно рассматривается в 7.11.
В оставшейся части документа прежде всего обратите внимание на сертифицированный публичный ключ сервера. Поля с метками Owners: и Administrators: присутствуют во всех документах общей адресной книги. Это поля типа Authors и они могут содержать списки тех, кто может редактировать данный документ, имея лишь авторский доступ к адресной книге.
Рис. 4.24 "Хвост" документа Server
Поле Change Request: используется задачей Administration Process и не должно изменяться администратором.
Отметим, что в документе Server имеется также несколько "не показываемых в форме" полей, которые сервер модифицирует при своей работе.
Серверная задача Administration Process
ADMINP По умолчанию задача Administration Process запускается при старте сервера версий 4.х и работает до его останова. При первом запуске задачи Administration Process на сервере автоматически создается база данных Administration Requests (ADMIN4.NSF).Когда администратор, "открыв" общую адресную книгу, создает запросы на изменение имени пользователя или сервера, ресертификацию ID пользователя и сервера, удаление пользователя, сервера или группы (включая при этом и изменения в списках управления доступом во многих базах данных на многих серверах), эти запросы сначала заносятся в базу данных Administration Requests и только затем задача Administration Process выполняет на сервере каждый такой запрос.
Для того чтобы запрошенные изменения происходили на всех серверах домена, на этих серверах должны присутствовать реплики базы Administration Requests. В частности, в процессе установки очередного сервера версии 4.х в домене на нем автоматически создается реплика базы Administration Requests (с того же сервера, с которого реплицировалась и адресная книга). Запросы поступают во все реплики базы Administration Requests путем репликаций, а исполняются задачей Administration Process на соответствующих серверах.
Имеется важный момент, связанный с изменениями по запросу в документах из общей адресной книги, в списках управления доступом находящихся на сервере баз и (с версии 4.5) некоторых документов в этих базах. Эти изменения должны произойти только в одной реплике базы, и затем путем репликаций распространиться в документы и списки управления доступом ее реплик на других серверах. Если такие изменения произойдут сразу во всех репликах, могут возникнуть множественные репликационные конфликты. Поэтому, когда имеются реплики базы данных на многих серверах, вы должны определить (указать), в какой именно реплике базы задача Administration Process должна выполнять эти изменения - который из серверов будет сервером администрирования этой базы. Когда вы определили сервер администрирования для базы, вы по сути указали одну реплику, в которой Administration Process модифицирует документы и имена в списке управления доступом, и затем Notes реплицирует эти изменения в остальные реплики по расписанию репликаций.
Подготовка к использованию Administration Process
Прежде, чем использовать Administration Process, проверьте и обеспечьте следующее.
· Все серверы домена переведены на версию 4.х и имеют иерархические имена.
· На серверах присутствует реплика базы "Протокол сертификаций" - CERTLOG.NSF (см. 4.4). Создана соответствующая организации иерархия сертификаторов (см. 8.4). Сертификаторы, которые будут регистрировать или ресертифицировать пользователей и серверы, имеют к этой базе по крайней мере доступ автора с правом создавать документы.
· В файле NOTES.INI сервера в строке ServerTasks= <задачи, запускаемые при старте
сервера> присутствует задача Adminp.
· Вы, как основной администратор, имеете к базе Administration Requests доступ менеджера. В список управления доступом (ACL) базы Administration Requests добавлены все администраторы и сертификаторы (или их группы) с доступом не ниже автора с правом создания документов. База Administration Requests добавлена в рабочее пространство станций администраторов и сертификаторов.
· Вы, как основной администратор, имеете к общей адресной книге доступ менеджера. В ACL общей адресной книги добавлены все администраторы и сертификаторы (или их группы) с доступом не ниже автора с правом создания и удаления документов и назначением хотя бы на одну из ролей GroupModifier, ServerModifier, UserModifier. Всем другим лицам, группам и серверам также предоставлен необходимый доступ.
· Для общей адресной книги и для "практически всех" других баз назначен сервер администрирования (см. ниже).
· Изменения, выполненные в ACL баз на исходно выбранных серверах, распространились репликациями на остальные серверы домена.
"Массовое" назначение сервера администрирования для баз в Notes версий до 4.5 осуществляется так: в меню File - Tools - Server Administration; выбор сервера; кнопка Databases; в меню кнопки выбор Database Administration Server; выбор общей адресной книги или иных баз из списка; ввод полного имени сервера администрирования; кнопка Set.
Рис. 3.17 Назначение сервера администрирования для нескольких баз в версиях до 4.12
В версии 4.5 это уже выглядит несколько иначе, однако принципиальных отличий нет.
Рис. 3.18 Назначение сервера администрирования для нескольких баз в версиях от 4.5
Выполненные действия изменяют список управления доступом базы - имя сервера администрирования добавляется в ACL с доступом менеджера, причем этот сервер изображается с пиктограммой
Назначить сервер администрирования для конкретной базы удобнее из ее списка управления доступом. На закладке Avanced выбираем из списка сервер администрирования и нажимаем кнопку Ok.
Рис. 3.19 Назначение сервера администрирования из списка управления доступом базы
В результате в ACL получаем следующее.
Рис. 3.20 Так выглядит сервер администрирования в ACL
Выдав с консоли сервера команду Tell Adminp Show Databases, можно получить список тех баз, для которых этот сервер назначен сервером администрирования.
Типы запросов, выполняемых задачей Administration Process
Выполнив подготовительные действия, вы и "допущенные" вами администраторы и сертификаторы обретаете возможность создавать различные запросы для задачи Administration Process. Наибольший интерес представляют запросы, связанные с трудоемкими операциями по изменению имен пользователей, включая "вытекающие из них" изменения имен в списках управления доступом всех баз данных на всех серверах домена. Наиболее часто запрос создается из общей адресной книги выбором соответствующей акции (кнопкой на панели вида или в меню Actions). Однако общая адресная книга не единственное "место", откуда можно создать запрос. В Notes версии 4.5 некоторые запросы создаются из окна Administration кнопкой Database Tools и далее выбором нужной операции (например, создание реплик многих баз или перемещение баз между серверами-членами кластера).
Ниже перечислены все возможные типы "базовых" запросов, поддерживаемых версиями Notes до 4.12 включительно.
· Delete
- удалить пользователя или сервер.
· Rename in Access Control List - изменить имя в списках управления доступом баз данных (например, после изменения имени пользователя или сервера).
· Copy Server's Certified Public Key - занести в документ Server новый публичный ключ.
· Place Server's Notes Build Number into Server Doc - занести в документ Server номер версии (автоматически появляется после upgrade сервера).
· Rename Server in Address Book - изменить имя сервера в документах общей адресной книги.
· Rename Person in Address Book - изменить имя пользователя в документах общей адресной книги.
· Move Person's Name in Hierarchy - ресертифицировать пользователя, то есть "переместить его в иерархии имен организации из одного поддерева в другое". Запрос создается сертификатором оргединицы, которую пользователь "покидает", и требует последующего участия сертификатора оргединицы, в которую пользователь "переходит". "Принимающий" пользователя сертификатор инициирует запрос на сертификацию пользователя.
· Delete Statistic Monitors in Address Book - удалить из общей адресной книги документы Statistic Monitors после upgrade системы удаленного мониторинга в домене с версий 3.x на версии 4.х.
· Initiate Rename in Address Book - инициирование процесса изменения имени, всегда влечет появление "последующих" запросов.
· Recertify Server in Address Book - ресертифицировать сервер.
· Recertify Person in Address Book - ресертифицировать пользователя.
В версии 4.5 этот список расширен.
· Add Resource
- добавить ресурс.
· Approve Resource Deletion - подтвердить удаление ресурса.
· Delete Resource
- удалить ресурс.
· Add Server to Cluster - добавить сервер в кластер.
· Remove Server from Cluster - удалить сервер из кластера.
· Approve File Deletion - подтвердить удаление файла.
· Change User Password in Address Book - изменить пароль пользователя в адресной книге.
· Check Access for Move Replica Creation - проверить наличие необходимого уровня доступа при перемещении реплики базы с сервера на сервер.
· Check Access for New Replica Creation - проверить наличие необходимого уровня доступа при создании новой реплики базы.
· Create Mailfile
- создать почтовый ящик.
· Delete Mailfile
- удалить почтовый ящик.
· Delete Unlinked Mailfile - удалить почтовый ящик, отсоединенный от совместно используемого почтового ящика.
· Create Replica
- создать реплику.
· Move Replica
- переместить реплику с сервера на сервер.
· Monitor Replica Stub - "контролировать окурок" реплики (в процессе создания или перемещения реплики базы).
· Delete Original Replica after Move - удалить исходную реплику после ее перемещения на другой сервер.
· Request File Deletion
- запрос на удаление файла.
· Get File Information for Deletion - получить информацию об удаляемом файле (перед удалением).
· Rename in Person Documents - изменить имя в документах Person адресной книги.
· Delete in Person Documents - удалить имя в документах Person адресной книги.
· Rename in Reader/Author fields - изменить имя в полях типа Reader или Author.
· Delete in Access Control List - удалить из списка управления доступом.
· Delete in Reader/Author fields - удалить имя из полей типа Reader и Author.
· Set Password Fields - установка полей пароля в документах Person адресной книги.
· Delete Obsolete Change Requests - удалить старые запросы.
Обратите внимание, что были перечислены именно "базовые" запросы - своего рода "кирпичики", из которых состоит "сложный" запрос. Каждая связанная с задачей Administration Process акция влечет за собой появление целой серии связанных запросов для ее реализации, причем последующие запросы создаются самой задачей Administration Process в ходе обработки предшествующих запросов. Существуют запросы, для выполнения которых требуется участие администратора или пользователя. Выполнение каждого из запросов задачей Administration Process влечет появление ответных документов - отчетов о выполнении.
Например, в Notes версии 4.11a процесс удаления пользователя происходит следующим образом. Акция "Delete Person", инициированная из адресной книги на одном из серверов домена, влечет появление в базе Administration Requests этого сервера запроса Delete. Запрос репликациями поступает в базы Administration Requests других серверов домена и выполняется на сервере, который является сервером администрирования для адресной книги. Задача Adminp
"устраняет" имя пользователя из всех документов адресной книги, кроме документа Person. Выполнение "протоколируется" ответным документом. Задача Adminp порождает еще два запроса - на удаление в документах Person адресной книги и удаление в списках управления доступом баз. Эти запросы и уже выполненные изменения в адресной книге распространяются репликациями на другие серверы домена. Задачи Adminp на каждом из серверов домена удаляют имя этого пользователя из списков управления доступом тех баз, для которых данный сервер является сервером администрирования. Выполнение "протоколируется" ответными документами. Выполненные изменения в списках управления доступом баз распространяются репликациями на другие серверы домена. Задача Adminp
на сервере администрирования адресной книги удаляет документ Person этого пользователя, а выполнение "протоколируется" ответным документом. Удаление документа Person в адресной книге репликациями достигает адресных книг на других серверах домена.
В Notes версии 4.5 дополнительно производится удаление имени пользователя из полей типа Readers и Authors в документах баз на их серверах администрирования, а так же удаление файла почтового ящика пользователя.
Рис. 3.21 "Протокол" удаления пользователя из базы ADMIN4.NSF
в
Notes версии 4.51
Процессы, происходящие при изменении имени пользователя и ресертификации пользователя, подробно рассматриваются в 8.5.7 и 8.5.8.
Переменные из NOTES.INI, влияющие на работу Administration Process в Notes версий ниже 4.5
К задаче Administration Process имеют отношение следующие переменные из NOTES.INI.
· AdminpInterval - частота в минутах, с которой задача проверяет появление запросов в базе Administration Requests. Значение по умолчанию - 60 минут.
· AdminModifyPersonDocumentsAt - час, когда производится изменение документов Person в адресной книге и вносятся изменения в ACL баз (0 - 24:00, 1 - 1:00, …, 23 - 23:00).
Управление работой Administration Process в Notes версий 4.5
Основное отличие от предыдущих версий - "перенос" параметров в документ Server и добавление двух новых.
· AdminpInterval
- частота в минутах, с которой задача проверяет появление запросов в базе Administration Requests. Однако задача Administration Process в первую очередь проверяет, не установлено ли соответствующее значение в документе Server в поле с меткой Interval:, и, только если оно не установлено в документе, пытается использовать значение соответствующей переменной из NOTES.INI. Если это значение не определено ни в документе Server, ни в файле NOTES.INI, используется значение по умолчанию - 60 минут.
· AdminPModifyPersonDocumentsAt
- задача Administration Process модифицирует документы Person в общей адресной книге ежедневно в заданное в документе Server в поле с меткой Execute once a day requests at: (Выполнять один раз в день запросы в:) время. Если значение не установлено в документе Server - используется значение переменной AdminPModifyPersonDocumentsAt из NOTES.INI. Если значение нигде не установлено, используется значение по умолчанию - в 12 часов дня.
· Поле с меткой Interval between purging mail file and deleting used object store: определяет интервал времени от удаления почтового ящика до удаления связанных с ним тел сообщений в совместно используемом почтовом ящике задачей Object с параметром Collect. Значение по умолчанию 14 дней.
· Поля с метками Starting executing on: и Start executing at: определяют, по каким дням недели и во сколько времени на сервере администрирования должны выполняться "вызванные" операциями изменения имени пользователя, сервера или группы, а также удаления пользователя, сервера или группы "трудоемкие" запросы на выполнение соответствующих изменений в полях типа Author и Reader документов в базах. Значение по умолчанию - в воскресенье в 12 часов дня.
Рис. 3.22 Фрагмент документа Server из адресной книги Notes версии 4.5
Сколько времени занимает выполнение "сложного" запроса?
Выполнение "сложного" запроса занимает довольно значительное время. Точно ответить на этот вопрос, принимая во внимание расписание репликаций между серверами домена, достаточно затруднительно. Однако в понимании этого вопроса вам поможет приводимая ниже таблица. Она относится к Notes версии 4.5. В первом столбце таблицы приведены наиболее часто встречающиеся в практике "сложные" запросы, во втором столбце - связанные с выполнением этих запросов "базовые" запросы, а в третьем - условия, в соответствии с которыми задача Administration Process начинает выполнение "базового" запроса. В третьей колонке для краткости использованы следующие обозначения:
· "по появлению" - приблизительно через минуту после поступления запроса в базу Administration Requests,
· "интервал"
- в соответствии с установкой AdminpInterval или Interval: (по умолчанию каждые 60 минут),
· "раз в день" - в соответствии с установкой AdminPModifyPersonDocumentsAt или Execute once a day requests at: (по умолчанию в 12 часов дня),
· "раз в неделю" - в соответствии с установками Starting executing on:
и Start executing at:
(по умолчанию в воскресенье в 12 часов дня),
· "через две недели" - с соответствии с установкой Interval between purging mail file and deleting used object store: (по умолчанию раз в 14 дней),
· "администратор"
- после того, как администратор обнаружит запрос в базе и выполнит необходимые необходимые действия по запросу.
|
"Сложный" запрос |
Связанные запросы |
Когда начинается выполнение связанного запроса |
|
Изменение имени пользователя |
Initiate Rename in Address Book |
Интервал |
|
Rename Person in Address Book |
Интервал |
|
|
Rename in Access Control List |
Интервал |
|
|
Rename in Person Documents |
Раз в день |
|
|
Rename in Reader/Author Fields |
Раз в неделю |
|
|
Move Person's Name in Hierarchy |
Администратор |
|
|
Delete Obsolete Change Requests |
Раз в день ** |
|
|
Ресертификация пользователя |
Recertify Person in Address Book |
Интервал |
|
Ресертификация сервера |
Recertify Server in Address Book |
Интервал |
|
Удаление пользователя, |
Delete in Address Book |
Интервал |
|
сервера или группы |
Delete in Person Documents |
Раз в день |
|
Delete in Access Control List |
Интервал |
|
|
*) только при удалении |
Delete in Reader/Author Fields |
Раз в неделю |
|
пользователя |
Get Information for Deletion* |
По появлению |
|
Approve File Deletion* |
Администратор |
|
|
Request File Deletion* |
По появлению |
|
|
Delete Mail File* |
Интервал |
|
|
Delete Unlinked Mail File* |
Через две недели |
|
|
Установка Master Address Book |
Set Master Address Book |
Интервал |
|
Установка проверки пароля |
Set Password Information |
Интервал |
|
при аутентификации |
Change User Password in Address Book |
По появлению |
|
Создание реплик многих баз |
Check Access for New Replica Creation |
По появлению |
|
Create Replica |
По появлению |
|
|
Добавление сервера в кластер |
Add Server to Cluster |
По появлению |
|
и удаление сервера из кластера |
Remove Server from Cluster |
По появлению |
|
Перемещение многих баз |
Check Access for Move Replica Creation |
По появлению |
|
между серверами-членами |
Move Replica |
По появлению |
|
кластера |
Monitor Replica Stub |
Интервал |
|
Delete Original Replica After Move |
Интервал |
**) Проверка наличия "устаревших" запросов на изменение имени выполняется задачей Adminp ежедневно. Запрос считается "устаревшим" и удаляется, если пользователь не осуществил изменение своего имени в ID-файле в течение заданного в файле NOTES.INI переменной Name_Change_Expiration_Days количества дней (по умолчанию 21 день, допустимые значения в диапазоне от 14 до 60 дней).
Команды, которые можно передать задаче Administration Process
Задача Adminp версии до 4.5 принимает и обрабатывает следующие команды.
· Tell Adminp Process All - задача должна проверить в базе Administration Requests все запросы, выбрать из них те, которые "ожидают" обработки, и выполнить их. Если были обнаружены запросы Delete или Rename Person in Address Book, требующие изменений в документах Person из адресной книги, они тоже выполняются.
· Tell Adminp Process New
- задача должна проверить в базе Administration Requests только те запросы, которые появились или были модифицированы после момента предыдущей проверки базы (в соответствии с параметром AdminpInterval), и выполнить их. Если были обнаружены запросы Delete или Rename Person in Address Book, требующие изменений в документах Person адресной книги, задача только "предупреждает", что такие запросы должны выполняться в запланированное параметром AdminModifyPersonDocumentsAt время, но не выполняет их.
· Tell Adminp Process People - задача должна проверить в базе Administration Requests только запросы Delete или Rename Person in Address Book, требующие изменений в документах Person адресной книги, и выполнить изменения в документах Person.
· Tell Adminp Show Databases - позволяет получить список названий и имен файлов тех баз, для которых данный сервер назначен сервером администрирования.
В версии Notes 4.5 вместо приведенных выше используются следующие команды:
· Tell Adminp Process Interval - выполнить запросы, которые должны выполняться непосредственно по появлению, а также те, которые должны выполняться в соответствие с установкой Interval. Аналог Tell Adminp Process New.
· Tell Adminp Process Daily
- выполнить новые и модифицированные запросы на изменение в документах Person в общей адресной книге. Аналог Tell Adminp Process People.
· Tell Adminp Process Delayed
- выполнить запросы, которые должны выполняться в соответствии с установками Start executing on и Start executing at.
· Tell Adminp Process Time - выполнить все типы новые и модифицированные запросы Delete unlinked mail file.
· Tell Adminp Process All - выполнить все типы новых и модифицированных запросов, кроме Delete unlinked mail file.
Внимательный читатель может быть удивлен приведенными на Рис. 3.21 значениями времени: получается, что запрос на удаление пользователя был почти полностью выполнен всего за 6 минут. Во-первых, запрос выполнялся на серверах-членах кластера, где "цикл репликаций" составлял не более 15 секунд. Во-вторых, процесс "принудительно ускорялся" командой консоли Tell Adminp Process All.
Причиной появления задачи Administration Process явилось применение в Notes "децентрализованной и распределенной в пространстве" системы защиты информации: сервер "защищается" в общей адресной книге, базы данных - в их списках управления доступом, отдельные документы в базах - полями типа Readers и Authors в самих документах... Любые изменения при такой системе защиты сопряжены с выполнением изменений "во многих местах на многих серверах". Аккуратно и быстро "вручную" выполнять такие изменения в больших доменах весьма трудоемко. Поэтому очень рекомендуем начинающим администраторам уделить достаточно времени изучению задачи Administration Process на практике - без использования этой задачи "удержать в руках" систему защиты большого домена практически невозможно.
Серверная задача Agent Manager
AMGR В версиях 4.х выполнение агентов в базах, расположенных на сервере, обеспечивает задача Agent Manager.
Рис. 3.5 Если данная база расположена на сервере, агенты RIDUID и UpdateMailIn будет выполнять задача Agent Manager
Агенты (см. Рис. 3.6) могут быть "написаны" с использованием простых действий, @-формул или на языке LotusScript. Агенты бывают двух типов:
· личные
(personal) - для их создания достаточно иметь доступ не ниже читателя с установленной опцией Create Personal Agents и, чтобы дополнительно иметь возможность создавать агентов на языке LotusScript, с установленной опцией Create LotusScript Agents
· общие
(shared) - для их создания необходим доступ не ниже дизайнера и, чтобы дополнительно иметь возможность создавать агентов на языке LotusScript, с установленной опцией Create LotusScript Agents.
Как общие, так и личные агенты, в зависимости от заданных условий их запуска (When should this agent run?), могут выполняться как станцией, так и сервером. На сервере выполняются только агенты с условиями запуска If New Mail Has Arrived
(по событию прихода почты в базу), If Documents Have Been Created or Modified (по событию создания или изменения документа в базе) и On Schedule... (по расписанию...), а осуществляет их выполнение серверная задача Agent Manager. Агенты с другими условиями запуска всегда выполняются станцией.
Агенты, написанные на языке LotusScript, в зависимости от использованных их разработчиком языковых возможностей и методов встроенных классов, могут быть "ограниченными по возможностям" (restricted) или "неограниченными по возможностям" (unrestricted). "Неограниченные по возможностям" агенты могут работать с файлами, изменять системное время, отправлять почту, запускать другие программы или вызывать функции из стандартных или созданных их разработчиком библиотек динамической компоновки, то есть имеют как полный доступ к компьютеру сервера Notes, так и возможность передать информацию с этого компьютера на другие компьютеры. Такие агенты "в руках добропорядочного разработчика" могут выполнять сложные и "полезные" для вашей организации операции, а "в руках недобропорядочного разработчика" потенциально способны "нанести вред" вашей организации. Вопрос о "полезности" или "вредности"
конкретного агента может быть решен администратором только посредством анализа всех его исходных текстов. В Notes версий 4.х каждый агент (как общий, так и личный) автоматически "подписывается" разработчиком, когда тот сохраняет агента в базе. А у администратора имеется возможность разрешать или запрещать запуск на сервере агентов, созданных конкретными разработчиками. В ситуации "полного недоверия" администратор может разрешить запуск на сервере только "своих собственных" агентов, а от разработчиков требовать предоставления созданных ими агентов, и, после анализа их исходных текстов, "пересохранять агентов под своим ID-файлом, за своей подписью".
Рис. 3.6 Определение условий запуска агентов
Когда наступает условие для запуска агента, задача Agent Manager выполняет следующее:
1. Проверяет, кем "подписан" агент. Обычно агент подписан тем разработчиком, который последним сохранил этого агента. Если агент "не подписан", задача не будет его выполнять.
2. Проверяет информацию из документа Server в общей адресной книге, чтобы определить, разрешил ли администратор сервера запускать на нем личных, "ограниченных по возможностям" (restricted) и "неограниченных по возможностям" (unrestricted) агентов, созданных этим разработчиком (поля с метками Run personal agents:,
Run restricted LotusScript agents: и Run unrestricted LotusScript agents: на Рис. 3.7).
3. Если агент написан на языке LotusScript, проверяет по коду агента, является ли он "ограниченным" или "неограниченным".
4. Если выполнение разрешено, начинает выполнение агента.
Рис. 3.7 Фрагмент документа Server, содержащий информацию, касающуюся выполнения агентов задачей Agent Manager
Если поле с меткой Run personal agents: пусто, задача Agent Manager будет выполнять в базах на сервере личных агентов, созданных любыми пользователями. Если поле с меткой Run restricted LotusScript agents: пусто, задача Agent Manager не будет выполнять ничьих агентов с ограниченными возможностями, написанных на языке LotusScript. Аналогично, если поле с меткой Run unrestricted LotusScript agents: пусто, задача не будет выполнять ничьих агентов с неограниченными возможностями, написанных на языке LotusScript. Для простоты управления запуском агентов администратору можно порекомендовать создать в общей адресной книге группы с именами наподобие RestrictedAgents, UnrestrictedAgents
и, если привилегии на запуск личных агентов предоставляются не всем пользователям, то и PersonalAgents, включить в соответствующие поля в документе Server только названия групп и в дальнейшем манипулировать составом этих групп.
Кроме ограничений на возможность запуска агентов, на работу задачи Agent Manager оказывают влияние значения из следующих полей в документе Server.
Refresh agent cache Кэш задачи Agent Manager содержит список агентов, "запланированных" для выполнения в течении текущих суток. В данном поле дается время, когда задача должна обновлять список агентов, запланированных для выполнения в течение суток.
Daytime and Nighttime
Эти поля "разбивают" рабочий день на два отрезка - "дневное" и "ночное" время. По умолчанию дневное время с 8 утра до 8 вечера, а ночное - с 8 вечера до 8 утра. Для каждого отрезка времени для Agent Manager выделяется то или иное количество ресурсов, обычно меньшее в дневное время и относительно большее в ночное время. Отрезки не должны пересекаться. Во время суток, не принадлежащее ни к дневному, ни к ночному отрезкам, задача вообще не будет выполнять никаких агентов.
Max concurrent agents Только один агент может выполняться в базе данных в одно и то же время, но агенты в разных базах данных на том же самом сервере могут выполняться одновременно, однако в количестве не большем, чем определено в этом поле. Значение по умолчанию - 1 для дневного времени и 2 для ночного времени. Согласно указанному вами значению основная задача Agent Manager запускает соответствующее число своих подзадач, которые отображаются по команде Show Task как Agent Manager Executive '1': статус
, Agent Manager Executive '2': статус
... Каждая из этих подзадач одновременно может исполнять только одного агента. Количество этих подзадач обычно различно на дневном и ночном отрезках времени.
Maximum LotusScript execution time
Эти поля ограничивают время, отводимое на выполнение одного агента, написанного на языке LotusScript, на дневном и ночном отрезках времени. Если такой агент не успевает завершиться за заданное время, то Agent Manager "снимает"
его. Данная возможность введена, в частности, в целях предотвращения потери производительности сервера из-за зацикливания "недостаточно отлаженных агентов".
Max % busy before delay Эти поля, если "рассматривать осреднение по времени", определяют в процентах количество процессорного времени, отводимого задаче Agent Manager на дневном и ночном отрезках времени. Значение по умолчанию - 25 % для дневного и 35 % для ночного отрезка. Позволяет не допустить захвата всех ресурсов сервера на выполнение агентов - есть и другие серверные задачи, которые должны выполняться параллельно.
Возникающие при работе события Agent Manager заносит в базу "Протокол работы сервера".
08.09.96 12:02:49 AMgr: Start executing agent 'UpdateMailIn' in 'BASES400\Secretariat\ITSNMLST.NSF' by Executive '1' (агент выполнен нормально)
08.09.96 12:02:53 AMgr: Start executing agent 'UpdateMailIn' in 'BASES400\Secretariat\ITSSecrt.NSF' by Executive '1'
08.09.96 12:02:54 AMgr: Agent ('UpdateMailIn' in 'BASES400\Secretariat\ITSSecrt.NSF') printing: Найдено - 9 док-в. (агент выполнен нормально)
08.09.96 12:02:56 AMgr: Start executing agent 'UpdateMailIn' in 'BASES400\Secretariat\ITSsbd1.NSF' by Executive '1' (агент выполнен нормально)
08.09.96 12:03:41 AMgr: Agent 'Mail Event Log' in 'NOTES400\STUD\DLibR4.nsf' did not process all documents successfully. Check the Agent Log for more information: LotusScript did not run to completion. (ошибка при выполнении агента)
08.09.96 12:03:41 AMgr: Error executing agent 'UpdateMailIn' in 'BASES400\Secretariat\ITSNMLST.NSF', agent will be removed from current schedule: Document has been modified or corrupted since signed! (data) (ошибка при выполнении агента)
Кроме того, на работу Agent Manager оказывают влияние следующие переменные из файла NOTES.INI:
· AMgr_NewMailEventDelay = значение Задает время задержки (в минутах) перед выполнением агента, запускаемого по факту доставки почты (от момента обнаружения события доставки почты до выполнения агента). Значение по умолчанию 1.
· AMgr_NewMailAgentMinInterval = значение Задает минимальное время (в минутах), которое должно пройти между последовательными выполнениями одного и того же агента, запускаемого по факту доставки почты. Значение по умолчанию 0.
· AMgr_DocUpdateEventDelay = значение Задает время задержки (в минутах) перед выполнением агента, запускаемого по факту создания нового или изменения существующего документа в базе (от момента обнаружения события изменения документа до выполнения агента). Значение по умолчанию 5.
· AMgr_DocUpdateAgentMinInterval = значение Задает минимальное время (в минутах), которое должно пройти между выполнением агента, запускаемого по факту изменения документа в базе, на одном и том же документе. Значение по умолчанию 30.
· AMgr_WeekendDays = день1, день2, … Когда агент запускается по расписанию, для него в окне Schedule доступна опция Don't run on weekends, запрещающая выполнение этого агента по выходным дням. Данный параметр содержит список дней, которые считаются выходными (воскресенье = 1, понедельник = 2, …, суббота = 7). Значение по умолчанию для уик-энда - суббота (7) и воскресенье (1).
Рис. 3.8 "Ежедневный" агент не выполняется по выходным дням
· Log_AgentManager = значение Значение 1 требует протоколировать (на консоли сервера и в базе "Протокол работы сервера") факт запуска каждого агента, а значение 0 - не протоколировать.
Отметим еще два момента, касающихся выполнения агентов в базах на сервере.
Во-первых, с версии 4.5 появилась возможность запрещать в конкретной базе выполнение всех общих и личных агентов, запускаемых по расписанию, приходу почты или модификации документа. Для этого в окне свойств базы на закладке Basics необходимо установить опцию Disable background agents for this database.
Во-вторых, все рассмотренное выше касалось запуска агента задачей Agent Manager, но не затрагивало вопроса, какие действия в самой базе может выполнить этот агент. Возможности агента в базе определяются уровнем доступа к ней разработчика этого агента. Так, читатель с правом создания персональных агентов может создать в базе на сервере личного агента, который по расписанию удаляет или модифицирует документы в этой базе, применяя простые действия или @-формулы. Задача Agent Manager будет запускать этого агента, если, например, в документе Server поле Run personal agents пусто. Однако агент не сможет удалить или модифицировать документы в базе, поскольку его прав доступа (читатель) для этого недостаточно.
Серверная задача Billing
Задача Billing предназначена для сбора информации, необходимой для составления счетов за использование серверов Notes. Сервер Notes помещает необходимую для этого информацию в очередь сообщений задачи Billing. Задача Billing периодически опрашивает эту очередь сообщений и заносит необходимую информацию в специальную базу данных или файл.Классы информации, которая должна отслеживаться сервером Notes и затем протоколироваться задачей Billing, перечисляются в переменной BillingClass в файле NOTES.INI. Например, если задано
BillingClass=Session,Database,Document,Replication,Mail,Agent
то требуется отслеживать всю возможную информацию. Рассмотрим возможные классы.
· Session Отслеживаются начало и окончание каждой сессии с сервером составления счетов (сервер, на котором работает задача Billing), включая выполненные за время сессии действия, в частности, редактирование документов или репликации.
· Database Отслеживаются моменты открытия и закрытия баз на сервере составления счетов пользователями и другими серверами, а также продолжительность использования этих баз.
· Document Отслеживаются обращения (для чтения или записи) только к некоторым документам в базах данных на сервере составления счетов. Такие документы должны содержать поля с именами $ChargeRead и (или) $ChargeWrite
типа Number (Currency) со значением, по смыслу интерпретируемым как "цена обращения к документу".
· Replication
Отслеживается репликации, инициированные сервером составления счетов с другими серверами или станциями пользователей с данным сервером.
· Mail Отслеживается факты отправления почтовых сообщений с сервера составления счетов на другие серверы (включая имена отправителя и получателя).
· Agent
Отслеживается время, затраченное сервером составления отчетов на выполнение агентов.
Переменная BillingAddinRuntime=n (из файла NOTES.INI) задает количество секунд, отводимых задаче Billing на извлечение сообщений из очереди и запись информации о них в базу или файл. Значение по умолчанию 10 секунд. По истечении этого "кванта времени" задача приостанавливает свою работу, даже если в очереди остались необработанные сообщения.
Переменная BillingAddinWakeup=n
(из файла NOTES.INI) задает интервал в секундах, с которым задача Billing повторят процесс извлечения сообщений из очереди и записи информации о них в базу или файл. Значение по умолчанию 60 секунд. Естественно, что значение переменной BillingAddinWakeup должно быть больше, чем значение переменной BillingAddinRuntime.
Задача Billing заносит необходимую информацию в специальную базу данных или файл, в зависимости от того, что вы укажите в качестве значения переменной BillingAddinOutput в файле NOTES.INI. Если BillingAddinOutput=1, информация записывается в базу данных BILLING.NSF, если BillingAddinOutput=8 - в "двоичный" файл BILLING.NBF, если BillingAddinOutput=9 - одновременно и в базу BILLING.NSF, и в файл BILLING.NBF.
Рис. 11.18 База данных BILLING.NSF - информация о почтовых сообщениях, переданных сервером
Файл BILLING.NBF так же автоматически создается, если при запуске задача Billing обнаруживает его отсутствие. Это не текстовый, а "записеориентированный" файл относительно несложной структуры. Каждая его запись содержит свою длину, тип записи и соответствующую типу информацию. Администраторы, заинтересованные в специфических способах представления содержащейся в файле информации, могут разработать для этого собственные программы.
Серверная задача Cataloger
CATALOG Серверная задача Cataloger обновляет содержимое базы CATALOG.NSF ("Каталог баз данных"). По умолчанию задача запускается на сервере в 1:00 ночи. При необходимости всегда может быть запущена командой LOAD CATALOG. Сама же база CATALOG.NSF рассматривается в 4.3.> load catalog
13.08.96 01:00:58 Starting update of database catalog
13.08.96 01:01:48 Updated database DNOTES\dbarhive.nsf in catalog
13.08.96 01:01:53 Updated database FreeDist.nsf in catalog
13.08.96 01:02:08 Updated database Informat.nsf in catalog
13.08.96 01:03:26 Finished updating database catalog
Серверная задача Chronos
CHRONOS В версиях 4.х задача обновляет индексы полнотекстового поиска в тех базах на сервере, для которых задано часовое или ежедневное обновление (см. Рис. 3.4).Команда консоли LOAD CHRONOS HOURLY принудительно запускает задачу и "заставляет" ее выполнить часовые изменения индексов полнотекстового поиска, а команда LOAD CHRONOS DAILY - соответственно ежедневные.
> load chronos hourly
12.08.96 16:57:46 Periodic full text indexer starting, performing hourly full text indexing
…
12.08.96 16:58:00 Periodic full text indexer terminating
В версиях 3.х одноименная задача, кроме того, выполняла часовые, дневные и недельные фоновые макросы в базах на сервере, обрабатывая "базу за базой", и в каждой базе выполняя соответствующие фоновые макросы в "алфавитном" порядке.
Рис. 3.4 Выбор частоты обновления индекса полнотекстового поиска в окне свойств базы
Серверная задача Collect
Задача Collect, подобно задаче Report, предназначена для сбора статистической информации c многих серверов. Однако для этого, в отличие от задачи Report, задачу Collectзагружают только на том сервере, где собирается статистика с других серверов, а не на каждом из серверов получения статистики. В этом и состоит преимущество задачи Collect
перед Report. Но в то же время задача Collect, в отличие от Report, не может создавать сводные статистические отчеты и статистику о базах данных на серверах. Если последнее необходимо, следует использовать задачу Report. Обратите внимание, что использовать обе задачи совместно нельзя - либо только Report, либо только Collect.
Когда задача Collect запускается на сервере в первый раз (например, по команде консоли Load Collect), она автоматически создает свою базу настроек COLLECT4.NSF. Поскольку эта база данных представляет собой "усеченный вариант" базы EVENTS4.NSF, мы не будем ее специально обсуждать. Для сбора статистики от задачи Collect обычно используется уже знакомая вам база STATREP.NSF.
Серверная задача Database Compactor
COMPACT Серверная задача Database Compactor "уплотняет" базы, находящиеся на сервере. При этом в базе освобождается неиспользуемое дисковое пространство, появившееся после удаления или изменения документов и присоединенных файлов.
Рис. 3.9 Окно свойств базы на закладке Information - в этой базе 40% неиспользуемого пространства
В процессе уплотнения базы задача Database Compactor создает временную копию базы и "переписывает" в эту временную копию "документ за документом" информацию из исходной базы. Если процесс "перезаписи" завершился успешно, исходная база удаляется, а временная копия "получает имя" исходной базы. Поэтому на сервере на том же диске, где расположена уплотняемая база, должно быть достаточно свободного пространства, чтобы сохранить эту временную копию.
Команда консоли LOAD COMPACT уплотняет все базы на сервере. В общем случае рекомендуется раз в месяц уплотнять все базы на сервере. Команда консоли LOAD COMPACT имя_каталога\ уплотняет все базы на сервере в указанном каталоге, а команда LOAD COMPACT имя_базы уплотняет только указанную базу.
> load compact pubnames.ntf
12.08.96 17:57:22 Compacting database pubnames.ntf (Public Address Book)
12.08.96 17:57:22 Finished compacting pubnames.ntf, 0K bytes recovered (0%)
12.08.96 17:57:22 Database compact process shutdown
> load compact mail\
12.08.96 17:58:29 Compacting database mail\asavelye.nsf (Alexander M. Savelyev)
12.08.96 17:58:56 Finished compacting mail\asavelye.nsf, 176K bytes recovered (7%)
12.08.96 17:58:56 Compacting database mail\DIVANOV.NSF (Denis U. Ivanov)
12.08.96 17:59:20 Finished compacting mail\DIVANOV.NSF, 144K bytes recovered (8%)
12.08.96 17:59:20 Compacting database mail\niontsev.nsf (Nikolay N. Iontsev)
12.08.96 18:00:09 Error Compacting database mail\niontsev.nsf: Insufficient disk space
12.08.96 18:00:25 Compacting database mail\ppuchkov.nsf (Pavel A. Puchkov)
12.08.96 18:00:25 Error Compacting database mail\ppuchkov.nsf: Database is currently in use by you or another user
12.08.96 18:00:25 Compacting database mail\Shared.nsf (Object Store for NotesSrv400)
12.08.96 18:00:25 Error Compacting database mail\Shared.nsf: Database is currently in use by you or another user
12.08.96 18:00:25 Compacting database mail\SMOISEEV.NSF (Serge L. Moiseev)
12.08.96 18:00:51 Finished compacting mail\SMOISEEV.NSF, 128K bytes recovered (5%)
12.08.96 18:01:16 Database compact process shutdown
Команда консоли с параметром -S и заданным числовым значением, например, LOAD COMPACT -S 10 , уплотняет только те базы, в которых >= 10% пространства не используется. В общем случае рекомендуется запускать эту задачу для баз, имеющих более 10% неиспользуемого пространства, ежедневно ночью по расписанию.
Кроме того, в версии 4.х, "встретив" базу данных с расширением .NSF в формате версии 3.х, задача COMPACT на сервере версии 4.х преобразует ее в формат версии 4.х. Если требуется предотвратить такое преобразование, скопируйте базу данных средствами Notes, дав ей расширение .NS3.
Если необходимо выполнить преобразование базы формата 4.х в формат версий 3.х, можно для конкретной базы воспользоваться командой LOAD COMPACT имя_базы -R , а для всех баз на сервере - командой LOAD COMPACT -R.
Учтите, что если база данных используется другой серверной задачей, она не может быть уплотнена задачей COMPACT. Так, при работе сервера Notes постоянно открыты, а потому не могут быть уплотнены некоторые системные базы данных, в частности LOG.NSF, NAMES.NSF, STATREP.NSF... Чтобы уплотнить их, необходимо остановить сервер, и воспользоваться командой
icompact names.nsf (OS/2)
ncompact names.nsf (Windows NT)
compact names.nsf (UNIX®)
На запрос введите пароль. Затем запустите сервер.
Отметим, что серверная задача Router сама осуществляет ежедневное сжатие "своей базы" MAIL.BOX. См. также переменную MailCompactDisabled.
11.08.96 04:00:03 Router: Shutdown is in progress
11.08.96 04:00:03 Router: Beginning mailbox file compaction
11.08.96 04:00:07 Router: Completed mailbox file compaction
Выполнять уплотнение баз на сервере удобно из окна Server Administration, выбрав в нем "несущий" уплотняемые базы сервер, нажав кнопку-пиктограмму Databases и выбрав во всплывающем меню пункт Database Compact. В появившемся окне можно выбрать базу данных или каталог, и нажать кнопку Compact для запуска задачи на сервере. Обратите внимание, что при этом можно запросить, чтобы при уплотнении базы "не копировались" индексы видов - они будут заново перестроены при открытии базы после уплотнения. Отметим, что это наиболее простой способ для массового удаления индексов видов в базах на сервере.
Рис. 3.10 Уплотнение базы с одновременным "разрушением" индексов видов
Наконец, всякий пользователь, имеющий к расположенной на сервере базе доступ менеджера или дизайнера, может инициировать запуск задачи COMPACT на сервере для этой базы кнопкой Compact из окна свойств базы (Рис. 3.9).
Серверная задача Database fixup
FIXUP Серверная задача Database fixup проверяет находящиеся на сервере базы данных на наличие в них "поврежденных" видов, папок и документов и удаляет те виды, папки и документы, в которых были обнаружены повреждения.Наиболее часто повреждение базы данных случается:
· при неправильном завершении операционной системы (аппаратная перезагрузка компьютера, сбой питания, крах операционной системы или иные неподходящие процедуры ее закрытия),
· при принудительном завершении ("снятии") сервера Notes средствами операционной системы,
· из-за неправильной работы с базой данных из программы, использующей Notes API.
Во время своей работы сервер Notes открывает запрашиваемые пользователями базы данных и в течение некоторого времени поддерживает их в открытом состоянии. Некоторые системные базы данных, например, LOG.NSF, MAIL.BOX или NAMES.NSF, открываются при старте сервера и остаются в открытом состоянии до его завершения. При штатном завершении сервера (командой консоли Quit или Exit) последний "закроет" все открытые им базы данных. Однако при нештатном завершении сервера некоторые из баз могут остаться в незакрытом состоянии.
Когда вы снова запускаете сервер, он самостоятельно запускает задачу FIXUP в фоновом режиме. Задача FIXUP
прежде всего обрабатывает базу "Протокол работы сервера" (LOG.NSF), чтобы в нее можно было заносить информацию о возможных последующих обнаруженных повреждениях и выполненных "исправлениях". Затем задача FIXUP
обрабатывает "незакрытые" базы данных. Для каждой "незакрытой" базы она:
· проверяет каждое поле в каждом документе на наличие повреждений;
· удаляет поврежденные документы, но так, что эти удаления не повлекут удалений соответствующих документов в других репликах данной базы.
Если задача FIXUP "не успеет" обработать "незакрытые" базы до того, как запустится сервер, а пользователи попытаются открыть такую базу, они получат сообщение "This database cannot be opened because a consistency check of it is in progress."
При старте сервера может быть запущено несколько параллельно работающих задач FIXUP, чтобы сократить общее время обработки поврежденных баз. По умолчанию при старте запускается до двух задач FIXUP в расчете на каждый имеющийся на сервере процессор. Максимальное количество одновременно запускаемых при старте сервера задач FIXUP может задаваться переменной Fixup_Tasks в NOTES.INI. Фактическое число выполненных задач обычно меньше заданного значения Fixup_Tasks. Например, если Fixup_Tasks = 4, но только одной базе данных имеются повреждения, выполнится только одна задача FIXUP.
Обратите внимание на следующие моменты. Во-первых, при автоматическом запуске задача FIXUP не выполняет проверку поврежденных видов и папок в базах. Во-вторых, база данных, которая повреждена, но "корректно закрыта", вообще не обрабатывается при автоматическом запуске задачи FIXUP.
В таких случаях администратору приходится запускать задачу FIXUP "вручную". Поводом для этого может послужить получение пользователем сообщения о повреждении базы, обнаружение пользователем некорректной информации в виде базы (невозможно открыть вид, в колонках вида "непонятные" символы, информация в документе и в виде не синхронна, в базе нет документов, представленных в виде) или обнаружение администратором соответствующие сообщения в базе "Протокол работы сервера" (LOG.NSF). Приведем некоторые сообщения, появляющиеся в LOG.NSF и свидетельствующие о наличии повреждений в базах:
· Поврежденный документ
· "Document NT
· " Document is damaged or obsolete (unrecognized data type)"
· "Document is damaged or obsolete (unrecognized field)"
· Некорректно (в "физическом" смысле) удаленный документ
· "Document NT
· Разрушенный вид
· "Page format is incorrect"
· "Invalid CNO vector - position == 0"
· "Container integrity has been lost - rebuild".
При запуске "вручную" FIXUP способна обрабатывать не только поврежденные документы, но и поврежденные виды или папки.
Формат для запуска "вручную": LOAD FIXUP [имя_базы] [-L] [-V] [-I] [-N] .
· Имя_базы
- необязательный параметр. Он определяет имя базы данных, которую необходимо обработать. Если вы не указали базу данных, FIXUP обрабатывает все базы данных на сервере.
· -L требует протоколировать информацию о каждой базе, обработанной FIXUP, даже если в базе отсутствуют повреждения. Без этого параметра FIXUP протоколирует только обнаруженные и "исправленные" ею повреждения.
· -V
"запрещает" задаче FIXUP проверять и "исправлять" виды (но не папки) - проверяются документы и папки. Это сокращает общее время работы программы.
· -I "заставляет" задачу FIXUP проверять только те документы, которые изменились с момента предшествующего запуска задачи.
· -N "запрещает" задаче FIXUP удалять поврежденные документы - будет происходить лишь обнаружение повреждений, но "без грубого лечения посредством удаления всего испорченного".
FIXUP не может обрабатывать уже открытые базы данных, и базы данных не могут быть открыты, когда FIXUP "работает" на них. Учтите, что системные базы данных (например, LOG.NSF, MAIL.BOX или NAMES.NSF) при работе сервера всегда открыты.
При желании можно запускать задачу FIXUP по расписанию. Общая рекомендация в этом случае - один раз в неделю в "не пиковые" часы.
Остается рассмотреть вопрос о последствиях применения задачи FIXUP. Если задача удаляет поврежденный индекс вида, "ничего страшного" не происходит. Этот индекс вида будет построен сервером заново - при попытке пользователя открыть вид, "ночном" выполнении задачи UPDALL
или в иных ситуациях. Если же задача FIXUP удаляет поврежденный документ, этот документ "не восстановится автоматически". Для его восстановления необходимо иметь либо резервную копию базы, выполненную средствами операционной системы, либо реплику этой базы на другом сервере Notes. В первом случае придется со станции вручную перенести необходимые документы через буфер обмена из резервной копии в восстанавливаемую базу. Во втором случае поможет механизм репликаций. Задача FIXUP всегда удаляет поврежденный документ "без следов", так что при репликации он не влечет удаления соответствующего документа в реплике базы на другом сервере. Зато "нормальный" документ из реплики на другом сервере при репликации должен добавляться в восстанавливаемую реплику, как новый документ. Однако при этом возможны некоторые нюансы, о которых вы узнаете в главе 6.
Серверная задача Designer
DESIGN Серверная задача Designer приводит все базы на сервере, для которых указан шаблон (Template name:) и запрошено обновление дизайна (Inherit design from template), в соответствие с указанным шаблоном.
Рис. 3.11 База NAMES.NSF наследует дизайн с шаблона с именем StdR4PublicAddressBook
Рис. 3.12 База PUBNAMES.NTF является шаблоном с именем StdR4PublicAddressBook
При обновлении элементов дизайна (форм, субформ, видов, навигаторов, агентов) действуют следующие соглашения. Если в шаблоне появился новый элемент дизайна, он добавляется в базу, наследующую дизайн с этого шаблона. Если элемент дизайна в шаблоне был изменен, он заменяет "более старый" элемент дизайна в базе, наследующей дизайн. Если элемент дизайна в шаблоне был удален, он вызывает удаление соответствующего элемента в базе, наследующей дизайн.
Учтите, что возможно также наследование только отдельных элементов дизайна (форм, субформ, видов…), причем каждый из них может наследоваться со своего шаблона (Рис. 3.13). Возможно введение запрета на изменение отдельных элементов дизайна - опция Do not allow design refresh/replace to modify. Наконец, шаблон и сам может наследовать отдельные элементы дизайна из других шаблонов, причем в этом случае, чтобы обновления произошли "по всей цепочке наследования", может потребоваться не один запуск задачи Designer.
Рис. 3.13 Элемент дизайна, например, форма, наследуется из шаблона
Обычно задача DESIGN по умолчанию запускается на сервере в 1:00 ночи. При необходимости ее можно запустить с консоли командой LOAD DESIGN.
13.08.96 01:00:39 Database Designer started
. . . Обновление элементов дизайна
13.08.96 01:02:25 Updating 'Periodic Archive' into database 'Alexander M. Savelyev' from template 'Mail (R4)'
13.08.96 01:02:36 Updating '$HTTPServerFormSubForm' into database 'InterTrustCorp's External N&A' from template 'Public Address Book'
13.08.96 01:02:38 Updating '$MTAConnectionFormSubform' into database 'InterTrustCorp's External N&A' from template 'Public Address Book'
13.08.96 01:02:39 Updating '$SMTPServerFormSubForm' into database 'InterTrustCorp's External N&A' from template 'Public Address Book'
13.08.96 01:02:39 Updating '$X400ConnectionFormSubform1' into database 'InterTrustCorp's External N&A' from template 'Public Address Book'
13.08.96 01:02:40 Adding '$X400ServerFormSubForm' to database 'InterTrustCorp's External N&A' from template 'Public Address Book'
13.08.96 01:02:43 Updating '$HTTPServerFormSubForm' into database 'InterTrustCorp's AddressBook' from template 'Public Address Book'
13.08.96 01:02:44 Updating '$MTAConnectionFormSubform' into database 'InterTrustCorp's AddressBook' from template 'Public Address Book'
13.08.96 01:02:44 Updating '$SMTPServerFormSubForm' into database 'InterTrustCorp's AddressBook' from template 'Public Address Book'
13.08.96 01:02:45 Updating '$X400ConnectionFormSubform1' into database 'InterTrustCorp's AddressBook' from template 'Public Address Book'
13.08.96 01:02:45 Adding '$X400ServerFormSubForm' to database 'InterTrustCorp's AddressBook' from template 'Public Address Book'
. . . Шаблон для базы задан, но отсутствует
13.08.96 01:03:12 Warning: Cannot locate design note 'Archive Selected Documents' in 'Shared Template Components (R4)' template
13.08.96 01:03:40 Warning: Cannot locate design template 'NSVerSoft' used by 'THE VIEW On Line'
. . . Два базы-шаблона имеют одинаковое имя шаблона
13.08.96 01:03:17 WARNING: Both lbuspart\PARTSUP4.NSF and lbuspart\PARTFOR.NSF claim to be Design Template 'partsup4template'
. . .
13.08.96 01:03:53 Database Designer shutdown
Задача DESIGN должна запускаться и "успевать" завершиться до запуска задачи UPDALL, поскольку DESIGN может изменить некоторые виды, а после этого UPDALL должна перестроить связанные с измененными видами индексы. Если изменения дизайна производятся в шаблонах на одном сервере, и должны "распространиться на базы данных" на других серверах, на этих серверах должны быть реплики шаблонов, ежедневные репликации шаблонов должны завершиться до запуска на каждом из серверов задачи DESIGN, а последняя - до запуска UPDALL.
Серверная задача Mail Router - маршрутизатор почты
ROUTER Mаршрутизатор почты автоматически стартует при запуске сервера. Периодически анализирует базу данных MAIL.BOX на предмет появления новой почты, и, обнаружив почту, передает ее другим серверам (в базу MAIL.BOX) или перемещает в почтовые ящики пользователей.Более подробно эта задача будет рассмотрена в главе 7.
Серверная задача Replicator - репликатор баз данных
REPLICA Репликатор автоматически стартует при запуске сервера. Выполняет репликации баз данных между серверами. Задача получает запросы на выполнение репликаций, запланированных в документах Connection из общей адресной книги. Сервер поддерживает очередь запросов, а репликотор исполняет запросы из очереди, но только по одному одновременно. В Notes версий 4.х может одновременно выполняться несколько репликаторов. Для обработки команд консоли Push, Pullи Replicate
запускается отдельный репликатор, который завершается по выполнении команды.
Более подробно эта задача будет рассмотрена в главе 6.
Серверная задача Statistics
STATLOG Задача обновляет информацию об использовании баз данных, находящихся на данном сервере, как в базе "Протокол работы сервера" (LOG.NSF), так и в самих базах (окно User Activity). По умолчанию запускается в 5 часов утра.Информация об использовании баз заносится задачей Statistics в базу LOG.NSF "безоговорочно". Получить эту информацию можно в следующих видах базы LOG.NSF.
· Database - Usage Информация о каждом использовании каждой базы данных пользователями и серверами. Документы Session содержат количество документов, прочитанных и записанных в сеансе. Документы Activity показывают количество времени, в течение которого база данных использовалась (включая использование в уровне вида, когда никакие документы не были открыты) и количество документов, прочитанных и записанных за день, неделю, месяц и с момента создания.
· Database - Sizes Имеется столбец, дающий количество использований базы в течение последней недели.
· Usage - By User Для каждого сеанса пользователя или сервера можно получить информацию о документах, использованных в этом сеансе.
Если база данных активно используется, имеет смысл создать ее дополнительную реплику. Если же с базой никто не работает, вероятно, ее следует удалить, чтобы освободить пространство на диске.
С другой стороны, в каждой базе данных из диалогового окна User Activity обычно можно получить информацию об использовании только этой базы. Это окно "вызывается" из окна свойств базы кнопкой User Activity на закладке Information. Управление же окном User Activity доступно только менеджеру базы. Выбором опции Record Activity менеджер "требует" сбора информации об использовании базы. Опция Activity is Confidential "делает" информацию об использовании базы доступной только лицам, имеющим к этой базе доступ менеджера или дизайнера.
Рис. 3.16 Окно User Activity
Если опция Record Activity была "включена" для базы, задача Statlog будет обновлять информацию об использовании этой базы непосредственно в самой базе, если же опция "выключена" - не будет обновлять. Однако сбор информации об использовании непосредственно в базе "добавляет" 64Кб к размеру этой базы.
По умолчанию задача Statlog, обнаружив на сервере базу, для которой менеджер еще ни разу не изменял опцию Record Activity, "включит" эту опцию и тем самым активизирует сбор информации. Чтобы сохранять дисковое пространство, администратор может добавить в файл NOTES.INI переменную No_Force_Activity_Logging=1. В этом случае задача Statlog, обнаружив базу, для которой менеджер еще ни разу не изменял опцию Record Activity, "выключит" эту опцию и тем самым "запретит" сбор информации. Однако "при любом раскладе" менеджер базы может затем явно "включить или выключить" сбор информации.
Серверная задача Stats
STATS Задача запускается при старте сервера, а ее функция состоит в "ответе" на команду консоли Show Statistics. Может оказаться полезной команда Show Stat >имя_файла, которая выводит статистику не на консоль, а в текстовый файл в каталоге программ Notes.Серверная задача WEB Retriever
WEB Эта серверная задача позволяет клиентам Notes со своих станций через сервер Notes получать доступ к информации на HTTP-серверах. Клиенты Notes получают доступ к серверу Notes по любому доступному им протоколу. Сервер Notes, на котором запущена задача WEB, использует протокол HTTP поверх TCP/IP для доступа к HTTP-серверам.
Рис. 3.23 Клиенты получают доступ к HTTP-серверам в Internet через сервер Notes
При первом запуске на сервере задачи WEB (командой Load Web) она создает по шаблону Web Navigator 4.1 (web41.ntf)
или Server Web Navigator 4.5 (pubweb45.ntf) базу данных Web Navigator - web.nsf, а так же выполняет некоторые дополнительные настройки. Пользователям остается добавить эту базу в свое рабочее пространство, выполнить необходимые настройки в документе Location
и далее просто работать с базой. Для клиента версии 4.5 в документе Location
в поле с меткой Internet brouser: выбирают Notes, в поле Retrieve/open pages: - from InterNotes server, а в поле InterNotes server: задают полное имя сервера, на котором находится база Web Navigator и функционирует задача WEB. Обратите внимание, что выбор в поле с меткой Retrieve/open pages: значения from Notes workstation предполагает, что станция имеет собственный доступ к Internet, и означает, что станция будет обращаться к HTTP-серверам самостоятельно, никак не используя при этом серверную задачу WEB.
Рис. 3.24 Настройки в документе Location на станции пользователя
Когда пользователь Notes
из базы данных Web Navigator делает запрос на некоторую HTML-страницу, явно или "переходом по ссылке" указав ее URL (унифицированный локатор ресурса), прежде всего проверяется, не существует ли уже в базе Web Navigator соответствующий этой странице документ. Если существует, этот документ открывается для показа пользователю. Если не существует, "первый свободный или очередной порожденный" процесс Web Retriever задачи WEB
обращается к соответствующему HTTP-серверу, целиком "скачивает" с него HTML-страницу, преобразует ее в документ в формате Notes и помещает в базу Web Navigator. После этого документ - образ страницы - предъявляется пользователю.
Рис. 3.25 Принцип работы задачи WEB
Для функционирования задачи WEB необходимо, чтобы на сервере Notes был настроен порт TCPIP, а компьютер сервера Notes
поддерживал протокол TCP/IP и имел доступ к Internet
"напрямую" или через Proxy-сервер. Если сервер Notes получает доступ к Internet через Proxy-сервер, в его документе Server в общей адресной книге должна быть заполнена секция Proxy Configuration. В полях этой секции указываются IP-адреса и номера портов вашего Proxy-сервера. Причем сделать это рекомендуется до первого запуска задачи WEB. Если же сервер Notes имеет доступ к Internet
"напрямую", секция Proxy Configuration должна быть "пуста".
Рис. 3.26 Пример заполнения секции Proxy Configuration в документе Server
Рис. 3.27 Пример заполнения секции Web Retriever Administration в документе Server
Общие настройки задачи в версии 4.5 "вынесены" в секцию Web Retriever Administration документа Server
в общей адресной книге. Поле с меткой Web Navigator database: задает задаче WEB местоположение базы Web Navigator. Поле Services: содержит список сервисов Internet, используемых задачей WEB. Поле Concurrent retrievers: определяет максимальное количество процессов для "скачивания страниц", которые будут запускаться задачей WEB. Имея только dialup-выход в Internet, целесообразно указать не более 4-5 процессов. Поле SMTP Domain: заполняется тогда, когда в домене имеется сервер Notes c установленным SMTP MTA. Оно должно содержать имя домена Internet (за неимением укажите хост-имя компьютера c установленным SMTP MTA), через который отправляется и в который принимается почта агентом SMTP MTA. Это позволит выполнять отправку почты "по ссылкам" непосредственно из базы Web Navigator. Поля с метками Allow access...: и Deny access...: используются для ограничения доступа к HTTP-серверам.
Дополнительные настройки для задачи WEB имеются в документе Web Navigator Administration, хранящемся в самой базе Web Navigator. Менеджер базы Web Navigator получит доступ к этому документу, открыв вид All Documents и выбрав в меню Actions - Administration. В документе имеется возможность ограничить максимальный размер базы (Maximum database size:), выбрать сохранение информации об тех, кто инициировал процессы "скачивания страниц" (Save author Information:) и сохранение HTML-текста в документе (Save HTML in Note?). Остальные поля, а так же присутствующие на панели документа кнопки, связаны с настройкой имеющихся в базе агентов, один из которых "занимается" очисткой базы от устаревших документов, а второй - периодическим приведением имеющихся в базе документов в соответствие с "породившими" их страницами на HTTP-серверах.
Рис. 3. 28 Пример документа Web Navigator Administration (версия 4.5)
Отметим, что в версиях Notes до 4.5 практически все аналогичные настройки были сосредоточены только в документе Web Navigator Administration, в частности:
· Maximum concurent users: - максимальное количество процессов Web Retriever, одновременно порождаемых на сервере для "скачивания" страниц по запросам пользователей.
· Save Author Information: - если выбрано Yes, в каждый документ в базе Web Navigator задача WEB будет добавлять поле $Authors, содержащее имя пользователя, инициировавшего получение данной страницы.
· Allow Access: - список HTTP-серверов, к которым разрешен доступ, или *, если доступны любые HTTP-серверы.
· Deny Access: - список HTTP-серверов, к которым запрещен доступ, или "пусто", если запретов нет.
Рис. 3.29 Пример документа Web Navigator Administration (версия 4.11a)
Для работы с задачей WEB применяются следующие команды:
· Load Web - запуск задачи,
· Tell Web HELP
- получение подсказки,
· Tell Web QUIT
- завершение задачи,
· Tell Web REFRESH
- чтобы изменения настроек в документе Administration "вступили в силу" без перезапуска задачи WEB.
Отметим, что процесс Web Retriver в версиях Notes до 4.11a включительно, получая HTML-страницу в кодировке Windows 1251 с "русскоязычного" HTTP-сервера, конвертирует ее в документ Notes с "однобайтовой" кодировкой для русских букв. Поэтому, чтобы "увидеть" в таких документах русские буквы, а не символы "Ђ", приходилось либо временно подменять файлы перекодировки на клиенте Notes, заменяя l_cpwin.cls, в котором должна находиться таблица l_cp1251.cls, на l_cp1252.cls, либо использовать cls-файлы, модифицированные фирмой Viaduk Info (Киев).
В Notes версии 4.5 эта проблема
(и аналогичная при использовании расположенной на станции базы Web Navigator) решается добавлением в файл NOTES.INI сервера переменной WWWDSP_Codepage со значением 81 для HTML-страниц в кодировке Windows 1251
или значением 3308 для HTML-страниц в кодировке KOI8. Найти описание этой переменной можно в базе данных Lotus Notes 4.5 Release Notes.
Автор далек от встречающегося иногда в материалах рекламного характера излишнего "восхваления достоинств" задачи Web, но считает, что эта задача имеет полезную сферу применения в ситуациях, которые кратко можно обрисовать словами "ограниченные возможности доступа к Internet, безопасность, автоматическое обновление избранных страниц с конкретных HTTP-серверов".
Серверные задачи Report, Event, Collect и Billing
REPORT, EVENT, COLLECT, BILLINGЛюбая из этих задач, если используется, обычно функционирует на сервере постоянно, запускаясь при старте сервера и завершаясь при его останове. Задача Report генерирует статистические отчеты о работе сервера. Задача Event отслеживает возникающие при работе сервера события и, если указано, протоколирует их или доставляет по назначению. Задача Collect появилась в версии 4.5 и может рассматриваться как альтернатива задаче Report. Задача Billing, также появившаяся в версии 4.5, предназначена для сбора информации, необходимой для составления всевозможных отчетов и счетов, связанных с использованием серверов.
Более подробно эти задачи рассматриваются в главе 11.
Серверные задачи Update (Indexer)
UPDATE и UPDALL Серверные задачи Update (Indexer) и Updall занимаются поддержкой и обновлением индексов видов и индексов полнотекстового поиска в базах данных. Они также восстанавливают удаленные индексы видов и полнотекстового поиска.Индекс вида (не путайте с индексом полнотекстового поиска) хранится в самой базе и необходим для того, чтобы станция Notes могла оперативно предъявлять пользователю содержимое вида - оно формируется на основе индекса вида в базе. Индекс полнотекстового поиска хранится отдельно от базы, в каталоге, имя которого совпадает с именем базы, а "расширение" равно FT. Индекс полнотекстового поиска необходим, чтобы находить в базе документы с указанными в запросе полнотекстового поиска словами.
Update - оперативное обновление индексов
Серверная задача Update (имя выполняемого файла xUPDATE.exe, где x зависит от платформы, но на консоли представлена под именем Indexer) по умолчанию включена в файл NOTES.INI в список ServerTasks, а потому загружается автоматически при запуске сервера. Update обновляет соответствующие индексы видов в базе данных, когда пользователь или серверная задача, например Replicator, создают, модифицируют или удаляют документы в этой базе. В случае если пользователь или серверная задача обращаются к виду, для которого в базе еще не существует индекса, Update создает индекс этого вида.
Сервер Notes поддерживает очередь запросов на изменение индексов видов в базах данных. Запросы в эту очередь поступают от различных серверных задач, которые создают, модифицируют или удаляют документы в базах. Задача Update опрашивает эту очередь каждые несколько секунд. Как только она находит в очереди запрос, то форсирует изменение тех индексов в заданной базе, которым согласно формуле отбора "принадлежат" эти документы. Если эта база имеет еще и индекс полнотекстового поиска с частотой обновления Immediate
("непосредственно при создании, удалении или модификации документа"), помимо изменения индексов видов задача Update обновляет индекс полнотекстового поиска.
В целях сохранения дискового пространства на сервере задача Update также занимается удалением индексов длительно неиспользуемых видов. Если разработчик базы данных не указал для вида опцию, касающуюся частоты удаления его индекса, т.е. в поле с меткой Discard index: выбрано значение по умолчанию Never ("никогда"), то задача Update удалит индекс этого вида, если он никем не использовался в течение 45 дней.
Рис. 3.14 Выбор частоты удаления индекса вида в окне свойств вида
Можно использовать в NOTES.INI переменную Default_Index_Lifetime_Days=<число дней>, чтобы изменить "время жизни индексов видов по умолчанию". Если же для вида была определена частота удаления индекса (After each use - "после каждого использования" или If inactive for x days - "если не использовался в течении x дней"), задача Update будет удалять индекс с заданной частотой.
В версиях 4.х можно запускать сразу несколько задач Update, устанавливая в NOTES.INI переменную Updaters (число задач Update, запускаемых при старте сервера) или вручную с консоли (командой Load Update). Это может ускорить обновление индексов, но при условии, что компьютер сервера имеет соответствующий запас производительности. Отметим, что команда консоли Tell Update Quit приводит к завершению сразу всех запущенных на сервере задач Update. Однако для нормальной работы сервера необходима хотя бы одна задача Update...
Updall - ежедневное обслуживание индексов
Серверная задача Updall запускается на сервере по умолчанию в 2 часа ночи (это задается в NOTES.INI переменной ServerTasksAt2) и модифицирует во всех базах на этом сервере все индексы видов, к которым обращались по крайней мере раз, и все индексы полнотекстового поиска. Чтобы запретить задаче Updall автоматически модифицировать индексы полнотекстового поиска, можно использовать переменную Update_No_Fulltext в NOTES.INI.
Если вы запускаете Updall вручную или посредством документа Program, вы можете дополнительно задавать аргументы, которые определяют, как задача работает. Формат команды для запуска UpdAll: Load Updall [database] [аргументы]. Аргументы могут быть следующими:
· -V
модифицирует индексы видов, к которым обращались по крайней мере раз, но не модифицирует индексы полнотекстового поиска
· -C
создает все до этого не существовавшие индексы видов и модифицирует индексы полнотекстового поиска
· -R
перестраивает заново все индексы видов, к которым обращались по крайней мере раз, и модифицирует индексы полнотекстового поиска. Но это может потребовать много времени, так что использовать аргумент -R целесообразно только при исправлении поврежденных индексов в базах
· -F
модифицирует индексы полнотекстового поиска, но не модифицирует индексы видов
· -X
перестраивает заново все индексы полнотекстового поиска
· -S
модифицирует индексы полнотекстового поиска, для которых назначена частота обновления Scheduled (по расписанию), Hourly (каждый час) и Immediate (непосредственно).
Рис. 3.15 Установка частоты обновления индекса полнотекстового поиска в окне свойств базы
· -H
модифицирует индексы полнотекстового поиска с частотой обновления Hourly (каждый час)
· database -T viewtitle модифицирует индекс вида viewtitle
в базе database.
Вы можете использовать имя базы данных как дополнительный параметр, причем с опцией -T он всегда необходим. Например, команда Load Updall SALES.NSF -R перестраивает индексы видов и модифицирует индекс полнотекстового поиска только в базе данных SALES.NSF. Чтобы перестроить только один вид в базе, можно воспользоваться командой Load Updall filename -R -T viewname. Однако то же самое часто можно сделать и со станции Notes:
· выбрать вид, который нужно перестроить
· нажать SHIFT+F9, чтобы перестроить только индекс этого вида, или CTRL+SHIFT+F9, чтобы перестроить индексы всех видов в базе.
Отметим, что в версии 4.5 у задачи Updall появились еще два параметра (-A и -B). Они относятся к возможности полнотекстового поиска сразу по многим базам данных и рассматриваются в 10.5.
Серверные задачи, входящие в состав кластера
Кластер из серверов Notes- группа до шести серверов Notes, взаимосвязанных и взаимодействующих между собой, чтобы обеспечить высокую степень доступности, масштабируемости и балансировку загрузки его членов. Серверы кластера по возможности должны располагаться в одной высокоскоростной локальной сети. Обычно на серверах кластера для каждой "критической" для бизнес-процесса базы данных создаются реплики, которые внутри кластера синхронизируются не по расписанию, а по событию модификации документа, "почти в реальном времени".
В состав кластера входят следующие 6 компонент.
1. Серверная задача Cluster Administration Process (CLADMIN) отвечает за корректную работу всех компонент кластера. На сервере-члене кластера эта задача автоматически запускается при старте сервера или в ситуации, когда было обнаружено изменение в составе кластера.
2. Серверная задача Cluster Database Directory Manager (CLDBDIR) занимается поддержкой в актуальном состоянии базы данных Cluster Database Directory (CLDBDIR.NSF). Как только задача "замечает" появление на "своем" сервере новой базы или шаблона, она создает в базе CLDBDIR.NSF соответствующий этой базе или шаблону документ. Документ включает название базы, имя сервера, путь к файлу базы, идентификатор реплики и прочие атрибуты. Этот документ "тут же" передается внутрикластерным репликатором в реплики базы CLDBDIR.NSF на других серверах-членах кластера. Когда же задача "замечает" удаление на "своем" сервере базы или шаблона, она удаляет в базе CLDBDIR.NSF соответствующий удаленной базе или шаблону документ. Кроме того, задача CLDBDIR выполняет операции с базами данных, для которых в базе CLDBDIR.NSF были установлены атрибуты Out of service или Pending delete.
3. Реплика базы данных Cluster Database Directory (CLDBDIR.NSF) находится на каждом сервере-члене кластера. В базе содержится информация обо всех базах данных и шаблонах, имеющихся на серверах-членах кластера. Администратор сервера может в этой базе устанавливать для документов, соответствующих другим базам, атрибуты Out of service или Pending delete.
4. Серверная задача Cluster Manager постоянно "отслеживает" состояние всех серверов-членов кластера. Она поддерживает в своей виртуальной памяти (т.н. кэш кластера) в актуальном состоянии список всех функционирующих в данное время серверов-членов кластера, а также информацию о текущей загрузке каждого сервера-члена. Для получения этой информации задача периодически обменивается с другими серверами-членами кластера специальными сообщениями (cluster probes). Информацию "из кэша кластера" можно получить по команде консоли Show Cluster.
В ситуации, когда данный сервер "перегружен пользователями", задача Cluster Manager по информации из базы CLDBDIR.NSF всегда может определить, какие еще серверы кластера имеют реплику запрошенной очередным пользователем или сервером базы, и, если это возможно, перенаправить запрос на соответствующий сервер-член кластера.
Итак, в функции Cluster Manager
входит:
· периодический контроль в "своей" адресной книге значения поля ClusterName в документах Server и вида Server\Cluster для того, чтобы иметь в актуальном состоянии список серверов, потенциально включенных в данный кластер;
· периодический контроль текущей доступности каждого потенциального члена кластера и его текущей загрузки (cluster probes);
· уведомление "других" администраторов кластера об изменениях состояния данного сервера (ответ на cluster probes);
· переназначение запросов на открытие баз данных на другие серверы кластера на основании текущей загрузки данного и других серверов-членов;
· балансировка нагрузки на серверы-члены кластера;
· генерация событий failover и load balance;
· регистрация событий failover и workload balance в базе - протоколе работы сервера (LOG.NSF).
5. Серверная задача Cluster Replicator (CLREPL) функционирует на каждом сервере-члене кластера и обеспечивает выполнение внутрикластерных репликаций. Внутрикластерный репликатор работает по схеме Push-Only. Он "способен реплицировать" не только список управления доступом, элементы дизайна и документы, но и также частные папки, хранящиеся в базе. Информацию о других серверах-членах кластера, на которых имеется реплика "изменившейся" базы, задача CLREPL получает по информации из базы данных CLDBDIR.NSF. Однако для ускорения работы задача "кэширует" содержимое этой базы в своей виртуальной памяти, обновляя кэш только в тех случаях, когда содержимое базы данных CLDBDIR.NSF изменяется задачей CLDBDIR.
6. Средство анализа кластера - Cluster Analysis tool - встроено в программное обеспечение станции Notes. Оно используется для анализа конфигурации кластера и определения, корректно ли он установлен. "Запускается" средство из окна Server Administration выбором пункта Cluster Analysis в меню кнопки Servers. Результаты работы этого средства помещаются в базу данных Cluster Analysis (CLUSTA4.NSF) в документы формы Cluster Analysis Results.
Более подробно функционирование и настройка кластера, а также действия по добавлению сервера в кластер и "выводу" сервера из кластера рассматриваются в 10.4.
Серверные задачи
Серверная задача - разработанная с учетом специальных соглашений программа для работы на сервере Notes. Соглашения по разработке серверных задач можно найти в документации, входящей в состав Notes API.Серверные задачи бывают двух разновидностей:
· Add-In Program
- обычно запускается при старте сервера и работает до его завершения, получает "задания на выполнение работ" от других задач сервера через очередь событий или посредством циклического опроса чего-либо, "показывает свое состояние" по команде консоли Show Task и обычно может принимать и выполнять собственные команды, передаваемые ей по команде консоли Tell. Типичный пример - маршрутизатор почты Mail Router.
· Main Program
- запускается по расписанию или команде консоли для выполнения какого-либо однократного действия, после чего автоматически завершается. Обычно может "показывать свое состояние" по команде консоли Show Task. Часто может быть запущена и непосредственно из операционной системы, когда сервер Notes остановлен. Типичный пример - "уплотнитель баз" Database Compactor.
Ниже рассматриваются серверные задачи, которые входят в стандартный комплект поставки сервера. Данный материал достаточно важен, поскольку позволяет получить представление о том, как работает сервер Notes.
Схема Pull-Pull
Хотя термин "репликация" (replication) подразумевает двунаправленный процесс обмена изменениями, серверная задача "репликатор" (Replicator), работая по схеме Pull-Pull (pull -"притягивать", а Pull-Pull - "принять-принять"), только принимает измененные документы с другого сервера. Репликация становится двунаправленной, когда репликатор на втором сервере начинает прием изменений с первого, инициировавшего этот процесс сервера. На втором сервере репликатор первого сервера "обслуживается" задачей Database Server, как обычный пользователь. Существенно то, что один репликатор одновременно может принимать изменения только с одного сервера, тогда как задач Database Server на сервере запускается столько, сколько необходимо (в пределах "физических возможностей" компьютера, несущего сервер). В результате сервер может поддержать ряд одновременных процессов приема изменений с него репликаторами других серверов, но сам может принимать изменения одним репликатором одновременно только с одного сервера. Чтобы репликация стала двунаправленной (Pull-Pull), инициировавший ее сервер посылает на вызванный сервер запрос на прием изменений "от себя". Этот запрос поступает в очередь репликатора вызванного сервера.При репликации по локальной сети запрос на прием изменений репликатором другого сервера делается только по окончании приема изменений инициировавшим репликацию сервером, так что процессы "приема изменений" обоими серверами происходят не одновременно. Это, во-первых, минимизирует нагрузку на каждый сервер в ходе репликации (репликация интенсивно загружает компьютер сервера), и, во-вторых, способствует недопущению пиков сетевого трафика.
При репликации по модемному соединению или сети X.25 такой запрос выполняется практически сразу после установления связи, так что оба сервера принимают изменения друг от друга одновременно. Поскольку такой канал связи - типично "узкое" место, параллельная работа репликаторов способствует выполнению репликации за наименьшее время при наиболее полной загрузке канала связи между серверами.
Рис. 6.7 Репликация по схеме "Pull-Pull"
Репликатор может иметь в очереди до 5 запросов на репликацию (это запросы от других серверов или из-за перекрытий в расписании репликаций). Все запросы сверх пяти игнорируются.
Cхема Pull-Pull является стандартом в Notes версий 3.х.
Однако в версиях 4.х можно иметь на сервере постоянно запущенными несколько репликаторов. Это позволяет серверу при репликациях по схеме Pull-Pull выполнять одновременный прием изменений от равного количеству запущенных репликаторов количества других серверов. По командам консоли PULL, PUSH и REPLICATE запускается еще один репликатор, автоматически завершающийся по выполнении команды.
Схемы Pull-Push, Pull-only, Push-only
В некоторых случаях может быть целесообразно изменить принцип работы репликатора: вместо схемы Pull-Pull применить схему Pull-Push или "односторонние" схемы Pull-only или Push-only. Выбор схемы репликации выполняется в документе Connection (поле Replication Type:) или в зависимости от команды консоли, осуществляющей репликацию (PULL- схема Pull-only, PUSH - схема Push-only, REPLICATE
- схема Pull-Push).
· Pull-Push
("принять-затолкнуть"). Двусторонний процесс, полностью реализуемый репликатором на вызывающем сервере. Сначала репликатор вызывающего сервера принимает изменения с вызванного сервера, затем "заталкивает" свои изменения на вызванный сервер. На вызываемой стороне работу поддерживает задача DataBase Server.
Рис. 6.8 Репликация по схеме Pull-Push
· Push-only
("только затолкнуть"). Односторонний процесс, в котором вызывающий сервер только "заталкивает" изменения на вызванный сервер.
· Pull-only
("только принять"). Односторонний процесс, в котором вызывающий сервер только принимает изменения с вызванного сервера.
Шифрование исходящей почты
Когда пользователь запрашивает шифрование почтового сообщения, Notes сначала шифрует тело сообщения случайно сгенерированным им ключом шифрования RC2 (как в схеме с одним ключом). Затем Notes шифрует сам ключ шифрования RC2 публичным ключом получателя (последний берется из адресной книги) и добавляет зашифрованный RC2 в тело сообщения. Получатель сообщения определяет ключ шифрования RC2, дешифрируя его код своим личным ключом. Затем он дешифрирует тело сообщения ключом шифрования RC2. Никто иной не может определить ключ RC2, нужный для дешифрирования тела сообщения, ибо только получатель "знает" свой личный ключ (он хранится только в ID-файле получателя).
Рис. 9.30. Выбор шифрования отправляемой и сохраняемой почты "по умолчанию"
Отправитель выбирает шифрование исходящей почты одним из двух путей: или в диалоговом окне User Preferences на закладке Mail
выбором опции Encrypt sent mail, что рассматривается как значение "по умолчанию" для всей исходящей почты, или в диалоговом окне - альтернативной форме Delivery Options выбором опции Encrypt, что имеет силу
для конкретного сообщения.
Рис. 9.31. Выбор шифрования для конкретного сообщения
Шифрование почты
Почта может шифроваться отправителями в момент отправления, получателями или администраторами Notes в момент получения. Единственное шифруемое поле в почтовой форме Memo - поле Body ("тело сообщения"). Только содержимое поля Body может шифроваться. Шифрование отправляемой, входящей и сохраняемой почты осуществляется по комбинированной схеме: шифрование одним случайно сгенерированным ключом шифрования с последующим шифрованием этого ключа по схеме с двумя ключами.Шифрование полей в документах
Notes позволяет ограничивать доступ к определенным полям в документах посредством шифрования (encryption) их содержимого. Шифрование - кодирование данных так, чтобы только те пользователи, которые имеют ключ, могли эти данные читать. Встречаются системы шифрования с одним ключом ("симметричная" система) и с двумя (личным и публичным) ключами ("асимметричная" система).В первом случае один и тот же ключ используется и для кодирования, и для декодирования информации. Обе стороны должны знать тот же самый ключ. Этот метод неудобен при передаче почты в больших сетях, где пользователи могут и не знать друг друга лично. Но он удобен в случае использования зашифрованных документов из одной базы ограниченным кругом лиц, каждому из которых можно предоставить ключ шифрования. В Notes "на этом поприще" используется криптосистема с одним ключом DES (Data Encryptions System), разработанная фирмой IBM по заказу правительства США и считающаяся одной из наиболее "быстрых".
Во втором случае один из пары ключей используется для кодирования, а другой для декодирования информации. В Notes "на этом поприще" используется криптосистема RSA с двумя ключами. Эта криптосистема была изобретена в 1977 году тремя профессорами Ronald Rivest, Adi Shamir и Leonard Adelman (отсюда и аббревиатура RSA) из MIT, впоследствии основавшими компанию RSA Data Security Inc. в Redwood City, Калифорния. В криптосистеме RSA каждому субъекту (пользователю, серверу) назначается уникальная пара ключей: личный (private) ключ, который этот субъект хранит в тайне, и публичный (public) ключ, который, напротив, должен быть известен многим. Данные, зашифрованные одним из пары ключей, могут быть расшифрованы только при наличии другого ключа из этой пары.
Личный ключ хранится только в ID-файле субъекта. Публичный ключ хранится и в ID- файле субъекта, и в общей адресной книге. Любой пользователь сети Notes может отправить для пользователя Х сообщение, зашифрованное публичным ключом пользователя Х, ибо общая адресная книга с этим ключом общедоступна. Только пользователь Х может расшифровать это сообщение, ибо только в его ID-файле хранится его личный ключ. При регистрации нового пользователя в общую адресную книгу добавляется его публичный ключ. Пользователь без публичного ключа в адресной книге вообще не может получить шифрованную почту.
В Notes для шифрования используются обе криптосистемы (RSA и DES), причем во многих случаях комбинированно. Алгоритмы шифрования полей документа и шифрования почтового сообщения различны.
Информация в полях документов, хранимых в базах данных Notes, шифруется по схеме с одним ключом. Ключи шифрования (encryption keys) создаются пользователями и сохранятся в ID-файлах пользователей. Информация в документах и шифруется, и дешифрируется одним и тем же ключом шифрования. Чтобы иметь доступ к зашифрованной информации, нужно иметь в ID-файле соответствующий ключ. Ключи шифрования также могут быть ограниченно распространены среди группы пользователей, имеющих доступ к зашифрованной этими ключами информации (по аналогии с ключами от рабочих помещений). Таких ключей может быть создано много, каждый для своего специального применения. Чтобы "отличать" ключи друг от друга, все ключи "внутри" одного ID-файла имеют уникальное имя.
Кроме того, информация в одном документе может быть зашифрована сразу несколькими ключами шифрования, которые находятся в ID-файле "шифрующего" документ. Для дешифрирования информации в документе достаточно наличия в ID-файле только одного из использованных при шифровании ключей. Для "запоминания" этого момента полезна аналогия с комнатой, имеющей три двери: три ключа необходимы, чтобы запереть все двери, но только один ключ необходим, чтобы войти в комнату. А в качестве примера целесообразного использования можно предложить следующий. В подразделении два отдела. Отдел А имеет ключ шифрования "КлючА", а отдел В - "КлючВ". Руководство подразделения, в который входят эти отделы, имеет оба ключа "КлючА" и "КлючВ". Если документ создан в отделе А и зашифрован ключом "КлючА", к информации в нем могут получить доступ только имеющие "КлючА" - отдел А и руководство подразделения, но не отдел В. Если документ создан в отделе В и зашифрован ключом "КлючВ", к информации в нем могут получить доступ только имеющие "КлючВ" - отдел В и руководство подразделения, но не отдел А. Если же документ был создан в подразделении и был зашифрован обоими ключами "КлючА" и "КлючВ", к информации в нем могут получить доступ как в подразделении, так и в отделе А (имея "КлючА") и в отделе В (имея "Ключ В").
Итак, для обеспечения шифрования документов необходимы три шага: создание ключа и распространение его среди группы пользователей, создание в документе шифруемых полей и назначение ключа для документа.
Шифрование сохраненной почты
Пользователь может запросить шифрование почты, сохраняемой им в своем почтовом ящике. Шифруется только содержимое поля Body сообщения, шифрование выполняется случайно сгенерированным ключом шифрования, который затем шифруется публичным ключом пользователя. Для дешифрирования сохраненной почты необходим личный ключ пользователя, имеющийся только в его ID-файле.Шифрование сохраняемой в почтовом ящике почты выбирается посредством установок в диалоговом окне User Preferences на закладке
Mail (опция Encrypt Saved Mail). Когда пользователь отправляет почту, то после её отправки перед записью "копии" в почтовый ящик выполняется шифрование поля Body сохраняемого документа. Если пользователь просто сохраняет почту, так и не отправив ее, поле Body тоже шифруется. Однако выбор этой опции автоматически не зашифрует ранее сохраненную почту - чтобы зашифровать ее, пользователь должен ее повторно открыть и повторно сохранить.
Шифрование входящей почты
Шифрование входящей почты работает аналогично шифрованию исходящей почты: случайно сгенерированный ключ шифрования с его последующим шифрованием публичным ключом получателя. Только это происходит во время поступления сообщения в почтовый ящик получателя, когда серверная программа Router "перекладывает" поступившее письмо из базы входящих писем сервера - MAIL.BOX - в почтовый ящик.Администратор Notes может "затребовать" автоматическое шифрование всей прибывающей на сервер входящей почты, установив в файле NOTES.INI сервера ненулевое значение переменной MailEncryptIncoming, например: MailEncryptIncoming = 1.
Пользователь тоже может выбрать шифрование входящей почты, но только для себя. В его документе Person в общей адресной книге в группе полей Misc есть поле с меткой Encrypt Incoming Mail:. Для шифрования входящей почты в нем надо выбрать Yes.
Система электронной почты
Термин сообщениеиспользуется повсюду в этой главе для обозначения документа Notes, который передается системой почты Notes. Сообщение может быть составлено как с использованием стандартной почтовой формы Notes, так и по совершенно иной форме.
Система электронной почты Notes содержит четыре основных компоненты:
· Mailer
- подсистема, отвечающая за поиск имен (адресов) получателей сообщений, помещение адресов в почтовую форму, отправку сообщений на почтовый сервер и некоторые другие почтовые возможности, в частности, возврат отправителю уведомления о прочтении получателем его сообщения и предупреждение получателя о наличии новых сообщений. Mailer работает на станции клиента. Он - часть программного обеспечения станции. Однако вы явно не обнаружите в каталоге программ Notes соответствующих этой подсистеме выполняемых файлов или библиотек динамической компоновки - Mailer "размазан" по программному обеспечению станции.
· Router
- подсистема, осуществляющая доставку сообщений. Router выполняется на сервере Notes. Это отдельная серверная программа Mail Router (хROUTER.exe, где х зависит от платформы). В ходе своей работы она создает подпроцессы (threads), выполняющие доставку сообщений - по умолчанию по одному подпроцессу на каждый порт сервера.
· Служба имен
- подсистема, ответственная за работу с адресной книгой. Служба имен обычно постоянно работает на сервере, но может в некоторые моменты времени работать и на станции.
· Gateways (шлюзы)
и (или) Mail Transfer Agents (агенты передачи почты) - программы, которые могут передавать сообщения между пользователями почтовой системы Notes и пользователями "чужой" (т. e. не - Notes) почтовой системы. Программа шлюза или агент передачи почты обычно выполняются на сервере Notes и пользуются услугами, обеспечиваемыми Router. Чтобы Router "знал" о наличии шлюза (агента), в общей адресной книге создается документ формы Foreign Domain, содержащий имя "чужого" домена, имя сервера Notes, на котором функционирует шлюз (агент), и имя файла почтовой базы, через которую Router и шлюз (агент) обмениваются сообщениями.
Хотя перечисленные компоненты распределены по разным компьютерам, они действуют совместно и согласованно, чтобы исполнить одну основную функцию: перемещение документа Notes - сообщения - со станции отправителя через цепочку серверов в почтовый ящик получателя, который определен своим именем (адресом).
Соединения через асинхронный PAD по сети X.
Здесь мы предполагаем, что на вызывающем компьютере (станции или сервере) модем подключен непосредственно к COM-порту. Однако он выполняет телефонный вызов на модем, находящийся "на входе" асинхронного ассемблера/дизассемблера пакетов (асинхронный PAD). PAD территориально расположен у "ближайшего" провайдера услуг X.25 и своей "второй стороной" подключен к сети X.25. Вызываемый сервер Notes оборудован картой X.25фирмы Eicon
(подробнее смотрите в 4.1.1), которая также подключена к сети X.25.
Таким образом, с точки зрения модели, приведенной на Рис. 5.1, управляемое устройство УУ1 и скрипт его "приобретения" в данном случае отсутствуют. Роль управляемого устройства УУ2 выполняет асинхронный PAD. Диалог между вызывающим компьютером и PAD задается скриптом соединения. Этот диалог сводится к переводу PAD в необходимый режим и "вынуждению" его установить соединение с абонентом сети X.25, имеющим определенный DTE-адрес, т.е. картой X.25, установленной в вызываемом сервере Notes. Выполняется скрипт соединения, естественно, после того, как установлено соединение с установленным "на входе" PAD модемом.
Рис. 5.11 Схема соединения через асинхронный PAD по сети X.25
Рассмотрим действия, которые необходимо выполнить по настройке вызывающих станции или сервера в такой ситуации.
Настройки COM-порта
Единственным отличием от рассмотренного в 5.1 в конкретном случае, с которым имел дело автор, было то, что асинхронный PAD "требовал", чтобы модемное соединение с ним устанавливалось на фиксированной скорости 9600 bps. Однако модемы на вызывающем компьютере и PAD, а так же свойства соединяющей их телефонной линии при использовании штатного файла управления модемом "провоцировали" драйвер XPC на установление соединения на более высокой скорости. Проблема была устранена модификацией файла управления модемом: в строку инициализации модема ZyXEL U-1496+ была добавлена команда &N3, "вынуждающая" вызывающий модем устанавливать соединение с вызываемым на фиксированной скорости 9600 bps.
; а скрипт ожидает этого символа до 20 секунд.
WAIT 20 FOR "@"
; REPLY "String" посылает на УУ строку "String".
; В данном случае на PAD посылаются строки, переводящие PAD
; в режим, необходимый для работы с Notes. Все эти строки "SET"
; в точности заимствованы из "штатного" скрипта.
; ERROR <метка> после WAIT [N] [FOR "SubString"]
; передает управление на указанную метку, если за N секунд
; от УУ не получена строка, содержащая "SubString".
REPLY "SET 1:0,2:0,3:0,4:20,5:0,7:0,8:0,9:0"
WAIT 5 FOR "@"
ERROR TIMEOUT
REPLY "SET 10:0,12:0,13:0,14:0,15:0,16:0,17:0,18:0"
WAIT 5 FOR "@"
ERROR TIMEOUT
REPLY "SET 19:1,20:255"
WAIT 5 FOR "@"
ERROR TIMEOUT
; REPLY "^1" передает PAD значение первого аргумента: DTE-адрес
; абонента в сети X.25, с которым нужно установить соединение.
; WATCH [N]
; [FOR]
; "SubString1" Оператор1
; "SubString2" Оператор2
; . . .
; ENDW
; представляет собой "переключатель" в зависимости от того,
; содержится ли в "ответе" УУ указанная подстрока "SubStringI".
; Если за N секунд не получено предусмотренного ответа,
; выполняется следующий за ENDW оператор.
; "END" "нормально" завершает скрипт.
; FAIL String записывает строку в LOG.NSF и завершает скрипт "по ошибке".
; Если PAD возвращает строку "CONNECTED", соединение с абонентом X.25
; установлено, и скрипт "нормально" завершает работу.
; Иначе скрипт завершает работу "по ошибке".
REPLY "^1"
WATCH 15
"CONNECTED" END
"REJECTING" FAIL > Call rejected
"ILLEGAL ADDRESS" FAIL > Illegal DTE address
"?" FAIL > Unrecognized DTE address
ENDW
FAIL > Timed out trying to connect
; Инициализация модема станции
19.11.96 15:26:25 COM1: Send to Modem: AT&FE0X6&N3 (9600 bits per second)
19.11.96 15:26:25 COM1: Receive from Modem: OK
19.11.96 15:26:26 COM1: Send to Modem: ATM0 (9600 bits per second)
19.11.96 15:26:26 COM1: Receive from Modem: OK
19.11.96 15:26:26 COM1: Send to Modem: AT&H0 (9600 bits per second)
19.11.96 15:26:26 COM1: Receive from Modem: OK
19.11.96 15:26:26 COM1: Send to Modem: ATS9=6 (9600 bits per second)
19.11.96 15:26:27 COM1: Receive from Modem: OK
; Набор телефонного номера модема на PAD
19.11.96 15:26:27 COM1: Send to Modem: ATDP1234567, (9600 bits per second)
; Ответ модема на PAD на входящий вызов
19.11.96 15:26:56 COM1: Receive from Modem: CONNECT 9600/ARQ
19.11.96 15:26:56 COM1: 9600 bits per second connection established
; Соединение с модемом на PAD установлено, начинается выполнение скрипта соединения
19.11.96 15:26:59 COM1: Script Received: SPRINT NETWORKS
19.11.96 15:26:59 COM1: Script Received: 777 3350.07
19.11.96 15:26:59 COM1: Script Matched: @
; После ответа PAD на него посылаются команды SET
19.11.96 15:26:59 COM1: Script Sent: SET 1:0,2:0,3:0,4:20,5:0,7:0,8:0,9:0
19.11.96 15:26:59 COM1: Script Received: @SET 1:0,2:0,3:0,4:20,5:0,77:0,8:0,9:0
19.11.96 15:27:00 COM1: Script Matched: @
19.11.96 15:27:00 COM1: Script Sent: SET 10:0,12:0,13:0,14:0,15:0,16:0,17:0,18:0
19.11.96 15:27:00 COM1: Script Received: @SET 10:0,12:0,13:0,14:0,15:0,16:0,17:0,18:0
19.11.96 15:27:01 COM1: Script Matched: @
19.11.96 15:27:01 COM1: Script Sent: SET 19:1,20:255
19.11.96 15:27:01 COM1: Script Received: @SET 19:1,20:255
19.11.96 15:27:01 COM1: Script Matched: @
; На PAD посылается DTE-адрес, с которым нужно установить соединение
19.11.96 15:27:02 COM1: Script Sent: 7770123400
19.11.96 15:27:02 COM1: Script Received: @7770123400
19.11.96 15:27:02 COM1: Script Received: 777 1234 CONNECTED
19.11.96 15:27:02 COM1: Script Matched: CONNECTED
19.11.96 15:27:03 COM1: End of script file or END command reached
; Скрипт соединения завершил работу
; Далее станция устанавливает соединение с сервером Notes
19.11.96 15:27:25 Network: Determining path to server NS330/CROC
19.11.96 15:27:25 Network: Checking normal priority connection records only...
19.11.96 15:27:25 Network: Allowing wild card connection records...
19.11.96 15:27:25 Network: Enabling name server requests...
19.11.96 15:27:25 Network: Checking local COM1 names table for NS330/CROC
19.11.96 15:27:25 Network: Address found for NS330/CROC via COM1
19.11.96 15:27:25 Network: Connecting to NS330/CROC over COM1
19.11.96 15:27:25 Network: Use address 'NS330' on COM1
19.11.96 15:27:36 Network: Connected to server NS330/CROC
Остается отметить, что номера телефонов и DTE-адреса в документе Connection и протоколе заменены вымышленными.
Совместно используемый почтовый ящик (shared mail) и серверная задача Object store manager
OBJECT Установка на сервере возможности "совместно используемый почтовый ящик" (СПЯ) позволяет экономить дисковую память. Предположим, нескольким получателям, почтовые ящики которых находятся на этом сервере, приходит одно и то же сообщение. Вместо того чтобы помещать копию всего сообщения в почтовый ящик каждого получателя, в их почтовые ящики добавляется только заголовок сообщения со ссылкой на тело сообщения, а тело сообщения (содержимое поля Body типа Rich Text, включая присоединенные файлы) помещается в одном экземпляре в совместно используемый почтовый ящик. Например, если тело сообщения имеет размер 1 Мб, а сообщение адресовано 10 получателям на этом сервере, будет сэкономлено около 9 Мб памяти. В то же время для пользователя такое хранение его сообщения остается "полностью прозрачным". Когда пользователь открывает сообщение, заголовок активизирует связь с телом сообщения, сохраненным в СПЯ. Notes "показывает" получателю сообщение точно так же, как если бы все сообщение было целиком в почтовом ящике пользователя. Если пользователь удаляет такое сообщение, Notes удаляет только заголовок из почтового ящика пользователя, а тело сообщения остается в совместно используемом почтовом ящике, однако счетчик ссылок на тело сообщения уменьшается на единицу. После того, как все получатели на этом сервере удалили это сообщение из своих почтовых ящиков, счетчик ссылок на тело сообщения становится равным нулю, серверная задача Object store manager, запускаемая по умолчанию в 2 часа ночи с параметром Collect, удаляет уже более никому не нужное тело сообщения из совместно используемого почтового ящика.Все работы по сопровождению и настройке совместно используемой почты администратор выполняет с использованием серверной задачи Object store manager - OBJECT.
Более подробно задача OBJECT
и ее многочисленные параметры будут рассмотрены в главе 7.
Создание дополнительных СПЯ
Пока имеется достаточно дискового пространства, чтобы поддерживать рост СПЯ, вам не имеет никакого смысла создать дополнительные СПЯ. Функция Collect, которая по умолчанию выполняется ежедневно, ограничивает рост СПЯ. Однако, когда размер "первого" СПЯ станет очень большим, возникает необходимость создать дополнительный СПЯ на другом диске и "пере-присоединить" к нему некоторые ПЯ.Между тем, только один СПЯ будет использоваться серверной задачей Mail Router для доставки почты. Но можно иметь больше чем один СПЯ, содержащий тела сообщений, которые были доставлены ранее или присоединены к этим СПЯ вручную.
Чтобы создавать дополнительный СПЯ, используют команду:
Load Object Create NEWOBJ.NSF ,
где NEWOBJ.NSF - имя нового СПЯ, если необходимо, включая путь.
После этого к созданному СПЯ присоединяют необходимые ПЯ, используя опции Link и Relink команды Load Object.
Создание древовидного набора иерархических сертификаторов
Речь пойдет о создании набора ID-файлов для сертификаторов: ID-файла сертификатора организации (верхний уровень) и ID-файлов сертификаторов отделений, отделов и более мелких оргединиц. Эти ID-файлы создают остов "для развертывания" дерева имен вашей организации. Обычно каждый такой ID-файл передается конкретному лицу - сертификатору соответствующего уровня. Используя полученные ID-файлы,сертификаторы будут создавать ID-файлы пользователей, серверов или других сертификаторов "на уровень ниже их самих" в дереве имен или ресертифицировать ID-файлы пользователей и серверов. Следовательно, вся немалая работа по сертификации и ресертификации может выполняться не одним сертификатором, а "целой иерархией" сертификаторов, возможно, даже территориально-удаленных.
Рис. 8.7 Древовидный набор иерархических сертификаторов - остов для "выращивания дерева" имен в организации
Создание и распространение ключа шифрования
Любой пользователь Notes может создать ключ шифрования, выбрав в меню File - Tools - User ID… , и нажав кнопку New в диалоговом окне на закладке Encryption (Рис. 9.17).В очередном диалоговом окне (Рис. 9.18) ключу присваивается имя. По нажатию кнопки OК
ключ шифрования добавляется в ID-файл пользователя.
Чтобы другие пользователи могли читать шифрованные документы, им должны быть предоставлены ключи шифрования. Есть два пути распространения ключей шифрования: почтой Notes или через файлы (экспорт/импорт).
Распространение ключей почтой
Нажав кнопку Mail
в диалоговом окне на закладке Encryption (Рис. 9.17), пользователь может отправить ключ шифрования своим коллегам. Он заполняет в полученном окне (Рис. 9.19) адрес, нажимает кнопку Send и в следующем в диалоговом окне (Рис. 9.20) "решает вопрос", может ли получатель передавать полученный ключ другим лицам. Передаваемый ключ всегда автоматически шифруется и подписывается.
Коллеги, получившие такое письмо (Рис. 9.21), должны выбрать в меню Actions - Accept Encryption Key - ключ шифрования будет добавлен в их ID-файл.
Рис. 9.17. Окно свойств ID-файла пользователя - закладка Encryption
Рис. 9.18. Создание ключа шифрования
Рис. 9.19. Отправка ключа шифрования почтой
Рис. 9.20. Может ли получатель передавать ключ другим?
Рис. 9.21. Письмо с ключом шифрования
Распространение через файлы (экспорт/импорт)
Пользователь выбирает ключ шифрования и экспортирует его кнопкой Export в диалоговом окне на закладке Encryption (Рис. 9.17). Файл, в который экспортируется ключ, не шифруется, но пользователь может защитить его паролем (Рис. 9.22), а также указать, может или нет получатель передавать ключ другим (Рис. 9.23).
Рис. 9.22. Экспорт ключа шифрования
Рис. 9.23. Точное имя получателя и возможность передавать ключ другим
Рис. 9.24. Запись ключа в файл
Ключ экспортируется в файл с расширением .KEY в выбранном пользователем каталоге (Рис. 9.24). Создатель файла ключа передает его получателям, сам отвечая при этом за физическую безопасность.
Чтобы импортировать ключ (добавить его в свой ID-файл), пользователь-получатель нажимает кнопку Import в диалоговом окне на закладке Encryption (Рис. 9.17) и выбирает файл импортируемого ключа.
Рис. 9.25. Выбор файла с импортируемым ключом
Если файл ключа защищен паролем, получатель должен его ввести. Ключ добавляется в ID-файл получателя кнопкой Accept в следующем окне.
Рис. 9.26. Добавление ключа в ID-ФАЙЛЕ-файл
Создание ID-файла сертификатора организации
Обычно в качестве ID-файла сертификатора организации используют файл CERT.ID, созданный при установке первого сервера Notes в организации. Однако при необходимости всегда можно создать другой ID-файл сертификатора организации. Рекомендуется иметь только один ID-файл сертификатора организациидля одной организации, поскольку это исключает обмен взаимными сертификатами внутри организации. Но можно иметь и несколько таких ID-файлов, выпустив необходимые взаимные сертификаты.
Выбираем из меню File - Tools - Server Administration, далее кнопку Certifiers и в ее меню Register Organization ... .
Рис. 8.8 Окно Server Administration с раскрытым меню кнопки Certifiers
Получаем окно для регистрации сертификатора организации.
Рис. 8.9 Окно для регистрации сертификатора организации
В окне вводим обозначение страны, название организации и пароль для ID сертификатора организации. В поле Administrator вводим имя (адрес) лица, которое будет "владеть" ID-файлом и обслуживать запросы (в том числе и почтовые) на сертификацию. В окне по кнопке Other Certifier Settings можно задать дополнительную информацию о сертификаторе (она носит чисто информационный характер), а также изменить минимально-допустимую длину пароля.
Рис. 8.10 Окно Other Certifier Settings
Кнопка Registration Server позволяет выбрать сервер, в адресной книге которого будет создан документ Certifer со сведениями о сертификаторе организации. Кнопка Register выдает диалоговое окно для выбора местоположения и имени ID-файла сертификатора организации. После выбора местоположения и имени файла через 1-3 минуты ID-файл сертификатора организации будет создан.
Рис. 8.11 Документ Certifier
типа Notes Certifier содержит информацию о сертификаторе организации
Создание ID-файлов сертификаторов оргединиц
Оргединицы обычно соответствуют отделениям, отделам и рабочим группам в организации. Применять ID-файлы сертификаторов оргединиц особенно целесообразно в больших организациях с территориально удаленными офисами.ID-файл сертификатора оргединицы "подчинен по рангу" ID-файлу сертификатора организации или вышестоящей оргединицы. С его помощью можно создавать ID-файлы сертификаторов подчиненных оргединиц и сертифицировать ID-файлы пользователей и серверов.
Для создания ID сертификатора оргединицы выбираем из меню File - Tools - Server Administration, далее кнопку Certifiers и в ее меню Register Organizational Unit ...
. Получаем окно для регистрации сертификатора оргединицы.
Рис. 8.12 Окно для регистрации сертификатора оргединицы
Кнопкой Certifer ID
выбираем ID-файл сертификатора, являющийся "родителем" для вновь создаваемого. Остальное похоже на создание ID-файла сертификатора организации... Кнопка Register создает ID-файл сертификатора оргединицы и документ Certifer со сведениями о сертификаторе оргединицы в адресной книге регистрационного сервера.
Рис. 8.13 Документ Certifier типа Notes Certifier содержит информацию о сертификаторе оргединицы
Отметим, что весь созданный набор ID-файлов иерархических сертификаторов должен сохраняться в безопасном месте и защищаться от несанкционированного использования. Пароли ID-файлов сертификаторов должны быть достаточно длинными, чтобы исключить возможность их подбора. Крайне желательно иметь несколько архивных копий этих файлов, чтобы исключить случайную потерю любого из них. Один из вариантов организации такого архива рассматривается в 9.6.
Создание реплики базы
Кто может создавать реплики баз на сервере? Не все, а только те, кто перечислен (явно или как член группы) в поле с меткой Create replica databases: документа Server из общей адресной книги.Для создания реплики базы выберите из меню File - Replication - New Replica... Если перед этим на текущей закладке не была выбрана база, с которой необходимо создать реплику, появится диалоговое окно для выбора базы-оригинала. Выбор выполняется кнопкой Select.
Рис. 6.3 Оригинал можно выбрать и потом
Когда база-оригинал выбрана, вы получите диалоговое окно New Replica.
Рис. 6.4 Создание новой реплики
Укажите, где создается реплика: в поле Server - сервер или Local, в поле Title: - название, в поле File name: - имя файла. Выберите, как создавать реплику. Immediately - инициализировать и копировать базу сейчас. Такое может быть совершенно неприемлемо при создании реплик больших баз с сервера, доступ к которому возможен только по модему. Next scheduled replication - частично инициализировать базу (создать т.н. "окурок реплики" - "Replica Stub" размером в 176 Кб), предполагая при этом, что продолжение инициализации и копирование дизайна и документов состоится позже, при первой репликации. Выбор Copy Access Control List требует копировать в новую реплику ACL из оригинальной базы. Выбор Create full text index for searching требует создания для реплики индекса полнотекстового поиска.
Кнопка Encryption...
позволяет установить, кто сможет использовать создаваемую на локальном диске компьютера реплику. Если выбрано Do not locally encrypt this database, база может быть открыта локально даже без использования ID пользователя. В противном случае даже при локальном использовании базу сможет открыть только ее владелец, "предъявив" свой ID.
Рис. 6.5 Выбор локального шифрования для создаваемой реплики
Кнопка Size Limit...
позволяет ограничить максимально возможный размер создаваемой базы (1, 2, 3 или 4 Гб). Это именно максимально возможный размер - создаваемая база данных принципиально не сможет "разрастись" сверх этого размера. Для задания "практических" ограничений - "квот" на размер базы - используется иная последовательность действий:
File - Tools - Server Administration - кнопка Database Tools - выбор базы данных - выбор операции Quotas - выбор "практических" ограничений - кнопка Update.
Рис. 6.6 Ограничение максимального размера
Кнопка Replication Settings... позволяет выбрать репликационные установки для создаваемой базы. Они будут рассмотрены немного позже.
Созданная реплика будет иметь тот же идентификатор реплики, что и база, с которой реплика создана.
Еще раз напомним, что при копировании базы средствами Notes оригинал и копия будут иметь разные идентификаторы реплики. Но копия базы данных, выполненная средствами операционной системы, будет иметь тот же идентификатор реплики, что и оригинал, поскольку само значение идентификатора реплики хранится в файле базы. На практике в ряде случаев администраторы предпочитают создавать реплики баз именно путем их копирования как файлов. Однако во избежание возможных проблем, связанных с одновременной работой с файлом базы из нескольких приложений, рекомендуется перед созданием "физической копии" останавливать сервер Notes.
Создание шифруемых полей
Для шифрования полей в документе его форма должна иметь одно или более полей с атрибутом "шифруемые" (encryptable). Обычно разработчик базы данных присваивает этот атрибут - Enable encryption for this field - полям при проектировании формы.
Рис. 9.27. Окно свойств поля с установленным атрибутом "шифруемое"
В результате соответствующие поля в документах, созданных по этой форме, также "унаследуют" атрибут "шифруемое". Наконец, используя LotusScript, разработчик может присвоить этот атрибут полям непосредственно в создаваемом или существующем документе, не используя при этом форму.
Редактор на цветном мониторе может отличить шифруемые поля от обычных по красному цвету "полевых" скобок.
Обратите внимание на одну любопытную особенность шифруемых полей. Если документ с шифруемыми полями пытается прочитать пользователь, не имеющий нужного ключа шифрования, он "увидит" в зашифрованных полях формы значения, возвращаемые "формулами по умолчанию" этих полей, а не значения, хранящиеся в полях.
Информация из шифруемых полей, начиная с версий 4.х, уже может участвовать в полнотекстовом поиске. Но для этого в ID-файле сервера должны содержаться необходимые ключи шифрования.
Создание взаимных сертификатов
Взаимный сертификат (cross certificate) - документ, создаваемый иерархическим сертификатором, пользователем или сервером из одного дерева имен для иерархического сертификатора, пользователя или сервера из другого дерева имен. Документ необходим для того, чтобы в ходе выполнения процедуры аутентификации (8.3.2) удалось определить публичные ключи устанавливающих соединение сторон. Если же определить публичные ключи не удается, процедура аутентификации заканчивается неуспехом, в результате чего стороны обычно не предоставляют друг другу доступа.Взаимный сертификат создается и хранится в адресной книге. Он называется "взаимным" потому, что и другая сторона симметрично должна создать и хранить в своей адресной книге взаимный сертификат для первой стороны. В процессе выполнения процедуры аутентификации каждая из сторон всегда использует взаимный сертификат из своей локальной адресной книги.
Рис. 8.29 Деревья имен компаний Acme и Omega
Для того чтобы создать взаимный сертификат, необходимо иметь имя и публичный ключ того субъекта (сертификатора, пользователя или сервера), для которого взаимный сертификат создается. Обычно источником имени и публичного ключа служит безопасная копия ID-файла этого субъекта. В ней содержится иерархический сертификат, который состоит из цепочки сертификатов-компонент, выданных сертификаторами из дерева имен организации, предоставившей безопасную копию. Следовательно, вам доступны как имя и публичный ключ самого субъекта, так и имена и публичные ключи всех его сертификаторов. И за вами право выбирать, для кого из них выпустить взаимный сертификат. Например, вы представляете компанию Omega, и вам была предоставлена безопасная копия ID-файла Alice/Sales/Acme. Если вы выпустите взаимный сертификат на Alice/Sales/Acme, ваша сторона в ходе процедуры аутентификации сможет определить только публичный ключ Alice/Sales/Acme. Если вы выпустите взаимный сертификат на /Sales/Acme, ваша сторона в ходе процедуры аутентификации сможет определить публичные ключи всех, кто в дереве имен ниже /Sales/Acme
(это SERVER1/Sales/Acme,
Alice/Sales/Acme, Bob/Sales/Acme и любые другие, кто появится там позже). Если вы выпустите взаимный сертификат на /Acme, ваша сторона в ходе процедуры аутентификации сможет определить публичные ключи всех, кто в дереве имен ниже /Acme (это все, как настоящие, так и будущие пользователи и серверы компании Acme).
Следующий вопрос - от чьего имени выпускать взаимный сертификат. Если вы просто пользователь, сертификат можно выпустить только от вашего имени. Тогда этим сертификатом сможет воспользоваться только ваша станция и никто другой более. Аналогично администратор сервера может выпустить взаимный сертификат от имени сервера. Тогда им сможет воспользоваться только этот сервер и никто другой. Если вы имеете ID-файл сертификатора, сертификат можно выпустить от его имени. Тогда этим сертификатом сможет воспользоваться любой пользователь или сервер, который в дереве имен вашей организации ниже выпустившего сертификат сертификатора. Единственная тонкость - сервер или станция всегда обращается за взаимным сертификатом к локальной адресной книге. Для сервера это общая адресная книга, для станции - персональная. Поэтому взаимный сертификат, выпущенный от имени сертификатора, обычно вначале помещают в общую адресную книгу, а затем копируют в персональные адресные книги тех пользователей, которым он действительно нужен. Если в нашем примере вы выпускаете взаимный сертификат от имени John/Marketing/Omega, им может воспользоваться только станция John/Marketing/Omega. Если вы выпускаете взаимный сертификат от имени /Marketing/Omega, им смогут воспользоваться все, кто в дереве имен ниже /Marketing/Omega (в нашем примере пока только John/Marketing/Omega и Mary/Marketing/Omega). Если вы выпускаете взаимный сертификат от имени /Omega, им смогут воспользоваться все, кто в дереве имен ниже /Omega (в данном примере пока только
John/Marketing/Omega, Mary/Marketing/Omega и SERVER3/Marketing/Omega).
Рассмотрим все возможные варианты
взаимного сертификата, которые вы, как представитель компании Omega, могли бы выпустить.
· От имени John/Marketing/Omega для Alice/Sales/Acme
- позволяет только станции John/Marketing/ Omega определять публичный ключ станции Alice/Sales/Acme. С точки зрения установления соединений совершенно бесполезен, поскольку станция не может соединяться со станцией. Однако может использоваться для того, чтобы станция John/Marketing/Omega могла проверять "электронную подпись" Alice/Sales/Acme.
· От имени John/Marketing/Omega для /Sales/Acme
- позволяет только станции John/Marketing/Omega определять публичный ключ любого из дерева имен компании Acme ниже /Sales/Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega потому, что может обеспечить ему доступ к серверу SERVER1/Sales/Acme
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени John/Marketing/Omega для /Acme
- позволяет только станции John/Marketing/Omega определять публичный ключ любого из дерева имен компании Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega потому, что может обеспечить ему доступ к серверам SERVER1/Sales/Acme и SERVER2/Development/Acme
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Marketing/Omega для Alice/Sales/Acme
- позволяет станциям John/Marketing/Omega и Mary/Marketing/Omega определять публичный ключ станции Alice/Sales/Acme. С точки зрения установления соединений совершенно бесполезен, поскольку станция не может соединяться со станцией. Может использоваться для того, чтобы станции John/Marketing/Omega и Mary/Marketing/Omega могли проверять "электронную подпись" Alice/Sales/Acme.
· От имени /Marketing/Omega для /Sales/Acme
- позволяет станциям John/Marketing/Omega и Mary/Marketing/Omega определять публичный ключ любого из дерева имен компании Acme ниже /Sales/Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega и Mary/Marketing/Omega потому, что может обеспечить им доступ к серверу SERVER1/Sales/Acme (если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Marketing/Omega для /Acme
- позволяет станциям John/Marketing/Omega и Mary/Marketing/ Omega определять публичный ключ любого из дерева имен компании Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega и Mary/Marketing/Omega потому, что может обеспечить им доступ к серверам SERVER1/Sales/Acme и SERVER2/Development/Acme
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Omega для Alice/Sales/Acme - позволяет всем из компании Omega определять публичный ключ станции Alice/Sales/Acme. С точки зрения установления соединений представляет интерес для Alice/Sales/Acme
потому, что может обеспечить ей доступ к серверу SERVER3/Omega
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Omega для /Sales/Acme - позволяет всем из компании Omega определять публичный ключ любого из дерева имен компании Acme ниже /Sales/Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega и Mary/Marketing/Omega потому, что может обеспечить им доступ к серверу SERVER1/Sales/Acme (если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений). С той же точки зрения представляет интерес для Alice/Sales/Acme, Bob/Sales/Acme
и SERVER1/Sales/Acme
потому, что может обеспечить им доступ к серверу SERVER3/Omega
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Omega для /Acme - позволяет всем из компании Omega определять публичный ключ любого из дерева имен компании Acme. С точки зрения установления соединений представляет интерес для всех пользователей и серверов из обеих компаний, поскольку может обеспечить им доступ к серверам в другой компании (если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
Однако мы рассмотрели только одну половину вопроса. Чтобы процедура аутентификации при установлении соединений завершалась успешно, в компании Acme "зеркально симметрично" тоже должен быть выпущен хотя бы один взаимный сертификат от имени кого-то из компании Acme для кого-то из компании Omega. И вариантов здесь будет не меньше, чем было рассмотрено для компании Omega.
Далее можно было бы рассмотреть всевозможные пары из возможных взаимных сертификатов двух компаний. Ограничимся лишь несколькими вариантами.
· Omega: от имени John/Marketing/Omega для /Sales/Acme.
Acme: от имени SERVER1/Sales/Acme
для John/Marketing/Omega.
Позволяет только John/Marketing/Omega иметь доступ только к серверу SERVER1/Sales/Acme. Если в Acme
появится сервер с именем SERVER4/Sales/Acme, John/Marketing/Omega не будет иметь к нему доступа.
· Omega: от имени John/Marketing/Omega для /Sales/Acme.
Acme: от имени /Sales/Acme
для John/Marketing/Omega.
Позволяет только John/Marketing/Omega иметь доступ только к серверу SERVER1/Sales/Acme. Если в Acme
появится сервер с именем SERVER4/Sales/Acme, John/Marketing/Omega тоже будет иметь к нему доступ.
· Omega: от имени /Marketing/Omega для /Sales/Acme.
Acme: от имени /Sales/Acme
для /Marketing/Omega.
Позволяет только John/Marketing/Omega и Mary/Marketing/Omega иметь доступ только к серверу SERVER1/Sales/Acme. Если в Acme
появится сервер с именем SERVER4/Sales/Acme, John и Mary
тоже будет иметь к нему доступ. Если в Omega появится сервер с именем SERVER5/Marketing/Omega, он будет иметь доступ к серверу SERVER1/Sales/Acme. С другой стороны Alice, Bob и SERVER1 тоже будут иметь доступ к SERVER5/Marketing/Omega.
· Omega: от имени /Omega для /Acme.
Acme: от имени /Acme
для /Omega.
Все пользователи и серверы одной компании имеют доступ ко всем серверам в другой компании. Все новые пользователи и серверы так же автоматически обладают таким доступом.
Список управления доступом к базе (ACL)
Каждая база Notes имеет список управления доступом (Access Control List, ACL), определяющий, какие пользователи, группы пользователей, и серверы могут иметь к ней доступ и какие задачи в этой базе они могут исполнять.ACL включает две компоненты:
· список элементов ACL, каждый из которых содержит имя субъекта (пользователя, сервера или группы), его уровень доступа к базе и дополнительные свойства;
· список ролей вместе с назначением субъектов на роли.
Список управления доступом создается при создании базы и далее ведется менеджером базы данных в диалоговом окне, получаемом из меню File - Database - Access control....
Если имя пользователя или сервера не внесено в ACL базы данных явно или как члена группы, считается, что он - -Default-.
В Notes используется семь уровней доступа.
(Менеджер) может выполнять все возможные действия в базе данных - чтение, запись, редактирование документов, создание, модификация и удаление элементов дизайна (форм, видов, агентов…). Менеджер, в отличие от более низких уровней доступа, может также изменять ACL, настройки репликаций, установки локального шифрования базы и удалять базу данных. База данных всегда имеет по крайней мере одного менеджера.
Рис. 9.6. Список управления доступом - закладка Basics
(Дизайнер), в отличие от более низких уровней доступа, может создавать, модифицировать и удалять элементы дизайна (поля, формы, виды, общих агентов…), модифицировать репликационные формулы базы, создавать индекс полнотекстового поиска. И, конечно, выполнять те же самые действия, что и субъекты с более низким уровнем доступа
(Редактор) может читать, создавать и редактировать все документы в базе данных (в том числе и созданные другими пользователями), но не может изменить элементы дизайна, ACL и прочие атрибуты, присущие более высоким уровням доступа.
(Автор) может читать существующие документы и создать новые, но может редактировать только созданные им документы (но не другими).
(Читатель) может читать документы, но не может добавлять новые или редактировать существующие.
(Депозитор) может добавлять новые документы, но не может читать существующие, потому что попросту "не видит" их в видах базы.
No Access (Нет доступа). Пользователь не может открыть базу данных.
Кроме того, для каждого уровня доступа имеется свой собственный набор дополнительных флагов, уточняющих возможности на уровне. Ниже приведены все возможные флаги, но без учета уровня доступа, для которого они имеют смысл:
· Create documents - может создавать документы;
· Delete documents - может удалять документы;
· Create personal agents - может создавать личных агентов;
· Create personal folders/views - может создавать личные виды и папки;
· Create shared folders/views - может создавать общие виды и папки;
· Create LotusScript Agents - может создавать агентов на LotusScript;
· Read public documents - может читать общедоступные документы;
· Write public documents - может создавать общедоступные документы.
Из большого количества связанных с доступом комбинаций обратим ваше внимание на два момента. Во-первых, менеджер может "разрешить" читателю создавать личных агентов. А читатель может создать агента, который удаляет все документы в базе. Читатель может даже запустить этого агента. Но агент не сможет удалить документы в базе, поскольку "его читательского доступа" недостаточно для выполнения этой операции. Во-вторых, начиная с версии 4.5 даже пользователь с уровнем доступа No Access может быть "наделен возможностью" читать и (или) создавать в базе данных т.н. общедоступные документы. Чтобы эта возможность функционировала, разработчик базы должен создать в ней одну или несколько форм со свойством Available to Public Access users и полем (обычно, "невидимым") с предопределенным именем $PublicAccess типа Text и значением "1". Кроме того, обычно создаются и виды или папки, имеющие свойство Available to Public Access users, и содержащие общедоступные документы.
Группы - списки пользователей, серверов или других групп, создаваемые администратором в общей адресной книге. При использовании групп действуют следующие соглашения:
· если пользователь фигурирует в ACL и как член группы, и как физическое лицо, он получает права доступа физического лица, даже если права группы предоставляют ему больший уровень доступа;
· если пользователь - член двух групп в ACL - он получает права доступа группы с большим уровнем доступа.
Роли доступа используются для управления доступом пользователей или групп к определенным формам, видам или агентам в базе данных.
Рис. 9.7. Список управления доступом - закладка Roles
Дизайнер может предусмотреть при создании некоторых форм, видов или агентов, что доступ к ним должны иметь только те лица, которых впоследствии менеджер базы назначит на эту роль, а не все имеющие необходимый уровень доступа в ACL. Дизайнер (обычно при разработке базы он имеет и права менеджера) добавляет названия ролей в ACL базы. Например, [FormReadAccess] (к сожалению, название роли не "длиннее" 15 символов). Затем он использует эти названия ролей при определении доступа к некоторым формам или видам. При разработке агентов на LotusScript соответствующая проверка, назначен или нет запустивший агента пользователь на роль, выполняется в самом агенте. Если пользователь не назначен на роль, агент попросту не выполняет своего действия.
Менеджер базы впоследствии назначает (на закладке Basics щелчком мыши по названию роли при "выбранном" субъекте) на эту роль пользователей базы из числа имеющихся в ACL. Выполняемые менеджером изменения в списках назначенных на роль не требуют изменения доступа в использующих эту роль формах, видах и агентах. Только назначенные на роль смогут воспользоваться использующими роли формами, видами и агентами - простого присутствия в ACL недостаточно.
На закладке Log содержится информация о том, кто, когда и что изменял в ACL базы.
Рис. 9.8 Список управления доступом - закладка Log
На последней закладке, во-первых, можно задать для базы сервер администрирования и уточнить, должна ли серверная задача Administration Process вносить изменения в поля типа Readers и Authors при операциях изменения имен или удаления пользователей. Однако это уже рассматривалось в 3.2.14.
Во-вторых, менеджер базы данных может обеспечить, чтобы список управления доступа (ACL) оставался тем же самым во всех репликах базы. Для этого менеджер на закладке Advanced выбирает опцию Enforce a consistent Access Control List across all replica copies of this database ("предписать непротиворечивый список управления доступом во всех репликах этой базы данных"). Выбор этой опции не только гарантирует, что ACL будет оставаться одинаковой во всех репликах базы на серверах, но и то, что ACL будет оставаться одинаковой и будет функционировать в репликах на станциях пользователей. Если же эта опция не выбрана, пользователи имеют доступ менеджера к своим локальным репликам, а следовательно, могут менять их ACL, даже если в реплике на сервере они не имеют такого уровня доступа, хотя такие локальные изменения в ACL не поступают в реплику на сервере.
Рис. 9.9 Список управления доступом - закладка Advanced
Поддержка ACL в репликах на станциях тем не менее не является настоящим средством защиты, если вы физически не гарантируете безопасность станции или не применяете локального шифрования. Во-первых, зная имя группы, использованное в ACL, всегда можно создать группу с таким именем и включить в ее состав пользователя, которому необходим доступ. Во-вторых, зная полное имя пользователя, фигурирующего в ACL, можно создать новый ID-файл с таким именем (но, конечно, другими ключами) и получить "под ним" доступ к базе. Кроме того, серверные add-in - программы могут "обходить" список управления доступа, предписанный для локальных реплик.
Чтобы обеспечить распространение репликационных установок во все реплики базы на других серверах, следует выбрать данную опцию в реплике на том сервере, который имеет доступ менеджера во всех других серверных репликах, иначе репликация будет неудачной - сервер не сможет изменить ACL в репликах базы на других серверах. В сообщениях о неудаче репликации по этой причине вы встретите слова "inconsistent ACL".
В-третьих, в Notes версий 4. 5 появилась возможность указать максимальный уровень доступа к этой базе с использованием Web-броузера. На сервере Notes такой доступ поддерживает серверная задача HTTP, рассматриваемая в 10.2.
В-четвертых, кнопка Look Up User Types for "Unspecified" Users обеспечивает проверку фигурирующих в ACL имен по адресной книге и конкретизацию их типа: Person, Server, Person Group, Server Group, Mixed Group. Нажмите кнопку и вернитесь на первую закладку - в типах имен могут произойти изменения. Для чего это необходимо? Например, администратор сервера может запустить на сервере станцию Notes и работать под ID сервера с базой, если в ACL для имени сервера задан тип Unspecified. Но он не сможет этого сделать, если в ACL для имени сервера задан тип Server.
Как выяснить, чем определяется доступ пользователя к базе данных
Чтобы выяснить, что именно (например, какая группа) определяет уровень доступа пользователя к базе данных, "нажмите мышью" пиктограмму уровня доступа в строке состояния в нижней части окна рабочей области.
Рис. 9.10 К этой базе пользователь Nikolay N. Iontsev/InterTrustCorp/SU получает доступ менеджера как член группы Administrators
В появившемся диалоговом окне содержатся:
· все группы из адресной книги, членом которых является пользователь;
· шаблоны имен, которым удовлетворяет имя пользователя;
· роли, на которые пользователь назначен (они заключены в скобки []).
Галочкой отмечены те имена, на основании которых станция "принимает решение" о предоставлении пользователю его уровня доступа.
Такая возможность работает для баз на серверах и локальных баз, для которых выбрана опция Enforce a consistent Access Control List across all replicas of this database.
Список управления выполнением (ECL)
У этой возможности, окончательно оформившейся в только версии 4.5, длительная и любопытная предыстория.Начнем с того, что при использовании любой почтовой системы имеется риск получить в письме присоединенный файл, содержащий выполняемую программу или интерпретируемый приложением компьютера получателя код. "Поспешное" выполнение этого файла на компьютере получателя может привести к "заражению компьютера вирусом" (исполняемая программа-вирусоноситель или интерпретируемый код-вирусоноситель, наподобие макровирусов в Microsoft Word или Microsoft Exel) или прямому причинению ущерба (исполняемая программа или интерпретируемый код типа "троянский конь").
Аналогичная ситуация наблюдается в большинстве систем "клиент-сервер", когда на компьютере клиента запускается полученный с сервера интерпретируемый код или исполняемая программа. Разница лишь в "степени доверия" к их разработчику (обычно она выше, чем при использовании почты) и "степени легкости запуска" (часто запуск выполняется даже без уведомления об этом пользователя).
Lotus Notes этих вопросах не является исключением, причем создание "троянских коней" возможно средствами самого Notes. В простейшем случае это кнопка или "горячая площадка" в любом поле типа Rich Text любого документа, например, в поле Body ("тело сообщения") стандартной почтовой формы. Нажатие такой кнопки или "щелчок мышью по горячей площадке" запускают связанные с этим объектом @-формулы или подпрограмму на LotusScript. Нет сомнений, что это очень полезная для разработки ряда приложений или просто документов возможность. Но эта же возможность может использоваться и для выполнения "совсем не ожидаемых" пользователем действий. Например, даже с использованием @-функций несложно написать @-формулу, которая получит из почтового ящика пользователя-получателя список всех его корреспондентов, и каждому из них, уже от имени "неосторожного" получателя, отправит письмо с точно такой же кнопкой. А классифицировать такую @-формулу приходится как почтовый вирус, ибо признаки размножения, хотя и требующие участия человека, у него имеются. Другим вариантом создания подобных "троянских коней" является форма, встроенная в документ. В ней содержится множество мест, в которые могут быть встроены @-формулы или подпрограммы на LotusScript
(скрипты), автоматически запускаемые в момент открытия пользователем такого документа. Третий вариант, доступный однако лишь разработчикам используемых в организации баз, не требует поиска "тонких мест" продукта - это обычные элементы дизайна базы: формы, агенты...
Разработчики Lotus Notes всегда знали о существовании подобных эффектов и по мере возможности занимались созданием средств борьбы с ними. В Notes версий 3.х при анализе различных типов @-формул прослеживается политика запретов на потенциально опасные действия. Факты создания пользователями "троянских коней", основанных на встроенных в поле типа Rich Text кнопках, отмечены в базе знаний по Notes (Lotus Notes Knowledge Base) еще в 1993-1994 годах. Возможность создания "троянских коней" на базе встроенной в документ формы также была известна разработчикам Lotus Notes, хотя об этом и не упоминалось в базе знаний по продукту. Но с появлением в Notes версии 4.0 языка LotusScript
придерживаться политики запретов стало невозможно, поскольку иначе была бы потеряна вся мощь языка и его встроенных классов. Требовался механизм доверия, основанный на "личной электронной подписи" создателя содержащего скрипты и @-формулы элемента дизайна или документа и позволяющий перед любым выполнением скриптов или @-формул этого элемента дизайна или документа проверять потенциальные способности его кода и априорный уровень доверия к его создателю. Однако, можно предположить, что из-за недостатка времени, версия Notes 4.0 появляется на рынок с применением такого механизма только при запуске агентов на сервере. В версии Notes 4.1 в свойства базы добавляется опция, разрешающая или запрещающая сохранять в ней документы с формой, встроенной в документ. При попытке открыть документ с встроенной формой пользователь предупреждается о потенциальной опасности, может отказаться от открытия и в меру возможностей исследовать вызывающий подозрение документ, в том числе и в пошаговом отладчике. Наконец, в Notes версии 4.5 вводится список управления выполнением (Execution Control List, ECL) на станции Notes.
Окно списка управления выполнением может быть получено выбором в меню File-Tools-User Preferences с последующим нажатием кнопки Seсurity
Options на закладке Basics.
Рис. 9.14 Окно списка управления выполнением станции
В левой части окна присутствует список тех, кем может быть "подписан" элемент дизайна или документ (When signed by:). В этот список могут быть добавлены полные имена разработчиков дизайна или шаблоны их имен, например, */InterTrustCorp/SU. Все элементы дизайна шаблонов баз, созданных самими разработчиками Lotus Notes, "подписываются" именем Lotus Notes Template Development/Lotus Notes. Предопределенное имя -No Signature- применяется для обозначения "неподписанных" элементов дизайна или документов. Наконец, предопределенное имя -Default- используется для обозначения "подписанных" элементов дизайна или документов, когда "подписавшее" его лицо не входит в заданный список.
В правой части окна (Allow:) для каждого имени или шаблона имен из списка перечисляются возможности, которые "разрешены" для скриптов и @-формул, имеющихся в элементах дизайна и документах, "подписанных этим именем":
· Access to the file system - возможность присоединять и отсоединять файлы в/из полей типа Rich Text, возможность читать и записывать файлы в каталогах компьютера станции;
· Access to current database - возможность читать или модифицировать информацию в текущей базе;
· Access to environment variables - возможность читать или модифицировать значения переменных из файла NOTES.INI станции функциями @SetEnvironment и @GetEnvironment или аналогичными методами LotusScript;
· Access to non-Notes databases - возможность читать информацию из баз данных "не Notes" форматов функциями @DBLookup, @DBColumn и @DBCommand;
· Access to external code - возможность вызывать методы классов и функции из библиотек динамической компоновки, не входящих в поставку Notes;
· Access to external programs - возможность запуска и работы с другими приложениями, включая активизацию любых OLE-объектов;
· Ability to send mail
- способность отправлять почту @-функциями, например, @MailSend, и методами встроенных классов;
· Ability to read other databases - способность читать информацию из других баз данных, но не из текущей базы;
· Ability to modify other databases - способность изменять информацию в других базах данных, но не в текущей базе;
· Ability to export data - способность выводить на принтер, копировать в буфер обмена, экспортировать и импортировать данные;
· Access to Workstation Security ECL - возможность изменять список управления выполнением (ECL) станции.
В принципе право ведения списка управления выполнением предоставлено пользователю станции. По умолчанию установки в ECL станции таковы, что всем предоставлены все возможности, а это потенциально опасно.
Однако администратор домена может осуществлять централизованное управление списками управления выполнением станций. Для этого администратор из общей адресной книги выбирает в меню Action - Edit Administration ECL и получает окно (Рис. 9.15), лишь немногим отличающееся от аналогичного окна на станции. Выполненные администратором в этом окне и сохраненные в общей адресной книге установки ECL для краткости будем называть "ECL домена". Отличие же окон состоит в возможности разрешить или не разрешить пользователям изменять скопированную на станцию ECL домена.
В процессе установки рабочих станций пользователей ECL домена автоматически копируется в ECL станции. После того, как администратор внесет очередные изменения в ECL домена, чтобы эти изменения поступили в ECL уже установленных станций, администратору необходимо отправить пользователям домена письмо с кнопкой, имеющей формулу @RefreshECL("";"").
Рис. 9.15 Окно списка управления выполнением для домена
Рис. 9.16 Средство для "массового подписывания" элементов дизайна баз
Остается отметить, что в руководстве администратора Notes версий 4.5 упоминается об утилите SIGNNSF.EXE, предназначенной для того, чтобы "в массовом порядке подписывать" элементы дизайна баз и шаблонов, используемых в организации. Такой утилиты в Notes версий 4.5 и 4.51 нет.
Однако в Notes версии 4.51 возложенные на утилиту функции включены в окно Tools to Manage Notes Databases, "вызываемое" из окна Server Administration кнопкой Database Tools. Средство применяется для расположенных локально баз данных или шаблонов. Для шаблонов приходится ввести имя файла шаблона. Для баз данных, находящихся на сервере, следует пользоваться этим средством из программы станции, запущенной на компьютере сервера. В качестве ID-файла, "именем которого подписываются" базы и шаблоны, используется текущий ID-файл станции. Могут быть "подписаны" все элементы дизайна (если поле NoteID пусто) или только избранные (в поле NoteID задается идентификатор местоположения элемента дизайна, наподобие NT0000011A). Определить идентификатор местоположения можно в окне свойств элемента дизайна - это последняя компонента в "полном" идентификаторе элемента дизайна. Если выбрана опция Update existing signatures only, "подписываются" только ранее "подписанные" элементы дизайна.
Сравнение схем Pull-Push и Pull-Pull
В широко распространенной конфигурации "hub-spoke" имеется один или несколько серверов, которые являются "поставщиками данных" (hub-серверы), и много серверов, которые занимаются в основном приемом "заказанных ими" данных с hub-серверов, хотя могут также передавать данные на hub-серверы (это spoke-серверы).Преимущества схемы Pull-Push по сравнению с Pull-Pull
При использовании репликаций по схеме Pull-Push существенно упрощается администрирование hub-серверов:
· администратор hub-сервера не планирует связь с каждым spoke-сервером;
· репликатор hub-сервера не вовлечен в репликационные события, инициированные spoke-серверами, тогда как многие spoke-серверы могут одновременно реплицировать данные с hub-сервера.
Схема Pull-Push обычно позволяет более быстро завершить репликационный цикл, т.е. выполнить репликации между hub-сервером и каждым из его серверов-"собеседников" (spoke). При репликациях по схеме Pull-Pull "собеседник" принимает изменения с hub-сервера, а затем репликатор hub-сервера принимает изменения от spoke-сервера. Но в этом случае hub-сервер каждым своим репликатором одновременно может принимать изменения только от одного из "собеседников". При использовании схемы Pull-Push многие spoke-серверы могут одновременно принимать изменения с hub-сервера и "заталкивать" их на hub-сервер.
Недостатки схемы Pull-Push по сравнению с Pull-Pull
Документы Connection будут находиться на разных spoke-серверах. Если таких серверов много и они из разных доменов, может оказаться организационно трудно составить "равномерное" расписание, если только на hub-сервере не имеются реплики адресных книг всех участвующих в репликациях доменов.
Hub-сервер не будет иметь информации о репликационных событиях в своем протоколе работы (LOG.NSF) - с "его точки зрения" имеет место лишь доступ к находящимся на нем базам. Для анализа возможных проблем в конфигурации "hub-spoke" администратор hub-сервера будет вынужден просмотреть большее количество протоколов работы spoke-серверов, чем в случае репликаций по схеме Pull-Pull.
Средства мониторинга серверов Notes
Средства мониторинга позволяют собирать информацию о работе сервера или группы серверов (в пределах одного или нескольких доменов), чтобы помочь администратору в управлении, обнаружении неисправностей и обоснованном планировании расширения всей системы.Логически они включают 3 компоненты:
· Statistics/Alarm Reporter - система сбора статистики и генерации тревог
· Еvent Logger
- система протоколирования событий
· Database Monitor
- система наблюдения за базами данных.
Конструктивно эти средства представлены двумя серверными задачами и двумя базами данных:
· Report - Reporter - задача сбора с заданным интервалом статистики о работе сервера, создания по ней сводных отчетов и доставки статистики и отчетов в базу сбора статистики;
· Event - задача отбора из стандартной очереди событий заданного типа и степени серьезности и протоколирования их заданным способом;
·
- база для управления функционированием всей системы мониторинга серверов (реплика на каждом сервере);
·
Установка средств мониторинга серверов трудностей не вызывает: достаточно с консоли сервера командами Load Report и Load Event запустить обе задачи. Задача Report при первом запуске:
· создает базу STATREP.NSF, если она еще не существует
(по шаблону STATREP.NTF или STATRP45.NTF
с версии 4.5);
· создает базу EVENTS4.NSF, если она еще не существует;
· создает документ Mail-in Database в общей адресной книге.
Задача Event при первом запуске:
· создает базу STATREP.NSF, если она еще не существует;
· создает базу EVENTS4.NSF, если она еще не существует;
· копирует в базу EVENTS4.NSF из общей адресной книги документы ACL Monitor, Replication Monitor, Event и Statistics Monitoring, а также связанные с ними виды (эти документы могли иметься в общей адресной книге, если на сервере, ранее функционировавшем под Notes версий 3.х, были установлены средства мониторинга);
· копирует в базу EVENTS4.NSF из общей адресной книги документ Server данного сервера и преобразует его в документ Servers to Monitor.
Однако настройка и использование средств мониторинга сложнее, чем их установка.
Statistics/Alarm Reporter - система сбора статистики и генерации тревог
Когда на сервере запускается задача Report, она проверяет в базе Statistics & Events наличие документа Server To Monitor и далее использует в своей работе информацию из этого документа. Первоначально документ Server To Monitor создается при первом запуске задачи Event - посредством копирования документа Server из общей адресной книги с добавлением в него некоторых полей со значениями по умолчанию. Впоследствии администратор может модифицировать этот документ или создать вместо него новый.
Рис. 11.1 Пример документа Server To Monitor
В документе задается интервал сбора статистики - поле с меткой Collection interval... - по умолчанию 60 минут, но может варьироваться от 15 до 1440 минут. Кроме того, задается интервал, с которым по документам, содержащим "разовую статистику", создается сводный отчет - поле с меткой Analysis interval:. Поле с меткой Server name: содержит имя сервера, с которого задача Report "снимает статистику". Поле с меткой Report method: определяет способ, которым задача Report должна доставлять статистику в базу сбора (обычно STATREP.NSF). Возможны два варианта:
· Log to Database - протоколирование в базу - задача записывает документ, содержащий статистику, непосредственно в базу сбора;
· Mail-In Database - задача отправляет документ почтой Notes по адресу почтовой базы сбора статистики.
В случае Log to Database, если база сбора статистики находится на сервере получения статистики, в поле с меткой Enter server name: следует выбрать Local - тогда задача будет записывать информацию непосредственно в базу, имя файла которой указано в поле с меткой Database to receive reports:. Если же база сбора статистики находится на другом сервере, но в той же поименованной сети Notes, что и сервер получения статистики, следует указать имя этого сервера. В случае разных поименованных сетей такой способ невозможен - приходится отправлять статистику почтой
по адресу, содержащемуся в вычисляемом поле с меткой Mail- in database address to receive reports:.
При первом запуске задачи Report в общей адресной книге создается документ Mail-In Database, "провозглашающий" созданную этой же задачей базу STATREP.NSF как базу, имеющую собственный почтовый адрес и способную принимать почту. Формат адреса: имя_сервера Statistics/имя_организации. Однако, поскольку база сбора первоначально находится на сервере получения статистики, по умолчанию статистика доставляется в нее способом протоколирования в локальную базу.
Обратите внимание, что все серверы домена, с которых собирается статистика, "несут" реплику базы EVENTS4.NSF. В то же время база STATREP.NSF не обязательно должна присутствовать на каждом из серверов домена - обычно она присутствует только на сервере сбора статистики. Если статистика должна собираться для группы серверов, включая данный, в базе сбора, расположенной на другом сервере, администратору следует удалить STATREP.NSF на данном сервере. Далее, следует оставить в адресной книге только те документы Mail-In Database, которые относятся к серверам, находящимся в разных поименованных сетях с сервером сбора статистики, согласовав в них местонахождение базы сбора статистики. Позвольте напомнить, что понятие "поименованная сеть" определено в пределах одного домена, и, следовательно, в случае разных доменов приходится использовать доставку почтой. Наконец, нужно обеспечить в документах Server to Monitor или правильный почтовый адрес базы STATREP.NSF, или правильный способ протоколирования в эту базу.
В результате задача Report начинает с заданным интервалом создавать в базе сбора статистики документы формы Statistics Report, содержащие весьма подробную информацию о состоянии сервера на момент сбора статистики. Эти документы представлены в группе видов 1. Statistics Reports... базы STATREP.NSF.
Рис. 11.2 Вид в базе STATREP.NSF, содержащий статистику о работе сервера
Ниже приведен пример одного из таких документов. Обратите внимание, что на самом деле там представлена не вся информация из документа Statistics Report. Как видно из Рис. 11.2, в базе имеется пять видов, в каждом из которых один и тот же документ Statistics Report "отображается" по разной форме, с представлением информации из тех или иных групп полей.
Data file path: f:\notes400\data
Swap file path: Not Applicable
Number of processors: 1
Processor type: Intel Pentium
Server Load Statistics:
Transactions in last minute: 8
Peak transactions per minute: 1 413
Time of last peak transactions per minute: 30.01.97 11:37:13
Total transactions processed: 15 118
Number of current users: 12
Peak number of users: 13
Time of last peak number of users: 30.01.97 13:22:26
Number of sessions dropped in mid-transaction: 0
Number of server tasks: 19
Server Tasks:
Database Server: Perform console commands
Database Server: Listen for connect requests on TCPIP
Database Server: Listen for connect requests on LAN4
Database Server: NetBIOS name server for LAN4
Database Server: Cluster Manager is idle
Database Server: Perform housekeeping chores
Database Server: Idle task
Database Server: Server for Andre A. Linev/InterTrustCorp/SU on LAN4
Database Server: Server for InterTrust/InterTrustCorp/SU on TCPIP
Database Server: Server for Vladimir A. Panov/InterTrustCorp/SU on TCPIP
Database Server: Server for Oleg G. Taranchenko/InterTrustCorp/SU on LAN
Database Server: Server for session B87000E on TCPIP
Database Server: Server for Nikolay N. Iontsev/InterTrustCorp/SU on TCPI
Database Server: Server for Oleg G. Taranchenko/InterTrustCorp/SU on LAN
Database Server: Server for InterTrust/InterTrustCorp/SU on TCPIP
Database Server: Server for Vladimir A. Panov/InterTrustCorp/SU on LAN4
Database Server: Server for NotesSrv400/InterTrustCorp/SU on TCPIP
Database Server: Server for Pavel A. Puchkov/InterTrustCorp/SU on LAN4
Database Server: Server for Alexander M. Savelyev/InterTrustCorp/SU on T
HTTP Web Server: Ready
Indexer: Updating views in mail\ALinev.nsf
SMTPMTA oseshlr0: Idle
WEB Retriever: Process(3): Idle
WEB Retriever: Process(2): Idle
SMTPMTA iseshlr0: Idle
SMTPMTA drt: Idle
SMTPMTA isesctl: Listening on SMTP port 25
SMTPMTA imsgcnv: Idle
SMTPMTA osesctl: Idle
Cluster Replicator: Idle
SMTPMTA omsgcnv: Idle
Event: Idle
Cluster Directory: Idle
Query/Set Handler: Idle
Reflector Agent: Idle
SMTPMTA: Idle
Cluster Directory: Idle
Cluster Replicator: Idle
WEB Retriever: Process(1): Idle
Reporter: Idle
Calendar Connector: Idle
Schedule Manager: Idle
Admin Process: Idle
Agent Manager: Executive '1': Idle
Agent Manager: Idle
Indexer: Updating cldbdir.nsf view '($Pathname)'
Router: Idle
Replicator: Idle
Replicator: Idle
Event Interceptor: Idle
Replication Statistics:
Number of successful replications: 278
Number of replication failures: 133
Number of documents deleted: 357
Number of documents added: 1 065
Number of documents updated: 870
Database Statistics (in bytes):
Buffer control pool used: 91 204
Buffer control pool peak size: 196 218
Buffer pool maximum: 6 291 456
Buffer pool used: 6 264 804
Buffer pool peak: 6 336 000
Extension manager pool used:
Extension manager pool peak:
NSF pool used: 176 468
NSF pool Peak: 327 030
Stats Package Statistics:
Time started: 30.01.97 09:36:37
Agent Statistics:
Hourly agent scheduled runs: 0
Hourly agent triggered runs: 1
Hourly agent unsuccessful runs:
Hourly agent used run time: 13 Seconds
Hourly agent access denials: 0
Daily agent scheduled runs:
Daily agent triggered runs:
Daily agent unsuccessful runs:
Daily agent used run time:
Daily agent access denials:
Хотя в базе STATREP.NSF имеются и другие виды, в том числе "пытающиеся" представить все получаемое "море" информации в псевдографическом виде, всю информацию проанализировать трудно, да и это попросту ненужно.
Вы можете предварительно описать только ситуации, которые действительно достойны вашего внимания - "ситуации, вызывающие тревогу". Для этого в базе Statistics & Events создаются документы Statistic Monitor.
Рис. 11.3 Пример документа Statistics Monitor для контроля свободного пространства на диске
В документе Statistic Monitor содержится следующее.
· Enabled/Disabled:
-
задаче Report разрешено/запрещено "интерпретировать" этот документ.
· Server name:
- имя сервера или список имен серверов, на которые распространяется действие документа.
· Statistic name: - название параметра, значение которого рассматривается при решении вопроса о возникновении тревоги. Эти названия выбираются из списка ключевых слов, который строится по формуле @DbColumn(""; ""; "($Statistics)"; 1) из скрытого вида ($Statistics). Для понимания смысла параметров лучше просмотреть виды 5. Names & Messages\Thresholds и 5. Names & Messages\Statistics Names и, для заинтересовавших вас параметров, соответствующие документы из этих видов.
· Threshold operator: - операция, выполняемая при проверке значения параметра - Less that - меньше чем, Greater that - больше чем, Multiple of - кратно.
· Threshold value: - значение, с которым сравнивается значение параметра.
· Event severity:
- степень серьезности события типа Statistics, возникающего при выполнении условия.
· Comments:
и Description: комментарии и описание - вычисляемые поля. Они пересчитываются по нажатию клавиши F9 или при сохранении документа.
Рис. 11.4 Пример документа Statistics Monitor для контроля наличия "мертвой" почты
Рис. 11.5 В виде представлены все ситуации, "вызывающие тревогу"
Например, согласно документу Statistic Monitor на Рис. 11.3 ситуация, "вызывающая тревогу", возникает, если на диске F
заданного сервера стало меньше 40 Мб свободного пространства. Согласно документу на Рис. 11.4 ситуация, "вызывающая тревогу", возникает, когда на одном из серверов в базе MAIL.BOX появилась "мертвая" почта.
Все, что вы определили, как ситуации, "вызывающие тревогу", будет представлено в виде 3. Statistic\Monitors базы Statistics & Events (Рис. 11.5).
В соответствии с выполненными настройками задача Report при обнаружении "тревожных ситуаций" будет генерировать события типа Statistics заданной степени серьезности. Эти события будут поступать в стандартную очередь событий сервера. Что происходит далее? Задача Event анализирует стандартную очередь событий, отбирает те из них, на которые "ей предписано реагировать", и соответствующим образом протоколирует их. События типа Statistics
обычно протоколируются в базу сбора статистики. В итоге в виде Alarms
базы STATREP.NSF (Рис. 11.6) при возникновении "тревожных ситуаций" станут появляться документы
Alarm (Рис. 11.7).
Рис. 11.6 Вид Alarms содержит документы, описывающие события, "вызвавшие тревогу"
Рис. 11.7 Пример документа Alarm - в MAIL.BOX появилась "мертвая" почта
В результате количество информации, которое вам действительно необходимо просмотреть в базе STATREP.NSF, существенно сократится.
Кроме того, открыв документ Alarm, вы можете кнопкой Create Trouble Ticket создать связанный с ним новый документ - Alarm Trouble Ticket - "карточку аварийной ситуации". По смыслу документ Alarm Trouble Ticket является заданием администратору сервера, на котором возникла неисправность, на ее устранение. Документ Trouble Ticket может быть как сохранен в базе STATREP.NSF, так и направлен письмом (кнопкой Mail Trouble Ticket) тому администратору, которому надлежит устранить возникшую неисправность. Сохраненные документы Trouble Ticket содержатся в базе STATREP.NSF в виде 6. Trouble Tickets\1. Alarm.
Рис. 11.8 Пример "карточки аварийной ситуации"
Стоимость соединения и стоимость маршрута
Стоимость соединения (длина дуги графа) - относительная величина затрат на пересылку данных по данному соединению. Стоимость соединения задается целым числом в диапазоне от 1 до 10, причем 1 трактуется как "самое дешевое", а 10 как "самое дорогое". Например, соединение типа Local Area Network имеет по умолчанию стоимость 1, а соединение типа Dialup Modem имеет по умолчанию стоимость 5, т.е. почта "равноценно" может быть передана через до 5 соединений по локальной сети вместо передачи через одно модемное соединение.Администратор Notes может изменить стоимость соединения в поле с меткой Routing cost: документа Connection из адресной книги. Однако задавать значения, существенно отличающиеся от значений по умолчанию, следует обдуманно и с осторожностью.
Стоимость маршрута (длина пути на графе) определяется как сумма стоимостей каждого соединения в маршруте. Если, например, маршрут содержит два соединения, одно со стоимостью 10 и другое со стоимостью 1, общая стоимость маршрута - 11.
Платформа
| Платформа | AIX | HP-UX | NetWare | OS/2 | |
| Сертифицированная версия операционной системы | AIX 4.1.4 AIX 4.1.3 | HP-UX 10.01 | NetWare 3.12, NetWare 4.1 | OS/2 Warp, Warp Connect, OS/2 2.11 SMP | |
| Поддерживаемые процессоры | PowerPC Power2 | PA-RISC | Intel x86, Pentium | Intel 486, Pentium | |
| Поддержка SMP | Да | Да | Нет | Да | |
| Требования к компьютеру | RAM | 64 Mb минимум 96 Mb или больше рекомендуется | 64 Mb минимум 96 Mb или больше рекомендуется | 64 Mb минимум 96 Mb или больше рекомендуется | 32 Mb минимум 48 Mb или больше рекомендуется |
| Disk space | 300 Mb минимум 500 Mb или больше рекомендуется | 300 Mb минимум 500 Mb или больше рекомендуется | 300 Mb минимум 500 Mb или больше рекомендуется | 300 Mb минимум 500 Mb или больше рекомендуется | |
| Платформа | AIX | HP-UX | NetWare | OS/2 | |
| Disk swap space | 128 Mb | 128 Mb | Не используется OS | 16 Mb | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Да | Да |
| SPX | Да | Да | Да | Да | |
| SPX II | Нет | Да | Да | Нет | |
| NetBIOS/NetBEUI | Нет | Нет | Нет | Да | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Нет | Нет | Да | |
| X.PC | Да | Да | Да | Да | |
| X.25* | Нет | Нет | Нет | Да | |
| SNA* | Нет | Нет | Нет | Да |
| Платформа | Solaris | Windows 95 | Windows NT | |
| Сертифицированная версия операционной системы | Solaris 2.5 Solaris 2.4 | Windows 95 | Windows NT Server 3.51 | |
| Поддерживаемые процессоры | Intel x86, Pentium SPARC | Intel 486, Pentium | Intel 486, Pentium DEC Alpha | |
| Поддержка SMP | Да | Нет | Да | |
| Требования к компьютеру | RAM | 64 Mb минимум 96 Mb или больше рекомендуется | 16 Mb минимум 24 Mb или больше рекомендуется | 48 Mb минимум 64 Mb или больше рекомендуется |
| Disk space | 300 Mb минимум 500 Mb или больше рекомендуется | 150 Mb минимум 300 Mb или больше рекомендуется | 300 Mb минимум 500 Mb или больше рекомендуется | |
| Disk swap space | 128 Mb | 16 Mb | 64 Mb | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Да |
| SPX | Да | Да | Да | |
| SPX II | Да | Нет | Да | |
| NetBIOS/NetBEUI | Нет | Да | Да | |
| TCP/IP | Да | Да | Да | |
| VINES | Нет | Нет | Да | |
| X.PC | Да | Да | Да | |
| X.25* | Нет | Нет | Да | |
| SNA* | Нет | Нет | Да |
Содержание Назад Вперед
Требования для серверов версии (Domino)
| Платформа | AIX | HP-UX | NetWare | OS/2 | |||||||
| Сертифицированная версия операционной системы | AIX 4.1.4 AIX 4.2 | HP-UX 10.01 | NetWare 3.12, NetWare 4.1 | OS/2 Warp Server 4 (Entry, Advanced, и с поддержкой SMP), Warp Connect | |||||||
| Поддерживаемые процессоры | PowerPC, POWER, POWER2 | PA-RISC | Intel x86, Pentium | Intel 486, Pentium | |||||||
| Поддержка SMP | Да | Да | Нет | Да | |||||||
| Требования к компьютеру | RAM | 64 Mb минимум; 128 Mb или более рекомендуется | 64 Mb минимум; 128 Mb или более рекомендуется | 48 Mb минимум (64 польз.); 56 Mb минимум (128 польз.); 96 Mb или более рекомендуется | 32 Mb минимум; 48 Mb или более рекомендуется | ||||||
| Платформа | AIX | HP-UX | NetWare | OS/2 | |||||||
| Disk space | 300 Mb минимум; 500 Mb или более рекомендуется | 300 Mb минимум; 500 Mb или более рекомендуется | 300 Mb минимум; 500 Mb или более рекомендуется | 300 Mb минимум; 500 Mb или более рекомендуется | |||||||
| Disk swap space | 128 Mb | 128 Mb | Не используется OS | 16 Mb | |||||||
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Да | Да (Нет для SMP) | ||||||
| SPX * | Да | Да | Да | Да (Только для Warp Connect)** | |||||||
| SPX II | Да | Нет | Да | Нет | |||||||
| NetBIOS/NetBEUI | Нет | Нет | Нет | Да (Novell NetBIOS только для Warp Connect)** | |||||||
| TCP/IP | Да | Да | Да | Да | |||||||
| VINES | Нет | Нет | Нет | Да (Нет для SMP) | |||||||
| X.PC | Да | Да | Да | Да | |||||||
| X.25 | Нет | Нет | Нет | Да | |||||||
| SNA | Нет | Нет | Нет | Да |
| Платформа | Solaris | Windows 95 | Windows NT | ||||||
| Сертифицированная версия операционной системы | Solaris 2.5, Solaris 2.5.1 (SPARC, Ultra SPARC) | Windows 95 | Windows NT Server 3.51, 4.0, Windows NT Workstation 3.51, 4.0 *** | ||||||
| Поддерживаемые процессоры | Intel x86, Pentium (Intel Edition), SPARC, Ultra SPARC | Intel 486, Pentium | Intel 486, Pentium, Digital Alpha | ||||||
| Поддержка SMP | Да | Нет | Да | ||||||
| Требования к компьютеру | RAM | 64 Mb минимум; 128 Mb или более рекомендуется | 16 Mb минимум; 24 Mb или более рекомендуется | 32 Mb минимум; 48 Mb или более рекомендуется | |||||
| Disk space | 300 Mb минимум; 500 Mb или более рекомендуется | 150 Mb минимум; 300 Mb или более рекомендуется | 300 Mb минимум; 500 Mb или более рекомендуется | ||||||
| Disk swap space | 128 Mb | 16 Mb | 64 MB | ||||||
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Да (Нет для 4.0) | |||||
| SPX | Да | Да | Да | ||||||
| SPX II | Да | Нет | Да | ||||||
| NetBIOS/NetBEUI | Нет | Да | Да | ||||||
| TCP/IP | Да | Да | Да | ||||||
| Платформа | Solaris | Windows 95 | Windows NT | ||||||
| VINES | Нет | Нет | Да (Нет для Digital Alpha или SMP) | ||||||
| X.PC | Да | Да | Да | ||||||
| X.25 | Нет | Нет | Да | ||||||
| SNA | Нет | Нет | Да |
*) Возможности Domino Advanced Services (кластеры и partitioned-серверы) в версии 4.5 не поддерживают протокол IPX/SPX. В настоящее время фирма Lotus не планирует обеспечивать поддержку IPX/SPX для будущих версий Domino Advanced Services.
**) Протоколы SPX и Novell NetBIOS не поддерживаются на платформе Warp Server, поскольку фирма Novell пока не сертифицировала эту платформу.
***) Для платформы Windows NT версии 3.51 необходим Service pack 5, версии 4.0 - Service pack 1 или старше.
Учтите, что рассмотренные требования изменяются каждые 2-3 месяца.
Сертифицированная версия операционной системы
| Платформа | AIX | HP-UX | OS/2 | Macintosh | |
| Сертифицированная версия операционной системы | AIX 4.1.4 AIX 4.1.3 | HP-UX 10.01 | OS/2 Warp, Warp Connect | Mac System 7.5, System 7.1 (680x0 только) | |
| Поддерживаемые процессоры | PowerPC Power2 | PA-RISC | Intel 486, Pentium | Motorola 68030, 68040 PowerPC | |
| Требования к компьютеру | RAM | 24 Mb минимум 32 Mb или больше рекомендуется | 24 Mb минимум 32 Mb или больше рекомендуется | 8 Mb минимум 12 Mb или больше рекомендуется | 12 Mb минимум для 680x0, 16 Mb минимум для PowerPC, 20 Mb или больше рекомендуется для обоих |
| Disk space | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Нет | Да |
| SPX | Да | Да | Да | Нет | |
| SPX II | Нет | Да | Нет | Нет | |
| NetBIOS/NetBEUI | Нет | Нет | Да | Нет | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Нет | Да | Нет | |
| X.PC | Да | Да | Да | Да | |
| X.25* | Нет | Нет | Нет | Нет | |
| SNA* | Нет | Нет | Нет | Нет |
| Платформа | Solaris | Windows 3.1 | Windows 95 | Windows NT | |
| Сертифицированная версия операционной системы | Solaris 2.5 Solaris 2.4 | Windows 3.1 | Windows 95 | Windows NT Workstation 3.51 | |
| Поддерживаемые процессоры | Intel x86, Pentium SPARC | Intel 386 или старше | Intel 386 или старше | Intel x86, Pentium DEC Alpha | |
| Требования к компьютеру | RAM | 24 Mb минимум 32 Mb или больше рекомендуется | 6 Mb минимум 8 Mb или больше рекомендуется | 8 Mb минимум 12 Mb или больше рекомендуется | 16 Mb минимум, 20 Mb или больше рекомендуется |
| Disk space | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Нет | Нет |
| SPX | Да | Да | Да | Да | |
| SPX II | Да | Нет | Нет | Да | |
| NetBIOS/NetBEUI | Нет | Да | Да | Да | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Да | Да | Да | |
| X.PC | Да | Да | Да | Да | |
| X.25* | Нет | Нет | Нет | Нет | |
| SNA* | Нет | Нет | Нет | Нет |
Содержание Назад Вперед
Disk space
| Платформа | AIX | HP-UX | OS/2 | Macintosh | |
| Сертифицированная версия операционной системы | AIX 4.1.4 AIX 4.2 | HP-UX 10.01 | OS/ 2 Warp 3, Warp 4, Warp Connect | System 7.5 | |
| Поддерживаемые процессоры | PowerPC, POWERTM, POWER2TM | PA-RISC | Intel 486, Pentium | Motorola 68030, 68040, PowerPC | |
| Требования к компьютеру | RAM | 32 Mb минимум; 64 Mb или более рекомендуется | 32 Mb минимум; 64 Mb или более рекомендуется | 16 Mb минимум; 32 Mb или более рекомендуется | 12 Mb минимум для 680x0, 16 Mb минимум для PowerPC; 20 Mb или более рекомендуется для обоих |
| Disk space | 100 Mb минимум; 110 Mb или более рекомендуется | 100 Mb минимум; 110 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Нет | Yes |
| SPX | Да | Да | Да | Нет | |
| SPX II | Да | Нет | Нет | Нет | |
| NetBIOS/NetBEUI | Нет | Нет | Да | Нет | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Нет | Да | Нет | |
| X.PC | Да | Да | Да | Да | |
| X.25 | Нет | Нет | Нет | Нет | |
| SNA® | Нет | Нет | Нет | Нет | |
| MacTCP | Нет | Нет | Нет | Да |
| Платформа | Solaris | Windows 3.1 | Windows 95 | Windows NT | |
| Сертифицированная версия операционной системы | Solaris 2.5, Solaris 2.5.1 (SPARC, Ultra SPARC) | Windows 3.1 | Windows 95 | Windows NT Workstation 3.51, 4.0 | |
| Поддерживаемые процессоры | Intel 486, Pentium (on Intel Edition platform); SPARC, UltraSPARC | Intel x86, Pentium | Intel x86, Pentium | Intel x86, Pentium, Digital Alpha | |
| Требования к компьютеру | RAM | 32 Mb минимум; 64 Mb или более рекомендуется | 8 Mb минимум; 12 Mb или более рекомендуется | 8 Mb минимум; 12 Mb или более рекомендуется | 16 Mb минимум; 20 Mb или более рекомендуется |
| Disk space | 100 Mb минимум; 110 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Нет | Нет |
| SPX | Нет | Да | Да | Да | |
| SPX II | Да | Нет | Нет | Да | |
| NetBIOS/NetBEUI | Нет | Да | Да | Да | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Да | Да | Да | |
| X.PC | Да | Да | Да | Да | |
| X.25 | Нет | Нет | Нет | Нет | |
| SNA | Нет | Нет | Нет | Нет |
Содержание Назад Вперед
Удаление пользователя
Если задача Administration Process полностью настроена, следует открыть в общей адресной книге вид People и, выбрав документ Person удаляемого пользователя, нажать кнопку Delеte Person, а в появившихся трех диалоговых окнах выбрать соответственно Yes, вариант удаления почтового ящика и Ok, No. Обычно задача Administration Process выполняет удаление хотя и медленнее, но (только не обижайтесь) корректнее вас.
Рис. 8.20 Диалоговые окна при удалении пользователя с применением задачи Administration Process
При удалении "вручную" можно поступить так.
· Удалите документ Person этого пользователя из общей адресной книги и почтовый ящик пользователя с сервера.
· Запретите этому пользователю доступ ко всем серверам. Лучше заранее "заготовить" группу Terminations и включить ее в списки управления доступом на всех серверах.
· Реплицируйте адресную книгу на все серверы командой Replicate
<имя сервера> NAMES.NSF.
Удаление "повисших ссылок" из ПЯ пользователей
В случае сбоев в СПЯ могут быть потеряны некоторые документы - тела сообщений. Если это произойдет, ПЯ пользователей еще будут содержать заголовки сообщений, ссылающиеся на "потерянные" тела сообщений в СПЯ. Пользователи не смогут эти "тела" прочитать - их уже нет в СПЯ. Чтобы удалить из ПЯ пользователя такие "ссылки в никуда", используют команду консолиLoad Object Collect USERMAIL.NSF ,
где USERMAIL.NSF - имя файла почты пользователя.
Если сообщение найдено в ПЯ и ссылается на СПЯ, но соответствующее тело сообщения в СПЯ не найдено, такое сообщение удаляется из ПЯ. Если реплика ПЯ на другом сервере содержит удаленное сообщение, сообщение может быть восстановлено в этом ПЯ при последующей репликации с тем сервером.
Удаление сообщений из СПЯ
В конце концов все получатели удаляют сообщение, и в СПЯ не требуется больше хранить его тело. Функция Collect, выполняющаяся по умолчанию в 2 часа ночи, удаляет тела ставших ненужными сообщений из СПЯ.Чтобы запустить функцию Collect вручную, введите на консоли команду
Load Object Collect SHARED.NSF .
Если имеется несколько СПЯ, вам потребуется настроить запуск функции Collect для каждого из них по расписанию.
Чтобы удалить из СПЯ ненужные тела сообщений после того, как вы, не учтя сказанного ранее, удалили ПЯ пользователя, используйте команду консоли
Load Object Collect -Force SHARED.NSF .
Когда вы вводите опцию -Force, а функция Collect не может найти и открыть ПЯ (ибо вы его удалили), Collect ведет себя так, как будто все сообщения в ПЯ были удалены. В результате из СПЯ будут удалены все тела сообщений, которые использовались отсутствующим ПЯ, но никакими другими ПЯ.
Будьте осторожны. Использовать эту опцию следует только тогда, когда ПЯ был удален и никакой его резервной копии нет, так что вам остается только возможность освободить дисковое пространство в СПЯ, используемое телами сообщений из удаленного ПЯ. Когда вы используете опцию -Force, вы рискуете "заодно" удалить и тела сообщений, связанных с ПЯ, которые в данный момент оказались только временно недоступными. Поэтому убедитесь, что все другие ПЯ, имеющие тела сообщений в СПЯ, являются доступными.
Удаление СПЯ
Прежде, чем удалять СПЯ, необходимо отсоединить все ПЯ от него - только это позволит сохранить "полные сообщения" во всех ПЯ. Для отсоединения используется командаLoad Object Unlink SHARED.NSF ,
где SHARED.NSF - имя СПЯ. Для отсоединения одного ПЯ используется команда
Load Object Unlink USERMAIL.NSF ,
где USERMAIL.NSF
- имя ПЯ.
Установка и обслуживание Shared Mail
Установка на сервере Shared Mail - "совместно используемого почтового ящика" (СПЯ) - позволяет экономить дисковую память. Предположим, нескольким получателям, почтовые ящики которых находятся на этом сервере, приходит одно и то же сообщение. Вместо того чтобы помещать копию всего сообщения в почтовый ящик каждого получателя, в почтовые ящики получателей добавляется только заголовок сообщения со ссылкой на тело сообщения, а тело сообщения (содержимое поля Body типа Rich Text, включая имеющиеся в нем присоединенные файлы и объекты) помещается в совместно используемый почтовый ящик. Например, если тело сообщения имеет размер 1 Мб, а сообщение адресовано 10 получателям на этом сервере, будет сэкономлено около 9 Мб памяти. В то же время для пользователя такое хранение его сообщения остается "полностью прозрачным". Когда пользователь открывает сообщение, заголовок активизирует связь с телом сообщения, сохраненным в СПЯ. Notes "показывает" получателю сообщение точно так же, как если бы все сообщение было целиком в почтовом ящике пользователя. Если пользователь удаляет такое сообщение, Notes удаляет только заголовок из почтового ящика пользователя, а тело сообщения остается в СПЯ, но связанный с телом сообщения счетчик ссылок уменьшается на единицу. После того, как все получатели на этом сервере удалили это сообщение из своих почтовых ящиков, счетчик ссылок на тело сообщения становится равным нулю, серверная задача Object, которая по умолчанию запускается с параметром Collect в 2 часа ночи, удаляет уже более никому не нужное тело сообщения из СПЯ.Но при очевидном преимуществе Shared Mail администратору следует помнить, что ее применение сопряжено с регулярным резервным копированием СПЯ, а на время копирования придется останавливать сервер. Без регулярного копирования может случиться серьезная "беда" - ведь потеря СПЯ равнозначна потере сразу всех пользовательских почтовых ящиков этого сервера.
Первичная установка Shared Mail
происходит при передаче задаче Mail Router соответствующей команды. Все последующие работы по сопровождению и настройке совместно используемой почты администратор выполняет с использованием серверной задачи Object store manager - Object.
Установка программного обеспечения станций
Для минимизации усилий администратора по установке программного обеспечения станций рекомендуется попросту скопировать соответствующий дистрибутив с дистрибутивного лазерного диска на файл-сервер.Тогда администратор на компьютере пользователя "входит в сеть" и из сетевого каталога запускает программу INSTALL.EXE, выполняющую копирование файлов и создание группы с пиктограммой программы станции. По завершении работы INSTALL.EXE следует выполнить выбор соответствующих стране и используемому языку таблиц перекодировки и сортировки, как это описано в 2.2.4. Затем запускают программу станции. Обнаружив, что файл NOTES.INI "почти пуст", программа станции "задает ряд вопросов".
В первом диалоговом окне выбирается тип соединения станции с сервером: по локальной сети, с использованием модема, по локальной сети и с использованием модема, нет соединения. Если ID пользователя имеется в файле, выбирают опцию Your Notes user ID has been supplied to you in file. Если эта опция не выбрана, предполагается, что ID пользователя хранится в адресной книге сервера или, если станция вообще не имеет соединения с сервером, отсутствует.
Рис. 2.33 Четыре варианта установки станции
Если ID пользователя был предоставлен в файле, потребуется "указать" этот файл. Тогда имя пользователя будет определено из ID-файла, так что поле Your user name: во втором диалоговом окне будет "серым". Если же ID пользователя хранится в адресной книге сервера, придется ввести имя пользователя. Тогда по этому имени в адресной книге будет найден документ Person, а из него, после ввода соответствующего пароля, извлечен ID-файл.
Рис. 2.34 Если сервер доступен по локальной сети
Если сервер доступен станции только по локальной сети, потребуется ввести имя сервера и выбрать сетевой протокол, используемый для доступа станции к нему. Учтите, что при этом предполагается, что на компьютере, на котором устанавливается станция Notes, предварительно была обеспечена поддержка и выполнена проверка функционирования этого сетевого протокола.
Рис. 2.36 Переключение текущего местоположения на панели состояния станции
Рис. 2.37 Пример документа Location из адресной книги пользователя (фрагмент)
Поле с меткой Passthru server: может содержать имя сервера, по умолчанию предоставляющего станции пользователя в данном местоположении посреднические услуги для доступа к другому серверу, по каким-то причинам не доступному станции для прямого соединения. Обратите внимание, что сервер-посредник по умолчанию в одном местоположении может быть только один. Если же пользователю необходимо получать доступ к разным серверам через разные серверы-посредники, придется поработать "вручную" над пользовательской адресной книгой - в ней для каждого вызываемого сервера нужно создать документ Connection типа Passthru Server через соответствующий сервер-посредник на необходимый сервер. Альтернатива - создать несколько документов Location, но каждый с одним сервером-посредником по умолчанию.
Имейте в виду, что "от станции пользователя до сервера назначения" принципиально может быть не более 10 hop's ("прыжков" или "перегонов"). "Перегон" соответствует одной дуге в графе, начальной вершиной которого является станция, а конечной вершиной - сервер назначения. А рекомендуется использовать не более 4-х "перегонов", поскольку ретрансляция требует выделения каждым сервером определенных ресурсов.
Вторым видом документов из персональной адресной книги, в создании которых администратор может оказать помощь пользователю, является документ Connection ("Соединение"). Документ содержит информацию о способе установления соединения станции с сервером. Мы не станем здесь подробно рассматривать этот документ. Его рассмотрению, но применительно к общей адресной книге, уделяется много места в 4.1.1. Различия же между документами Connection из персональной и общей адресных книг весьма незначительны. Отметим только, что документы Connection в персональной адресной книге приходится создавать, если станция соединяется с сервером по протоколу TCP/IP (должен быть указан IP-сервера), по модему (должен быть задан телефонный номер модема на сервере), с использованием сервиса удаленного доступа к локальной сети и в некоторых других "нетрадиционных" случаях.
Установка сервера
Процесс установки в большей или меньшей степени зависит от операционной системы (Windows 95, Windows NT, OS/2, NetWare, Unix), для которой предназначен и под которой устанавливается сервер Lotus Notes. Менее всего различий встречается при установке серверов Notes на платформах Windows 95/NT и OS/2. Наибольшее количество особенностей присуще установке сервера Notes на платформе Novell NetWare.Мы рассмотрим установку сервера Lotus Notes для Windows 95 - Windows NT (32-x разрядный), стремясь при этом обращать основное внимание на присущие всем платформам общие моменты, а не на конкретные особенности.
Установка начинается запуском с дистрибутива программы INSTALL.EXE (INSTPM.EXE для OS/2), которая выполняет по сути, только копирование необходимых файлов с дистрибутива в соответствующие каталоги на винчестере и создание группы с двумя (Windows NT 4.0) или тремя (Windows NT 3.51) пиктограммами (Рис. 2.1 - Рис. 2.4).
Рис. 2.1 Выбраны "ручная установка" и каталоги программ и данных Notes
В окне Install Options выбирают установку сервера (Server Install или Manual Install) и задают два каталога: Notes Program Folder - каталог программ Notes (в него будут скопированы выполняемые файлы, библиотеки динамической компоновки и файлы с расширением .cls) и Notes Data Folder - каталог данных Notes (в него будут скопированы базы, шаблоны баз, файлы с расширением .mdm и т.п.).
В окне Customize (если было выбрано Manual Install) можно более подробно отобрать копируемые компоненты.
Рис. 2.2 Выбран "минимальный набор" для установки сервера; обычно документация тоже устанавливается на сервер, чтобы не хранить ее на станциях
При установке сервера должны быть выбраны опции:
· Notes Workstation - станция администратора, устанавливаемая на компьютере сервера
· Lotus Domino Server - собственно сервер Notes
· Personal Data Files
и Additional Templates - файлы данных и дополнительные шаблоны для создания баз
· Documentation Databases, Notes Release 4 Help и Notes Help Lite - обычно вся документация, чтобы не устанавливать ее на станциях пользователей
· Attachments Viewer - программное обеспечение для просмотра присоединенных файлов на станции, выбирается по желанию администратора.
Далее следуют опции, присущие Notes версий от 4.5 и зависящие от платформы:
· Java support files - программное обеспечение для запуска Java-апплетов на станции в базе данных Web Navigator
· Domino Action Templates - шаблоны, необходимые для работы Domino.Action - программного обеспечения для управления Web-сервером Domino
· Single Password Login - программное обеспечение (сервис), позволяющее на компьютере под Windows NT "автоматически вводить" пароль для Windows NT в качестве пароля для Notes
· Notes Service Install - программное обеспечение для установки сервера Notes как сервиса Windows NT
· Notes Performance Monitor - программное обеспечение для добавления объекта Domino Server в приложение Performance Monitor (в Windows NT)
· User Synchronization - библиотеки динамической компоновки, "добавляющие" в приложение User Manager for Domains (Windows NT) дополнительный пункт меню Notes и позволяющие при регистрации пользователя Windows NT одновременно зарегистрировать его и как пользователя Notes, обычно с таким же паролем, как для Windows NT.
Рис. 2.3 Закладка Advanced Services
На закладке Advanced Services выбираются дополнительные возможности, поддерживаемые в Notes только с версии 4.5. Формально для использования этих возможностей должны приобретаться лицензии Lotus Domino Advanced Services.
Программное обеспечение Domino Partitioned Server
позволяет одновременно выполнять несколько серверов Notes на одном физическом компьютере. Эта возможность может быть полезна для провайдеров услуг Notes, поскольку позволяет сократить число компьютеров, необходимых для функционирования большого количества серверов Notes, которые занимаются в основном операциями, не требующими больших вычислительных ресурсов, например, только передачей почты.
Несколько серверов Notes (до 6) может быть "объединено" в кластер. Репликации баз данных между серверами кластера происходят "почти" в реальном времени, имеется возможность осуществлять балансировку загрузки серверов кластера (load balancing) и "на лету" переключать обращения пользователей к реплике базы на нефункционирующем или "сильно загруженном" сервере кластера на ее реплику на другом сервере кластера (failover).
Возможности по составлению счетов (billing features) позволяют создавать собственные приложения для составления всевозможных отчетов, например, о величине почтового трафика пользователей, организаций, доменов;
об использовании баз данных или даже определенных документов в базах; о затратах времени на выполнение агентов.
Для установки программного обеспечения поддержки кластеров и составления счетов выберите "Advanced Services" и "Advanced Services Data". При установке первого partitioned-сервера на компьютере необходимо выбрать все три возможности.
Рис. 2.4 После копирования файлов программа инсталляции создает группу с двумя пиктограммами (Windows NT 4.0)
По завершении работы программы INSTALL.EXE "самое подходящее время" выполнить выбор соответствующих стране и используемому языку таблиц перекодировки и сортировки, как это описано в 2.2.4. Затем запускают программу станции - пиктограмма с названием Lotus Notes Client (а не Lotus Domino Server). Обнаружив, что файл NOTES.INI "почти пуст", программа станции "задает ряд вопросов". Именно в диалоговых окнах этой программы при ее первом запуске и выполняется дальнейшая настройка сервера.
Наиболее часто встречаются следующие 3 варианта установки сервера:
· первый сервер в организации - создается адресная книга нового домена и ID-файлы сертификатора организации, сервера и его администратора
· очередной сервер в том же домене той же организации - адресная книга реплицируется с существующего сервера этого домена, ID-файлы сервера и его администратора должны быть подготовлены предварительно
· первый сервер в новом домене той же организации - создается адресная книга нового домена, ID-файлы сервера и его администратора должны быть подготовлены предварительно.
Рис. 2.5 Первый или очередной сервер в домене
В первом диалоговом окне при установке возможны только два выбора:
· The first Lotus Notes Server in your organization (Первый сервер в вашей организации)
влечет создание нового домена и установку первого сервера в этом домене. При последующих выборах следует дополнительно уточнить, устанавливается ли первый сервер в организации (тогда происходит создание ID-файла сертификатора организации CERT.ID) или устанавливается первый сервер в новом домене той же организации (при этом не создается ID-файл сертификатора организации).
· An additional Lotus Notes Server in your organization (Дополнительный сервер в вашей организации) влечет добавление нового сервера к существующему домену.
Установка Shared Mail - создание
Для установки Shared Mailна сервере - создания совместно используемого почтового ящика и "разрешения" его использования сервером - во-первых, убедитесь, что запущена задача Mail Router и, во-вторых, передайте ей команду Use SHARED.NSF, набрав на консоли:
Tell Router Use SHARED.NSF ,
где SHARED.NSF - полное имя файла СПЯ, включая каталог, если это необходимо, например, MAIL/Shared.nsf. В ответ на эту команду задача Mail Router создает соответствующую базу и добавляет в файл NOTES.INI переменную Shared_Mail=2, что и является разрешением использовать СПЯ при доставке и передаче почты на этом сервере. Дополнительно при этом на сервере в каталоге данных Notes автоматически создается "база" MAILOBJ.NSF, являющаяся файлом-ссылкой, всегда указывающей на файл текущего СПЯ.
Если Shared_Mail=2, то задача Mail Router помещает в СПЯ тела всех сообщений, которые адресованы пользователям этого сервера (даже если сообщение было адресовано только одному пользователю). Кроме того, сообщения из MAIL.BOX этого сервера, предназначенные для передачи на другой сервер, так же хранятся "раздельно": заголовки в MAIL.BOX, а тела в СПЯ.
Если Shared_Mail=1, задача Mail Router помещает в СПЯ только тела тех сообщений, которые адресованные двум или более пользователям этого сервера. По мнению автора, это наиболее рациональный полезный вариант.
Наконец, если Shared_Mail=0, то возможность вообще не используются.
Установление подлинности (процедура аутентификации)
Процесс установления подлинности (процедура аутентификации) включает четыре этапа:· установление сервером доверия к публичному ключу клиента (станции, другого сервера);
· проверка, знает ли клиент свой личный ключ;
· установление клиентом доверия к публичному ключу сервера;
· проверка, знает ли сервер свой личный ключ;
Приступим к рассмотрению первого этапа. Когда клиент пытается установить связь с сервером, содержащиеся в ID-файле клиента имя и публичный ключ посылаются на сервер. Клиент по запросу сервера также присылает список сертификатов, которые будут использоваться, чтобы подтвердить ассоциацию между именем клиента и его публичным ключом. Однако присланные клиентом сертификаты еще необходимо проверить, а для выполнения этой проверки нужен публичный ключ выдавшего "присланный" сертификат сертификатора. Но получить этот ключ следует из более заслуживающего доверия источника, чем "присланный" клиентом сертификат или "своя" общая адресная книга.
Установление сервером доверия к публичному ключу клиента с применением простых сертификатов
При применении простых сертификатов используются следующие правила доверия публичным ключам.1. Доверять любому публичному ключу, полученному из сертификата, сохраненного в своем ID-файле.
2. Доверять любому публичному ключу, полученному из имеющего силу (т.е. уже прошедшего проверку) сертификата.
Использование этих правил в ходе установления подлинности клиента можно проиллюстрировать на следующем примере.
· Клиент Doe сообщает свое имя и публичный ключ серверу SALES. SALES пока не доверяет публичному ключу Doe.
· SALES сообщает Doe имя сертификатора, создавшего простой сертификат, имеющийся в его ID-файле.
· Doe просматривает простые сертификаты в своем ID-файле. Находит среди них сертификат, созданный сертификатором, имя которого сообщил ему SALES. Посылает этот сертификат SALES.
· SALES читает публичный ключ своего сертификатора из сертификата в своем ID-файле. Согласно правилу 1 SALES доверяет этому публичному ключу.
· SALES проверяет сертификат, полученный от Doe, используя при этом публичный ключ своего сертификатора. Эта проверка включает вычисление "контрольной суммы" по информации из сертификата и сравнение её с "контрольной суммой", хранящейся в самом сертификате. Однако хранящаяся в сертификате "контрольная сумма" зашифрована личным ключом сертификатора, и для того, чтобы её расшифровать, как раз и необходим публичный ключ этого сертификатора. Если проверка успешна ("контрольные суммы" совпали), полученный от Doe сертификат имеет силу. Тогда согласно правилу 2 SALES доверяет публичному ключу Doe.
Установление сервером доверия
При применении иерархических и взаимных сертификатов используются следующие правила доверия публичным ключам.1. Доверять любому публичному ключу, полученному из сертификатов-компонент иерархического сертификата, имеющегося в своем ID-файле.
2. Доверять любому публичному ключу, полученному из имеющего силу (т.е. уже прошедшего проверку) сертификата-компоненты.
Проиллюстрируем использование этих правил в процессе установления подлинности клиента, принадлежащего тому же дереву имен, что и сервер (Рис. 8.5).
Рис. 8.5 Установление подлинности с применением иерархических сертификатов: дерево имен компании Acme
· Клиент Alice/Sales/Acme пытается получить доступ к серверу SERVER1/Development/Acme. Клиент сообщает серверу свое полное имя и публичный ключ. Сервер начинает процесс установления подлинности публичного ключа клиента.
· Сравнением своего имени с именем клиента сервер выявляет наличие общего предка. Общий предок всегда существует, когда клиент и сервер из одного дерева имен. Очевидно, этот общий предок - /Acme. Сервер читает публичный ключ /Acme из сертификата-компоненты в своем ID-файле. Согласно правилу 1 сервер "уверенно знает" публичный ключ /Acme.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Acme создал для /Sales/Acme. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Acme. Если сертификат имеет силу, согласно правилу 2 сервер "уверенно знает" публичный ключ /Sales/Acme.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Sales/Acme
создал для Alice/Sales/Acme. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Sales/Acme. Если сертификат имеет силу, согласно правилу 2 сервер "уверенно знает" публичный ключ Alice/Sales/Acme.
· Проиллюстрируем использование правил доверия публичным ключам в процессе установления подлинности клиента, когда клиент и сервер принадлежат разным деревьям имен (Рис. 8.6).
Рис. 8.6 Установление подлинности с применением иерархических и взаимных сертификатов: деревья имен компаний Acme и Omega
В этом случае приходится использовать как иерархические сертификаты из ID-файлов, так взаимный сертификат из адресной книги. Предполагаем, что сертификатор /Acme создал взаимный сертификат для сертификатора /Omega. Этот взаимный сертификат хранится в локальной адресной книге сервера SERVER1/ Development /Acme.
· Клиент Jon/Marketing/Omega пытается получить доступ к серверу SERVER1/Development/Acme. Клиент сообщает серверу свое полное имя и публичный ключ. Сервер начинает процесс установления подлинности публичного ключа клиента.
· Поскольку общих предков у John/Marketing/Omega и SERVER1/Development/Acme нет, сервер вынужден обратиться к своей адресной книге в поисках взаимного сертификата. Этот взаимный сертификат должен быть выпущен от имени сервера SERVER1/Development/Acme или одного из его предков для пользователя John/Marketing/Omega или одного из его предков. По условию /Acme, предок SERVER1/Development/Acme, создал взаимный сертификат для /Omega, предка John/Marketing/Omega. Сервер извлекает из локальной адресной книги этот взаимный сертификат.
· Сервер читает публичный ключ создателя взаимного сертификата - /Acme - из сертификата-компоненты в своем ID-файле. Согласно правилу 1 сервер "уверенно знает" публичный ключ /Acme.
· Сервер проверяет взаимный сертификат, используя публичный ключ /Acme. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ /Omega.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Omega создал для /Marketing/Omega. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Omega. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ /Marketing/Omega.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Marketing/Omega создал для John/Marketing/Omega. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Marketing/Omega. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ John/Marketing/Omega.
Отметим, что в этой процедуре происходила даже проверка взаимного сертификата, извлеченного "из собственной локальной" адресной книги. Следовательно, взаимный сертификат, как и всякий сертификат, "подписан" создавшим его сертификатором. Однако, изучив механизм "электронной подписи" (рассматривается в 9.5), любознательный читатель не обнаружит в документе Cross Certificate никаких следов ее применения. Все дело в "тонком" различии собственно публичного ключа и информации, которая хранится в поле с меткой Certified Public Key: некоторых документов, в том числе и документа Cross Certificate, из адресной книги - "сертифицированного публичного ключа". Обратим внимание, что "в дизайне" это поле имеет имя Certificate. Сертифицированный публичный ключ сам является сертификатом - в нем содержится вся та информация, которая входит в состав сертификата, в том числе и публичный ключ. Косвенным подтверждением этого является следующий факт. При продлении срока действия сертификата в ID-файле пользователя изменяется сертифицированный публичный ключ в документе Person. Однако при этом в ID-файле не происходит смены публичного ключа и связанного с ним личного ключа - пользователь сохраняет возможность читать шифрованную почту в своем почтовом ящике и работать с базами данных, для которых применено локальное шифрование.
Введение в Lotus Notes и уточнение терминов
Lotus Notes - многоплатформная (функционирует под многими операционными системами) многопротокольная (может работать по многим сетевым протоколам) программная система для групповой работы с документами.Программное обеспечение Notes состоит из клиентской части - станции Notes - и серверной части - сервера Notes.
Сервер Notes
отвечает за:
· предоставление в совместное использование расположенных на нем баз данных разным пользователям (как сервер баз данных)
· хранение пользовательских почтовых ящиков и передачу почты между серверами по расписанию (как почтовый сервер)
· выполнение репликаций баз данных между серверами по расписанию (поддержка распределенных баз данных)
· взаимодействие с пользователями и серверами, имеющими доступ к серверу только по модему непосредственно (как DialUp-сервер) или с использованием сервиса удаленного доступа к локальной сети
· предоставление пользователям и серверам доступа через данный сервер к другим серверам (как Passthry-сервер)
· обеспечение безопасности.
Администратор Notes
устанавливает, контролирует и управляет работой сервера Notes и обеспечивает его безопасность. Управление сервером может выполняться администратором как непосредственно с сервера, так и дистанционно, со станции администратора.
Программное обеспечение станции Notes (клиента) реализует графический интерфейс для пользователя. Со своих станций пользователи имеют доступ к почтовым услугам, предоставляемым сервером Notes, и расположенным на серверах Notes базам данных. Пользователи могут также сохранять персональные базы данных локально, т.е. на своих компьютерах.
Станция Notes (клиент) имеет соединение с сервером(ами) Notes по локальной сети (LAN) или с использованием модема. DialUp-станция Notes имеет доступ к серверу Notes только посредством модема. Станции Notes не могут соединяться между собой. Сервер Notes тоже не может "по своей инициативе" соединиться со станцией - соединение с сервером всегда инициирует станция. Сервер может соединяться с другими серверами для выполнения репликаций баз, передачи почты или предоставления "посреднических услуг" станциям или другим серверам.
WAN - глобальная сеть, объединяющая многие локальные сети с использованием мостов, маршрутизаторов, выделенных линий, стандартных телефонных линий или иного специального оборудования для соединения компьютеров, обычно на больших расстояниях.
Для обслуживания Notes формально существуют четыре стандартных должности:
· Администратор системы - обслуживает серверы, занимается поддержкой пользователей, загружает и останавливает серверы, регистрирует серверы и сертификаторов верхних уровней, составляет и отлаживает расписание репликаций и передачи почты, распределяет дисковое пространство на сервере, следит за происходящими в системе событиями по протоколу работы серверов, выполняет регламентные работы.
· Инженер поддержки
- устанавливает и проверяет Notes, обеспечивает поиск ошибок. В большинстве случаев может поддерживать Notes в дополнение к поддержке других систем.
· Сертификатор
(Certifier) - имеет и хранит от несанкционированного использования ID сертификатора, создает и сертифицирует ID пользователей, используя при этом ID сертификатора, а также предпринимает прочие меры безопасности.
· Администратор базы данных - управляет доступом пользователей к конкретной базе данных, размещенной на сервере.
Выпуск взаимных сертификатов без передачи безопасных копий
Когда станция Notes версий 4.х обращается к серверу Notes версий 4.х, с которым у пользователя этой станции нет взаимного сертификата, однако у сервера или имеется взаимный сертификат для пользователя или его предка, а потому часть процедуры аутентификации на стороне сервера завершается успехом, или к серверу разрешен анонимный доступ, станция получает от сервера от сервера иерархический сертификат, содержащийся в его ID-файле, и предлагает пользователю выпустить взаимный сертификат.
Рис. 8.33 Диалоговое окно Cross Certify на станции
При этом пользователь получает диалоговое окно Cross Certify. Нажатие кнопки Yes влечет создание в локальной адресной книге станции взаимного сертификата от имени пользователя станции для сертификатора организации, которой принадлежит вызванный сервер. Нажатие кнопки No, очевидно, запрещает создавать взаимный сертификат. Наибольший интерес представляет кнопка Advanced Options. Нажав ее, вы получите уже знакомое диалоговое окно Cross Certify ID.
Рис. 8.34 Диалоговое окно Cross Certify ID на станции
Кнопкой Certifier администратор или сертификатор сможет выбрать тот ID-файл сертификатора, от имени которого считает нужным выпустить взаимный сертификат. Кнопкой Server можно выбрать сервер, в адресную книгу которого (естественно, при наличии доступа) этот сертификат будет помещен. В поле Subject name: можно выбрать имя, для которого выпускается взаимный сертификат - от имени сервера до имени его сертификатора организации. Можно и изменить срок действия сертификата...
Администратор сервера может пользоваться этой возможностью, запуская на компьютере сервера станцию, работающую под ID-файлом сервера, затем вызывая другой сервер, в адресной книге которого уже имеется взаимный сертификат для вызывающего сервера или его предка, и "на лету" выпуская взаимный сертификат на своей стороне.
Завершая главу, ответим на два вопроса.
· Что следует делать, если взаимный сертификат более не нужен? Его просто следует удалить из адресной книги.
· Могут ли в адресной книге одного домена одновременно присутствовать два или более дерева имен? Могут, и это типичная ситуация в только начинающих развиваться доменах, когда первое дерево имен было выбрано неудачно и происходит постепенный переход к более удачному дереву имен. Чтобы деревья имен "мирно уживались" в одной адресной книге, обычно выпускают взаимный сертификат от имени сертификатора первого дерева имен для сертификатора второго дерева имен, а затем взаимный сертификат от имени сертификатора второго дерева имен для сертификатора первого дерева имен. В этом случае оба "зеркально симметричных" взаимных сертификата находятся в одной адресной книге. Однако пользователям из одного дерева имен приходится скопировать из общей адресной книги в свою персональную взаимный сертификат для сертификатора другого дерева имен. Только по этой причине и рекомендуется иметь в одном домене или организации одно дерево имен. Но рекомендация не означает запрета...
Взаимная сертификация пользователя или сертификатора с сервером в другой организации
Предположим, что ваше имя Joe User/Sales/Company_A, и вы хотите связаться с сервером из другой компании, имя которого Server/Company_B. Поскольку вы и сервер не имеете общего предка, необходимы взаимные сертификаты.Пусть в вашей компании уже имеется сервер Server/Sales/Company_A, который "умеет" связываться с сервером Server/Company_B. Тогда вы можете обнаружить в общей адресной книге вашей компании документ Cross Сertificate такого содержания
Issued By (Кто выпустил): /Sales/Company_A или /Company_A
Issued To (Для кого): Server/Company_B
Вы можете скопировать этот документ в вашу персональную адресную книгу. Когда вы затем попробуете связаться с сервером Server/Company_B, начнется процедура аутентификации. Ваша станция успешно выполнит свою часть процедуры: в локальной адресной книге имеется взаимный сертификат, который один из ваших предков (/Sales/Company_A или /Company_A) выпустил для сервера Server/Company_B. Успех части процедуры аутентификации, выполняемой сервером Server/Company_B, зависит от того, какой взаимный сертификат имеется в его локальной адресной книге. Если вид этого таков:
Issued By (Кто выпустил): Server/Company_B или /Company_B
Issued To (Для кого): /Sales/Company_A или /Company_A
вас ожидает успех - Server/Company_B или его предок /Company_B выпустил взаимный сертификат для вашего предка /Sales/Company_A или /Company_A.
Если вид этого документа в их адресной книге:
Issued By (Кто выпустил): Server/Company_B или /Company_B
Issued To (Для кого): Server/Sales/Company_A
часть процедуры аутентификации, выполняемой сервером Server/Company_B, кончается неуспехом, поскольку сервер Server/Sales/Company_A не ваш предок, а на одном уровне с вами (Joe User/Sales/Company_A).
Тогда вы имеете две возможности.
1) Можно послать безопасную копию вашего ID-файла (Joe User/Sales/Company_A) администратору другой компании и попросить его выпустить на нее взаимный сертификат. Администратор может выпустить этот взаимный сертификат как на имя Joe User/Sales/Company_A, так и на /Sales/Company_A или /Company_A. Процесс выпуска взаимного сертификата будет напоминать рассмотренный выше при взаимной сертификации двух серверов.
2) Можно попросить вашего сертификатора, чтобы он послал безопасную копию одного из ID-файлов сертификаторов вашей организации (или /Sales/Company_A или /Company_A) администратору другой компании с просьбой выпустить на нее взаимный сертификат. Администратор другой компании может выпустить этот взаимный сертификат на имя /Sales/Company_A или /Company_A, если ему прислана безопасная копия /Sales/Company_A, или только на /Company_A, если ему прислана безопасная копия /Company_A.
Если администратор другой компании не откажется это сделать, документ Cross Certificate в общей адресной книге компании Acme примет следующий вид
Issued By (Кто выпустил): /Server/Company_B или /Company_B
Issued To (Для кого): Joe User/Sales/Company_A или /Sales/Company_A или /Company_A
и вы получите доступ на Server/Company_B.
Таким образом, взаимный сертификат для пользователя или сервера позволяет только одному ID-файлу проходить процедуру аутентификации. Но если одна из сторон выпускает взаимный сертификат на имя сертификатора другой, эта сторона позволяет любому, кто имеет этого сертификатора своим предком, проходить процедуру аутентификации.
Получается очень мощная и гибкая система. Если администратор компании Company_B хочет предоставить доступ большому количеству пользователей из Company_A на сервер Server/Company_B, ему не имеет смысла индивидуально кросс-сертифицировать каждого из этих пользователей. Вместо этого администратор может выпустить взаимный сертификат сертификатору /Sales/Company_A. Любой пользователь, имеющий этого точного предка в компании Company_A, будет проходить процедуру аутентификации. Однако пользователь из Company_A с именем Sam User/Marketing/Company_A не будет аутентифицирован, поскольку Sam User/Marketing/Company_A не предок /Sales/Company_A.
Если же имеются некоторые пользователи из Company_A с именами, заканчивающимися на /Sales/Company_A, которых администратор Company_B ни при каких условиях не хочет "пускать" на сервер Server/Company_B, администратор будет должен использовать в документе Server поля-списки Access server:
("имеют доступ к серверу") или Not access server:
("не имеют доступа к серверу") для уточнения доступа.
Взаимная сертификация сервера с сервером в другой организации
Предположим, что сервер с именем Server/Company_A из компании А должен иметь доступ к серверу с именем Server/Company_Вв компании B (для репликации баз или передачи почты). Рассмотрим те действия, которые нужно выполнить, чтобы оба сервера могли устанавливать подлинность друг друга.
1. Администратор сервера из компании A должен сделать безопасную копию ID-файла Server/Company_A и передать ее сертификатору (обычно он же и администратор сервера) в компании B. Для создания безопасной копии выполняется такая последовательность действий: меню File - Tools - User ID - закладка More Options - кнопка Create Safe Copy. Чтобы случайно не перепутать ID-файл, с которого создается безопасная копия, администраторы предпочитают последовательность действий: меню File - Tools - Server Administration - Administration - ID File… - выбор нужного ID-файла
- закладка More Options -
кнопка Create Safe Copy. Для сокращения риска повреждения ID-файла сервера желательно делать это, когда сервер остановлен. Если имеется другая копия ID-файла сервера, можно создать безопасную копию с нее. А еще лучше сделать безопасную копию ID-файла сервера один раз и многократно использовать в последующем.
2. Сертификатор или администратор сервера в компании B получает безопасную копию и должен создать взаимный сертификат для Server/Company_A. Для этого он должен выполнить последовательность действий:
в меню File - Tools - Server Administration - кнопка Certify - в ее меню Cross Certify ID File.
Будет получено диалоговое окно Choose Certifier ID для выбора ID-файла субъекта, от имени которого будет создаваться взаимный сертификат. В качестве него может быть выбран ID-файл сервера Server/Company_B или ID-файл сертификатора /Company_B. Если бы имя сервера из компании B было Server/Sales/Company_В, тогда в качестве него мог быть выбран ID-файл сервера Server/Sales/Company_В или ID-файлы сертификаторов /Sales/Company_В или /Company_В. Предположим, администратор выбрал ID-файл сертификатора /Company_B. Последует запрос пароля для выбранного ID-файла.
Затем появится диалоговое окно Choose ID to Certify для выбора ID-файла, для которого выпускается взаимный сертификат. Здесь должна быть выбрана безопасная копия, полученная из компании A.
После этого появляется диалоговое окно Cross Certify ID.
Рис. 8.30 Администратор из компании В, используя ID сертификатора /Company_B, выпускает взаимный сертификат для сервера Server/Company_A
В нем в поле Subject name: администратор может конкретизировать имя, для которого выпускается взаимный сертификат. В данном случае сертификат может быть выпущен как для Server/Company_B, так и для его предка /Company_B. Предположим, администратор выбрал Server/Company_B.
Кнопка Server используется для выбора сервера, в адресной книге которого будет создан взаимный сертификат - документ Cross Certificate. Кнопка Certifier позволяет при необходимости сменить ID-файл субъекта, от имени которого выпускается взаимный сертификат. Наконец нажимается кнопка Cross-certify...
В результате в адресную книгу сервера Server/Company_B будет добавлен документ формы Cross Certificate, выпущенный от имени /Company_B для Server/Company_A.
Рис. 8.31 Взаимный сертификат в адресной книге сервера Server/Company_B от имени /Company_B для Server/Company_A
Мы "прошли" только половину пути по процессу взаимной сертификации! Если Server/Company_A на этом этапе попробует получить доступ к Server/Company_B, на его консоли появится сообщение об ошибке "Your Address Book does not contain any cross certificates capable of authenticating the server"
- "ваша адресная книга не содержит взаимных сертификатов, способных подтвердить сервер".
3. Теперь администратору из компании В следует сделать "безопасную копию" ID-файла Server/Company_B и передать этот файл администратору сервера или сертификатору из компании А.
4. Администратор компании A, получив безопасную копию из компании В, может использовать ID-файл сервера Server/Company_A
или ID-файл сертификатора /Company_A, чтобы создать взаимный сертификат для Server/Company_B
или /Company_B. Он повторяет действия, рассмотренные в шаге 2, но с другими ID-файлами. Предположим, он выбрал ID-файл сертификатора /Company_A и выпускает сертификат для имени Server/Company_B. В результате в адресной книге на сервере в компании А появится документ формы Cross Certificate, выпущенный от имени /Company_A
для Server/Company_B.
Рис. 8.32 Взаимный сертификат в адресной книге сервера Server/Company_A от имени /Company_A для Server/Company_B
Процесс взаимной сертификации завершен. Server/Company_A и Server/Company_B теперь могут устанавливать подлинность друг друга.
При этом никакие другие серверы из компании A, например, Server2/Company_A, не смогут получать доступ к Server/Company_B. Так будет происходить потому, что в адресной книге компании В имеется взаимный сертификат только для Server/Company_A. И наоборот, никакие другие серверы из компании B
не смогут получать доступ к Server/Company_A.
Взаимные сертификаты
Взаимный сертификат - иерархический сертификат, создаваемый сертификатором с иерархическим именем для пользователя, сервера или сертификатора с иерархическим именем в случае, когда между сертификатором и сертифицируемым отсутствуют иерархические отношения (т.е. сертификатор и сертифицируемый принадлежат разным деревьям имен). Взаимные сертификаты часто используются, когда две независимых организации должны связываться между собой с применением Notes. Хранятся взаимные сертификаты не в ID-файлах, а в адресных книгах (документ Cross Certificate), общих или личных, смотря по тому, для кого создавался и кем будет использоваться взаимный сертификат. Интерпретировать документ Cross Certificate следует подобно Рис. 8.4.Например, сервер компании Alpha Inc. имеет имя SERVER1/Support/Development/Alpha Inc./US. К этому серверу должен иметь доступ сервер RETAIL2/Retail/Sales/Omega/US
отделения розничной продажи компании Omega.
Безопасная копия ID-файла сервера RETAIL2/Retail/Sales/Omega/US посылается сертификатору /Support/Development/Alpha Inc./US. Сертификатор создает взаимный сертификат для присланного ему ID-файла. В результате взаимный сертификат "за подписью" /Support/Development/Alpha Inc./US, содержащий имя сервера RETAIL2/Retail/Sales/Omega/US и его публичный ключ, будет добавлен в адресную книгу на сервере SERVER1/Support/Development/Alpha Inc./US.
Процесс "зеркально" повторяется. Безопасная копия ID-файла сервера SERVER1/Support/Development/Alpha Inc./US посылается сертификатору /Retail/Sales/Omega/US. Сертификатор создает взаимный сертификат для присланного ему ID-файла. В результате взаимный сертификат "за подписью" /Retail/Sales/Omega/US, содержащий имя SERVER1/Support/Development/Alpha Inc./US и его публичный ключ, будет добавлен в адресную книгу на RETAIL2/Retail/Sales/Omega/US.
Могут использоваться и взаимные сертификаты между организационными единицами или организациями - это взаимный сертификат для ID-файла сертификатора. Тогда любой пользователь, сертифицированный этим сертификатором и желающий получить доступ к "чужому" серверу, должен лишь скопировать в буфер документ Cross Certificate из общей адресной книги и вставить его из буфера в свою личную адресную книгу.
Задачи системы учета свободного времени
SCHED и CALCONN Система учета свободного времени (Free Time system) состоит из двух серверных задач: Schedule Manager (SCHED) и Calendar Connector (CALCONN). Запуск этих задач автоматически "прописывается" в переменной ServerTasks в файле NOTES.INI сервера, когда вы устанавливаете сервер Notes версии 4.5.Schedule Manager
Пользователь разрешает использование информации о его свободном времени, создавая документ Calendar Profile в своем почтовом ящике. Поле с меткой Only the following users can read my Freetime Schedule ("Только следующие пользователи могут читать информацию о моем свободном времени") позволяет задать список тех, кто может получать информацию о свободном времени пользователя. Если это поле пусто, все пользователи могут получать эту информацию.
При первом запуске задача Schedule Manager создает на "своем" сервере базу данных BUSYTIME.NSF и в этой базе создает "входы" для каждого пользователя, для которого этот сервер является почтовым сервером (поле MailServer в документе Person). Schedule Manager функционирует на сервере постоянно и каждый раз, когда пользователи вносят изменения в свои календари, он немедленно заносит эти изменения в базу BUSYTIME.NSF, находящуюся на этом сервере. Это гарантирует, что база BUSYTIME.NSF на каждом почтовом сервере постоянно находится в синхронном состоянии с календарями пользователей.
Даже если вы удалите базу данных BUSYTIME.NSF, при следующем запуске сервера Schedule Manager вновь создаст ее и заполнит соответствующей информацией из почтовых ящиков пользователей этого сервера. Обратите внимание, что только Schedule Manager имеет доступ к базе данных BUSYTIME.NSF.
Когда пользователь хочет пригласить одного или несколько человек на встречу и выбирает поиск свободного времени приглашаемых, к работе подключается Schedule Manager. В первую очередь он находит по общей адресной книге местоположения почтовых серверов и почтовых ящиков приглашаемых лиц. Затем Schedule Manager ищет информацию о свободном времени каждого приглашаемого лица в базе BUSYTIME.NSF на почтовом сервере приглашаемого лица. Schedule Manager возвращает список дат и времен возможных встреч и количество "доступных" лиц.
Calendar Connector
Всякий раз, когда пользователь, почтовый ящик которого находится на одном сервере, запрашивает информацию о свободном времени пользователя, почтовый ящик которого находится на другом сервере, к работе подключается задача Calendar Connector. Задача использует информацию из общей адресной книги, чтобы найти путь между почтовым сервером запрашивающего информацию пользователя и почтовым сервером пользователя, информацию о свободном времени которого запрашивается. Обратите внимание, что эти серверы могут находиться и в разных доменах Notes.
Пример: как выполняется запрос о свободном времени
Предположим, что пользователь Иван Иванович, почтовый ящик которой находится на сервере A, хочет узнать, когда свободен пользователь Иван Никифорович, чтобы договориться с ним о встрече. При этом происходит следующее.
· Иван Иванович в своем почтовом ящике создает приглашение на встречу с Иваном Никифоровичем и нажимает кнопку поиска свободного времени.
· Станция Ивана Ивановича посылает запрос о свободном времени на его почтовый сервер (сервер A).
· Система учета свободного времени ищет документ Person
для Ивана Никифоровича в общей адресной книге сервера A.
· Если находит, то определяет из его поля MailServer имя почтового сервера Ивана Никифоровича, и затем выполняет одно из следующего.
· Если почтовый сервер Ивана Никифоровича тот же сервер A, система учета свободного времени ищет свободное время Ивана Никифоровича непосредственно в базе BUSYTIME.NSF на этом сервере и затем отображает полученную информацию Ивану Ивановичу.
· Если почтовым сервером Ивана Никифоровича является сервер B из того же домена, что и сервер A, система учета свободного времени на сервере А передает запрос на cервер B. Система учета свободного времени на cервере B находит необходимую информацию в базе BUSYTIME.NSF на сервере B, возвращает ее системе учета свободного времени на сервере A, и полученная информация отображается у Ивана Ивановича.
· Но если поле CalendarDomain в документе Person
Ивана Никифоровича не пусто и содержит имя домена, отличающееся от имени его почтового домена, это означает, что Иван Никифорович пользуется другим приложением для планирования времени, например, Organizer 2.x или OfficeVision. Тогда система учета свободного времени направляет запрос о свободном времени Ивана Никифоровича в этот домен.
· Если система учета свободного времени не находит документ Person для Ивана Никифоровича в общей адресной книге сервера A, это означает, что почтовый ящик Ивана Никифоровича находится в другом домене. Если имя домена явно содержится в адресе Ивана Никифоровича или если иерархическое имя Ивана Никифоровича дает достаточно информации для определения имени его домена, система учета свободного времени ищет в общей адресной книге документ формы Domain для домена Ивана Никифоровича и затем выполняет одно из следующего.
· Если был найден документ формы Domain
типа Adjacent Domain ("Соседний домен"), система учета свободного времени обращается к информации из поля CalendarServer этого документа. Это поле может содержать имя сервера из домена Ивана Никифоровича, который "умеет" принимать запросы о свободном времени. Если поле не пусто, система учета свободного времени выполняет запрос на этот сервер. Если поле CalendarServer пусто, информация о свободном времени Ивана Никифоровича недоступна.
· Если система учета свободного времени находит документ формы Domain
типа Foreign Domain ("Чужой домен"), это знает, что Иван Никифорович пользуется другим приложением для планирования времени, например, Organizer 2.x или OfficeVision. Поле CalendarServer в документе Foreign Domain должно содержать имя сервера, который "умеет" принимать запросы о свободном времени, а поле CalendarSystem должно содержать тип используемого приложения для планирования времени. Система учета свободного времени выполняет запрос о свободном времени Ивана Никифоровича на указанный в поле CalendarServer сервер.
· Если система учета свободного времени не находит в общей адресной книге никаких документов формы Domain для домена Ивана Никифоровича, информация о свободном времени Ивана Никифоровича недоступна.
Запрос о свободном времени будет также терпеть неудачу, если сервер Ивана Никифоровича или один из серверов "в цепочке" не функционирует.
Заглянем в файл NOTES.INI
Пока мы рассмотрим только те переменные из NOTES.INI, на которые обычно обращают внимание при установке сервера и станции. Учтите, что для того, чтобы выполненные "вручную" исправления в NOTES.INI "вступили в силу", потребуется перезапустить станцию или сервер. Способы модификации NOTES.INI, не требующие перезапуска сервера, будут рассмотрены позже.KitType=<1 или 2>
1 - станция, 2 - сервер. Начальное значение получает при установке Notes.
Domain=<имя домена>
На сервере задает имя домена, которому принадлежит этот сервер; на станции задает имя домена, которому принадлежит "домашний" сервер пользователя. По умолчанию: имя, заданное при установке Notes.
KeyFilename=<путь и имя ID-файла пользователя>
Путь для ID-файла пользователя. См. также ServerKeyFileName.
ServerKeyFileName=<путь и имя ID-файла сервера>
Путь для ID-файла сервера. Используется сервером и API-программами, выполняющимися на сервере.
CertificateExpChecked=<дата>
Дата последней проверки времени истечения сертификата в ID-файле пользователя. Например, CertificateExpChecked=D:\NOTES33\NIONTSEV.ID 21.09.95
CertiferIDFile=<путь и имя ID-файла сертификатора>
Путь для ID-файла сертификатора. Имеется только в NOTES.INI на первом сервере в организации и в NOTES.INI на станциях администраторов и сертификаторов.
Описание портов и их настройки
Следующий фрагмент из файла NOTES.INI содержит информацию о выполненных из диалогового окна User Preferens (см. Рис. 2.18) настройках портов сервера.
; Список активных портов на сервере или станции
Ports=TCPIP,SPX,LAN0,COM2
; Список неиспользуемых портов на сервере или станции
DisabledPorts=VINES,COM1,COM3,COM4,COM5
; Параметры порта TCPIP
TCPIP=TCP, 0, 15, 0
TCPIP_TcpConnectTimeout=0,5
; Параметры порта SPX
SPX=NWSPX,0,15,0,,12288,
NetWareSpxSettings=0,0,0,0,1,1
; Параметры порта LAN0
LAN0=NETBIOS,0,15,0,,12288,
VINES=VINES, 0, 15, 0
COM1=XPC,1,15,0,
; Параметры порта COM2, MT9614.MDM - файл команд модема
COM2=XPC,2,15,0,,12302,19200,33,mt9614.mdm,150,15
COM3=XPC,3,15,0,
DialTimer=150
IdleHangupTimer=10
Names=<список имен файлов адресных книг>
Имена файлов (без расширения .NSF) адресных книг для поиска при проверке имен получателей почтовых сообщений. Список через запятую. Первое имя в списке должно быть names. Адресные книги просматриваются в указанном в списке порядке. Notes завершает поиск, когда он нашел вхождение имени получателя в одной из адресных книг. При посылке почты станция использует эту возможность для поиска имен пользователей или групп. Сервер не использует эту возможность при просмотре документов Connection, Domain и Server - такие документы выбираются только из первой адресной книги. Общее число символов в списке имен не должно превышать 256. Применяется переменная как для сервера, так и для станции.
По умолчанию переменная отсутствует в NOTES.INI, и Notes использует только одну адресную книгу с именем NAMES.NSF.
Замечания об использовании кластера
Состояния сервера-члена кластераСервер кластера может находиться в следующих состояниях: AVAILABLE ("доступен"), BUSY ("занят"), RESTRICTED ("использование ограничено"), MAXUSERS ("превышен порог пользователей"), UNREACHABLE
("не функционирует") и INVALID. Состояние INVALID - переходное состояние, которое можно наблюдать в течение очень короткого отрезка времени, когда "отрабатывается" процесс вывода сервера из состава кластера.
Следующая таблица показывает, что будет происходить с запросом на доступ к базе данных на сервере кластера для клиентов Notes версий 3.х, 4.х и серверных задач Notes Replicator ("обычный" репликатор), Cluster
Replicator (внутрикластерный репликатор) и Mail Router (маршрутизатор почты). В таблице использованы следующие обозначения:
· Access granted - сервер выполняет запрос,
· Load balance - сервер генерирует событие load balance, а обратившиеся к нему станция или сервер предпринимают попытку перенаправить запрос,
· Failover - сервер генерирует событие failover, а обратившиеся к нему станция или сервер предпринимают попытку перенаправить запрос,
· No access - сервер отвергает запрос.
| Состояние | сервера | ||||||||||||
| Запрос от | Available | Busy | Restricted | MaxUsers | Unreachable | Invalid | |||||||
| Клиент R3 | Access granted | Access granted | Access denied | Access denied | No access | Access granted | |||||||
| Клиент R4 | Access granted | Load balance | Failover | Failover | Failover | Access granted | |||||||
| Клиент R4 (репликации) | Access granted | Access granted | Access granted | Access granted | Failover | Access granted | |||||||
| Notes Replicator | Access granted | Access granted | Access granted | Access granted | No access | Access granted | |||||||
| Cluster Replicator | Access granted | Access granted | Access granted | Access granted | No access | Access granted | |||||||
| Mail Router | Access granted | Access granted | Failover | Failover | Failover | Access granted |
Особенности внутрикластерного репликатора
Серверная задача Cluster Replicator осуществляет репликации "по событиям" изменения документов в базах текущего сервера, а не по расписанию. Эти события хранится в очереди событий в виртуальной памяти сервера. Если другой сервер-член кластера, на который должны быть переданы эти изменения, не функционирует, события "накапливаются" в очереди "исходного" сервера. При перезапуске "исходного" сервера "накопившиеся" в его очереди события будут утеряны. Так что не следует думать, что внутрикластерный репликатор всегда гарантирует "полную синхронность" реплик. Кроме того, выполняемые внутрикластерным репликатором изменения не протоколируются в истории репликаций баз. Поэтому, если синхронность реплик на серверах-членах кластера нарушилась, следует воспользоваться "обычным" репликатором. А чтобы вообще не задумываться о возможной несинхронности баз в кластере из-за рассмотренного свойства внутрикластерного репликатора, можно поддерживать внутри кластера и обычные репликации по расписанию. Конечно, такой подход несколько "груб", но зато надежен.
Кроме того, на сервере кластера может запускаться несколько внутрикластерных репликаторов. Если ресурсы компьютеров позволяют, в кластере из n серверов на каждом сервере-члене можно запускать до n-1 внутрикластерных репликаторов. При этом передача изменений с одного сервера-члена на остальные серверы будет происходить псевдо-одновременно, а не последовательно. В результате изменения должны передаваться в целом быстрее, чем при использовании одного внутрикластерного репликатора. Но практика богаче теории - в условиях недостатка оперативной памяти на серверах из-за усилившегося свопинга вы можете получить и обратный эффект.
Состояния баз Out of service и Pending delete
В документах базы данных CLDBDIR.NSF присутствуют поля, информация их которых отображается в колонках видов Out of service ("выводится из обслуживания")
и Pending delete ("ожидает удаления"). Не пытайтесь изменять значения этих полей в базе CLDBDIR.NSF - поля лишь отображают текущее состояние базы, но не могут его изменить.
Администратор выводит базу из обслуживания, когда ему необходимо получить к базе монопольный доступ, например, чтобы выполнить уплотнение базы. Все последующие обращения пользователей к базе, находящейся в состоянии Out of service, будут отвергаться и при возможности перенаправляться в реплику на других серверах кластера. В результате через некоторое время база будет "освобождена" пользователями. По своему смыслу это аналогично действию команды консоли Set Config "Server_Restricted=1", но не для всех баз на сервере, а только для конкретной базы. После того, как администратор проделает с базой необходимую работу, он обычно снова "вводит базу в обслуживание".
Администратор переводит базу в состояние Pending delete, когда ему необходимо убрать реплику этой базы с конкретного сервера-члена кластера. При этом обычно предполагается, что реплика этой базы имеется на других серверах кластера. Однако подлежащая удалению реплика может использоваться пользователями. Все последующие обращения пользователей к базе, находящейся в состоянии Pending delete, будут отвергаться и перенаправляться в реплику на других серверах кластера. В результате через некоторое время база будет "освобождена" пользователями. И только после того, как внутрикластерный репликатор "передаст" последние изменения из этой реплики в реплики на других серверах, данная реплика будет удалена.
Перевод баз данных в рассмотренные выше состояния осуществляется из окна Server Administration кнопкой Database Tools с последующим выбором "инструмента" Cluster Management.
Рис. 10.12 Перевод баз в состояния Out of service, In service и Pending delete
Репликации с кластером
В командах консоли сервера для выполнения репликаций, а также в документах Connection для репликаций вместо имени сервера назначения может указываться имя кластера. При этом в репликации принимают участие не только реплики баз данных вызывавшего сервера и соответствующие реплики на том сервере-члене кластера, с которым было установлено соединение, но и соответствующие реплики на других серверах-членах кластера. Вызывающий сервер должен быть версии 4.5, наличие лицензии Lotus Domino Advanced Services для него не требуется. Аналогично можно поступать при репликациях между станцией и кластером.
Внутрикластерный обмен по отдельному сегменту локальной сети
Для того, чтобы внутрикластерный обмен серверов происходил по отдельному сегменту локальной сети, на компьютерах серверов должны быть установлены как минимум две сетевые карты с поддержкой необходимых стеков протоколов, а в файлах NOTES.INI
серверов должна присутствовать переменная Server_Cluster_Default_Port=<имя порта>. Здесь <имя порта>
- имя порта сервера Notes, связанного с протоколом и сетевой картой, подключенной к сегменту локальной сети, по которому должен происходить внутрикластерный обмен.
Запуск посредством документа Program в общей адресной книге
В общей адресной книге создается документ Program (а уже созданные документы находятся в виде Server\Programs).
Рис. 3.34 Документ обеспечивает запуск задачи COMPACT ежедневно в 4 часа ночи
Поле Program name: (имя программы) содержит только имя программы из каталога сервера или каталога в поисковом пути операционной системы. Поле Command line: содержит командную строку для этой программы. В поле Server to run on:
(сервер для запуска) выбирают полное название сервера, на компьютере которого должна быть запущена программа. В группе полей Schedule задается разрешение на автоматический запуск по расписанию Enabled/Disabled и время запуска Run at times:. Если интервал повторения Repeat interval of: нулевой, программа запускается один раз. Иначе несколько раз в день через заданный интервал. Days of week: - по каким дням недели. Кроме того, в поле Enabled/Disabled: возможен выбор Startup Only, означающий, что данная программа должна автоматически запускаться при старте сервера.
Запуск посредством переменных в файле NOTES.INI сервера
Время запуска и списки запускаемых серверных задач задается в файле NOTES.INI сервера.· ServerTasks=<имена задач> Список задач, автоматически запускаемых при старте сервера и работающих до его останова. По умолчанию на сервере версии 4.5, не являющемся членом кластера: Replica, Router, Update, Stats, Amgr, Adminp, Sched, CalConn.
ServerTasks=Replica,Router,Update,Stats,AMgr,Adminp,Sched,CalConn
Дополнительно можно запускать задачи Compact, Fixup, Event, Report, Collect, Billing, Web, HTTP, POP3, SMTPMTA, X400MTA
и др.
· ServerTasksAt Список задач, запускаемых сервером в час