Принцип работы 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" для обозначения совокупности расположенных на разных серверах Notes реплик одной и той же базы.
При этом термин "реплика базы":
· означает, что существует по крайней мере еще одна база, имеющая тот же самый идентификатор реплики (Replica ID), что и данная.
Рис. 6.1 Пиктограммы реплик адресной книги "стекированы" - расположены одна за другой
"Увидеть" идентификатор реплики можно на панели свойств базы.
Рис. 6.2 Эта база имеет идентификатор реплики C3256274:007061676
Идентификатор реплики (Replica ID) - уникальный идентификатор, позволяющий отличать реплики базы данных на различных серверах и станциях от обычных копий. Различные реплики одной и той же базы на различных серверах и станциях могут иметь разные названия и имена файлов, но у них одинаковый идентификатор реплики. Копия же базы, выполненная средствами Notes, гарантированно будет иметь другой идентификатор реплики, чем оригинал. Однако копия базы, выполненная средствами операционной системы, будет иметь тот же идентификатор реплики, что и оригинал
· предполагает, что за собственно созданием реплики последуют настроенные администратором и выполняемые автоматически по расписанию или по явному указанию администратора сервера или пользователя станции процессы репликации - обмена изменениями между репликами
· не означает, что содержание двух или более реплик базы будет совершенно одинаковым. Вообще говоря, это не так и во времени, и по наличию содержащихся в репликах документов.
Суть процесса репликации состоит в следующем. Реплики одной и той же распределенной базы находятся на разных серверах. Пользователи, имеющие доступ к репликам, изменяют их содержимое (изменяют документы, создают новые документы, удаляют существующие документы) параллельно и независимо друг от друга. В результате содержимое реплик становится неодинаковым. В определенное расписанием время на одном из серверов серверная задача Replicator ("репликатор") вызывает другой сервер. Если соединение состоялось, репликатор в первую очередь составляет списки баз, реплики которых присутствуют на обоих серверах.
Далее репликатор для каждой реплики сравнивает списки документов. Новые, модифицированные или удаленные в реплике на вызванном сервере документы принимаются в реплику на вызывавшем сервере. Затем, если осуществляется репликация по схеме Pull-Pull, репликатор вызывавшего сервера инициирует репликатор на вызванном сервере. Последний в свою очередь принимает в свою реплику новые, модифицированные или удаленные документы из реплики на сервере, инициировавшем процесс. Кроме того, в репликациях могут участвовать элементы дизайна и список управления доступом базы. По завершении этого процесса содержимое всех реплик баз на обоих серверах приходит в некоторое "установившееся" состояние. Однако это "установившееся" состояние, вообще говоря, не означает, что содержимое обеих реплик станет совершенно одинаковым. В частности, "неодинаковость" может создаваться за счет разных прав доступа серверов к репликам на других серверах или запланированного использования специальных формул, описывающих множество реплицируемых документов (селективные репликации).
Репликации между сервером и станцией Notes
На станции нет явного аналога серверной задачи Replicator. Программное обеспечение станции при репликации сначала принимает изменения с сервера, а затем отправляет измененные документы на сервер (аналог схемы Pull-Push). Репликация между станцией и сервером для конкретной базы может быть инициирована со станции вручную выбором File - Replication - Replicate в основном меню или Replicate во всплывающем меню базы. Однако значительно более удобно пользоваться мощными возможностями закладки Replicator.
Возможны и фоновые репликации по расписанию. Расписание фоновых репликаций определяется в документах Location из персональной адресной книги.
Репликационные конфликты
Когда репликатор обнаруживает конфликт, он выбирает версию документа, имеющую более позднее время модификации, и сохраняет в "своей" реплике в качестве главного документа. Другая версия этого документа тоже сохраняется в "своей" реплике, но в качестве ответного документа (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 number> in database <database name> is damaged:"
· " Document is damaged or obsolete (unrecognized data type)"
· "Document is damaged or obsolete (unrecognized field)"
· Некорректно (в "физическом" смысле) удаленный документ
· "Document NT <document number> in database <database name> has been deleted"
· Разрушенный вид
· "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-серверов".
Серверные задачи
Серверная задача - разработанная с учетом специальных соглашений программа для работы на сервере Notes. Соглашения по разработке серверных задач можно найти в документации, входящей в состав Notes API.
Серверные задачи бывают двух разновидностей:
· Add-In Program
- обычно запускается при старте сервера и работает до его завершения, получает "задания на выполнение работ" от других задач сервера через очередь событий или посредством циклического опроса чего-либо, "показывает свое состояние" по команде консоли Show Task и обычно может принимать и выполнять собственные команды, передаваемые ей по команде консоли Tell. Типичный пример - маршрутизатор почты Mail Router.
· Main Program
- запускается по расписанию или команде консоли для выполнения какого-либо однократного действия, после чего автоматически завершается. Обычно может "показывать свое состояние" по команде консоли Show Task. Часто может быть запущена и непосредственно из операционной системы, когда сервер Notes остановлен. Типичный пример - "уплотнитель баз" Database Compactor.
Ниже рассматриваются серверные задачи, которые входят в стандартный комплект поставки сервера. Данный материал достаточно важен, поскольку позволяет получить представление о том, как работает сервер Notes.
Серверные задачи 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.
Схема 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 может шифроваться. Шифрование отправляемой, входящей и сохраняемой почты осуществляется по комбинированной схеме: шифрование одним случайно сгенерированным ключом шифрования с последующим шифрованием этого ключа по схеме с двумя ключами.
