Изменение имени пользователя с использованием серверной задачи ADMINP
Пользователю, решившему поменять свое имя, достаточно просто сообщить об этом своему сертификатору. Сертификатор "отмечает" документ Person этого пользователя в общей адресной книге, а затем выбирает в меню Action - Rename Person.
Рис. 8.21 Окно Certify Selected Entries
В появившемся окне нажимает кнопку Change Common Name. Далее выбирает соответствующий ID-файл сертификатора.
Рис. 8.22 Выбор ID-файла сертификатора
В появившемся после ввода пароля для ID-файла сертификатора диалоговом окне вводит новое имя пользователя.
Рис. 8.23 В окне вводится новое имя пользователя
Нажимает кнопку Rename и получает "окно-квитанцию" о передаче запроса на переименование в базу данных Administration Requests.
Рис. 8.24 "Квитанция" о приемке запроса
Все последующие шаги происходят автоматически.
1. В базу Administration Requests на том же сервере, адресная книга которого открыта, добавляется документ Address Book Change, и далее этот документ реплицируется в базы Administration Requests других серверов домена.
2. В базе Certification Log протоколируется осуществленный акт сертификации, и далее этот документ реплицируется в базы Certification Log других серверов домена.
3. Задача Adminp на сервере администрирования, назначенном для адресной книги, сканирует свою базу Administration Requests, находит в ней документ Address Book Change и в соответствии с этим документом изменяет документ Person для этого пользователя в своей адресной книге. После этого вставляет документ Status в свою базу Administration Requests.
4. Изменения в адресной книге репликациями достигают других серверов домена.
5. Наступает время, когда пользователь, пожелавший изменить свое имя, под своим "старым" ID-файлом обращается к одному из серверов домена. В этот момент пользователь получает диалоговое окно с предложением изменить имя в ID-файле. Он соглашается с предложением, и его станция выполняет изменения в ID-файле и заменяет в нем иерархический сертификат на новый.
6. Сервер, с которым пользователь устанавливал соединение, добавляет в свою базу Administration Requests документ Update Address Book.
7. Изменения в базе Administration Requests репликациями достигают других серверов домена.
8. Задача Adminp на сервере администрирования, назначенном для адресной книги, сканирует свою базу Administration Requests, находит в ней документ Update Address Book и в соответствии с этим документом изменяет старое имя пользователя на новое во всех остальных документах, в которых старое имя могло встречаться. После этого создает документ Update ACL в своей базе Administration Requests. В версиях Notes от 4.5
дополнительно создается документ Rename in Reader/Author fields.
9. Изменения в базе Administration Requests репликациями достигают других серверов домена.
10. Задачи Adminp на серверах домена сканируют свои базы Administration Requests, находят документ Update ACL и в соответствии с этим документом изменяют старое имя пользователя на новое в списках управления доступом всех тех баз, для которых данный сервер является сервером администрирования.
11. Изменения в списках управления доступом баз реплицируются на другие серверы домена.
12. В версиях Notes от 4.5 еженедельно, обычно в 12 часов дня в воскресенье, задачи Adminp на серверах домена сканирует свои базы Administration Requests в поисках документов Rename in Reader/Author fields. В соответствии с этими документами задачи изменяют старое имя пользователя на новое в полях типа Readers и Authors
всех тех баз, для которых данный сервер является сервером администрирования, а в списке управления доступом базы на закладке Advanced разрешено модифицировать поля типа Readers и Authors.
13. Изменения в полях типа Readers и Authors
реплицируются на другие серверы домена.
Электронная подпись
Могут быть "подписаны" почтовые сообщения или отдельные поля в документах. В случае "подписанной" почты Notes гарантирует получателю, что лицо, указанное в поле адреса отправителя (поле From), действительно было отправителем этого письма, и что "в пути" в это письмо не было внесено изменений. В случае подписанных полей в документе Notes гарантирует лицу, читающему документ, что в этих полях находится точно та же информация, какая была в них в момент сохранения документа лицом, эти поля "подписавшим". Но если ID-файл подписавшего письмо или документ лица был украден и не был защищен паролем или пароль известен похитителю, возможна и "подделка подписи".
"Электронная подпись" тесно связана с шифрованием и сертификатами. Подпись
представляет собой вычисляемую по алгоритму хеширования RSA's Message Digest 2 (MD2) контрольную сумму (fingerprint - "отпечаток пальца") по данным из подписываемых полей документа, размером в 128 бит, которая (значение контрольной суммы) в свою очередь зашифрована личным ключом пользователя и добавлена к документу. Изменение единственного бита в подписанных данных с высокой вероятностью приводит к изменению контрольной суммы. Это делает очень маловероятным (хотя теоретически возможным) такое изменение данных в подписываемых полях документа, что при этом контрольная сумма не изменится.
Как обеспечить работу на сервере нескольких репликаторов
Если в документах Connection запланированы одновременные или перекрывающиеся по времени репликации с несколькими серверами, следует иметь на сервере несколько одновременно работающих репликаторов. При этом станут возможны одновременные репликации с разными серверами - каждый репликатор с одним сервером одновременно. Например, если на одно и то же время запланированы репликации сервера А с серверами B и С, и на сервере А запущено два репликатора, один из них будет выполнять репликацию с сервером B, в то время как второй - с сервером C.
Для запуска нескольких репликаторов возможны следующие варианты.
· Переменная Replicators или переменная ServerTasks из файла NOTES.INI сервера.
· Команда Load Replica с консоли.
· Команда Load Replica имя_сервера с консоли. Запущенный такой командой репликатор завершится после выполнения репликации с указанным сервером, что эквивалентно команде Replicate имя_сервера.
· Запуск репликатора на уровне операционной системы.
Запуск репликатора на уровне операционной системы выполняется командой
хREPLICA [direction] servername [filename or directory] ,
где:
· х - "I" для OS/2, "N" для Windows NT или Windows 95, "V" для Netware;
· [direction] - необязательный параметр, определяющий тип репликации:
· пусто - Pull-Push,
· -p - Pull-Only,
· -s - Push-Only;
· Servername
- имя вызываемого сервера;
· [filename or directory] - необязательный параметр, задающий имя файла базы или каталог с базами, для которых должна выполняться репликация.
Для того чтобы избежать недоразумений при столь необычном запуске репликатора, проверьте, чтобы в переменных KeyFileName и ServerKeyFileName из файла NOTES.INI были указаны одни и те же ID-файлы. Репликатор, запущенный на уровне операционной системы, будет работать под ID из KeyFileName, в то время как сервер Notes и запущенный из него репликатор работают под ID из ServerKeyFileName.
Наконец, целесообразность применения такого способа запуска репликатора неочевидна, и, начиная с версии 4.5, упоминание о нем в базе Notes Administration Help исчезает.
После того, как на сервере уже запущено несколько репликаторов, их можно остановить, но только все сразу, командой Tell Replica Quit.
Как отождествляются между собой
Подобно идентификатору реплики базы, каждый документ в любой базе Notes имеет свой универсальный идентификатор документа (DocumentUniqueID или UNID). Вы можете "увидеть" универсальный идентификатор документа в окне свойств этого документа.
Рис. 6.9 Универсальный идентификатор документа обведен рамкой
Универсальный идентификатор документа используется при репликациях для нахождения "одинаковых" - имеющих один и тот же универсальный идентификатор - документов в обеих репликах базы.
Если имеющийся в двух репликах документ был модифицирован в одной из реплик, остается по дате модификации выяснить более новую версию и заменить ею документ в другой реплике.
Если в одной из реплик появился новый документ, то у него свой универсальный идентификатор, а в другой реплике нет документа с таким же универсальным идентификатором, так что приходится добавить этот документ в другую реплику.
Если же документ присутствовал в обеих репликах, но затем был удален в одной из них, при удалении Notes заменяет этот документ на "deletion stub". Deletion stub (stub - пень, корень зуба, окурок, ам. корешок чековой книжки) можно рассматривать как документ с тем же универсальным идентификатором, который имел удаленный документ, с датой модификации, соответствующей моменту удаления, и не содержащий никаких полей данных. В соответствии со сказанным выше о модификации документа в одной из реплик при репликации "оставшийся от документа окурок" должен заменить в другой реплике "нормальный", но имеющий более раннюю дату модификации, документ.
"Окурок", как бы мал он ни был, занимает место в базе данных. Постепенно в базе происходит "накопление окурков". Для решения этой проблемы в репликационных установках каждой базы присутствует параметр, называемый "интервалом удаления" - это количество дней XXX в поле с меткой Remove documents not modified in the last: XXX days (см. Рис. 6.10). По умолчанию параметр принимается равным 90 дней, но может быть изменен. В базах данных, находящихся как на сервере, так и на станции, в некоторые моменты времени выполняется удаление "окурков". В базах, находящихся на сервере, процесс удаления "окурков" запускается с интервалом в 1/3 от интервала удаления (по умолчанию раз в каждые 30 дней). При этом удаляются только те "окурки", которые появились в базе раньше, чем текущее время (когда выполняется процесс удаления "окурков") минус интервал удаления.
Будьте внимательны: речь шла только о поле с меткой Remove documents not modified in the last: XXX days, содержащем количество дней XXX, а вовсе не о выборе самой опции Remove documents not modified in the last: XXX days. Если вы выберите эту опцию, то в базе станут автоматически удаляться документы, которые не изменились за последние XXX (интервал удаления) дней. Процесс же удаления "окурков" функционирует независимо от того, выбрана эта опция или нет, и не имеет к ней никакого отношения.
Возможна ситуация, когда "окурки" будут удалены до того, как произойдет репликация. Например, если базы реплицируются один раз в неделю, а интервал удаления равен 3 дня, то процесс удаления "окурков" запускается ежедневно, устраняя при этом "окурки с возрастом" не менее трех дней. При этом репликатор может вновь восстанавливать удаленный в одной реплике документ из другой реплики. Так что в случае, если такое явление происходит, увеличьте интервал удаления и, тем самым, интервал запуска процесса удаления "окурков".
Как влияет шифрование почты на выполнение
Шифрование почты практически не влияет на скорость передачи сообщения от отправителя к получателю, поскольку размер шифрованного сообщения лишь немного больше размера нешифрованного. Шифрование, однако, увеличивает затраты времени в момент отправки сообщения (когда выполняется шифрование) и в момент получения сообщения (потому что его надо дешифрировать). Количество дополнительного времени на шифрование и дешифрирование - функция размера сообщения и количества графических образов, объектов и присоединенных файлов, содержащихся в сообщении.
Как влияют на репликацию списки управления доступом реплик базы
Для уяснения принципа влияния списка управления доступом (ACL) на репликацию лучше "временно забыть", что в действительности вначале репликатор на сервере А "тянет к себе" информацию с сервера В. Влияние ACL на репликацию таково, что если что-то (изменения в ACL, дизайн, документы...) поступает на сервер А, то это "как бы записывает" сервер В, а значит, его "возможности по записи" таковы, как то указано для сервера B в ACL на сервере А. И наоборот, когда выполняется вторая фаза репликации. Вне зависимости от того, "заталкивает" ли репликатор сервера A информацию на сервер B
или сам репликатор сервера B "тянет ее к себе" с сервера A, эту информацию на сервер B "как бы записывает" сервер A, а значит его "возможности по записи" таковы, как то указано для сервера A
в ACL на сервере B.
A ç B (информация поступает с сервера В на сервер А)
| Если сервер B определен в ACL на сервере A как ... | При репликации сервер A принимает с сервера B ... | ||
| Менеджер | измененную ACL
новые или измененные элементы дизайна новые или измененные документы (включая удаления) | ||
| Дизайнер | новые или измененные элементы дизайна
новые или измененные документы (включая удаления) | ||
| Редактор | новые или измененные документы (включая удаления) | ||
| Автор | новые или измененные документы (включая удаления), в полях типа Authors которых явно или как член группы присутствует сервер В.
Но поскольку обычно сервер не является автором документа (если только его имя, явно или как члена группы, специально не внесли в поле типа Authors), рекомендуется избегать назначения для серверов такого уровня доступа в ACL баз | ||
| Депозитор | только новые документы |
Поскольку репликация обычно двусторонний процесс, необходимо анализировать и действие ACL "в обратную сторону" (когда информация поступает с сервера A на сервер B).
Рекомендации по настройке ACL
· База на сервере назначения принимает к себе только то, что ее ACL позволяет изменять серверу - источнику изменений. Хотите принимать в базу все - дайте серверу-источнику доступ менеджера, хотите только дизайн и документы - дизайнера, только документы - редактора. Если дополнительно необходимо, чтобы информация только принималась сервером назначения, но не поступала на сервер - источник изменений, в ACL его реплики дайте серверу назначения доступ читателя.
· Сервер - источник изменений должен иметь в ACL базы принимающего сервера тот же доступ, как и наивысший доступ пользователя на сервере-источнике.
· Если каждый сервер имеет доступ менеджера в ACL на обоих серверах и ACL был изменен на одной или на обеих сторонах, более новая версия ACL будет заменять более старую версию. Вся информация из более старой версии ACL будет потеряна. Если "старая" ACL после репликации "вернулась обратно", проверьте правильность установки времени и информации о часовом поясе на обоих серверах.
· Если сервер указан в ACL только как член группы, всякая выясняющая его уровень доступа сторона (сервер или станция) обращается за списком группы в свою локальную адресную книгу. С этим связана часто встречающаяся проблема при репликациях между станцией и сервером: если указать имя сервера
в ACL локальной реплики явно, сервер получает на станции заданный уровень доступа, если указать в ACL группу LocalDomainServers - сервер получает на станции только уровень доступа -Default-. Дело в том, что группа LocalDomainServers в персональной адресной книге станции обычно пуста. Аналогичный эффект может наблюдаться при использовании группы LocalDomainServers
(или других групп) при репликациях между серверами из разных доменов.
· Так как имеются достаточно много связанных с доступом моментов, могущих сделать репликацию неудачной или неполной - ACL, поля Readers и Authors, роли и Directory Links *) - администраторам остается предложить только общую стратегию поиска причин неудачной репликации: "смотреть" на реплику базы данных на "другой" стороне "под ID своего сервера" и руководствоваться правилом: что вы "видите", то вы и можете реплицировать, а что вы "не видите", то вы не можете реплицировать. Однако в версиях 4.х эта стратегия может "не сработать", если в ACL для имени вашего сервера был конкретизирован тип: "только как сервер".
*) Directory Link (в версиях 4.х Directory Pointer) - текстовый файл с расширением .DIR, находящийся в каталоге данных Notes и содержащий в первой строке полное название каталога с базами, иного, чем каталог данных Notes, а в остальных строках список пользователей и групп, имеющих доступ к базам в этом каталоге. Такая возможность часто применяется в случае, когда один диск компьютера переполнен базами, а другой диск свободен, или когда просто необходимо разграничить доступ к целым семействам баз.
Как выполняется маршрутизация почты
Маршрутизацией почты на каждом сервере занимается задача Router. Алгоритм маршрутизации использует данные из документов Person, MailInDatabase, Server, Connections и Domain общей адресной книги.
Так как документы Server определяют все серверы в одном домене и все поименованные сети Notes, документы Connection описывают связи между всеми серверами, а общая адресная книга реплицируется между всеми серверами в домене, все серверы домена имеют полную информацию о топологии сети в пределах домена. Эту информацию можно представить в виде ориентированного графа. Вершины графа соответствуют имеющимся серверам, а дуги отражают возможные соединения между серверами для передачи почты.
Рассмотрим это на примере (Рис. 7.7). В границах домена имеется 10 серверов Notes с условными именами S1 - S10. Информация о них содержится в документах Server адресной книги домена. В документах Server имеются сведения о поименованных сетях Notes - группах серверов, использующих для общения один и тот же тип сетевого протокола и способных в любое время соединяться между собой напрямую. В нашем примере четыре поименованных сети. Двусторонние пунктирные дуги между всеми серверами в границах поименованных сетей как раз и отражают тот факт, что почта внутри поименованных сетей всегда передается посредством прямого соединения серверов. Никаких документов Connection для этого создавать не требуется. Напротив, соединения серверов из разных поименованных сетей для передачи почты должны описываться документами Connection. В нашем примере 8 "внутридоменных" документов Connection
для передачи почты: S1 ®
S6, S6 ® S1, S3 ® S4, S4 ® S3, S4 ® S10, S10 ® S4, S10 ® S7, S7 ® S10. Кроме того, имеется 2 "междоменных" документа Connection для передачи почты: S2 ® X1 и S9 ® X2. Для "внешних" серверов X1 и X2 документов Server в адресной книге домена нет. Наличие "внешних" серверов следует из самих документов Connection. Сведения о наличии FAX-сервера и двух агентов передачи почты тоже формально следуют из имеющихся в адресной книге документов, но в данный момент не имеет смысла разбираться с этим подробнее.
Таким образом, каждый сервер (точнее, Router) домена "полностью знает" топологию своего домена и "знает" о наличии и способе соединения с некоторыми серверами из других доменов, однако "не знает" полной топологии других доменов.
Рис. 7.7 "Почтовая" топология домена как ориентированный граф
Числа на дугах графа не что иное, как "стоимость соединения". Для пунктирных дуг будем считать стоимость соединения равной 1. Таким образом, мы имеем ориентированный граф с заданными стоимостями (или длинами) дуг, а значит можем решать на нем оптимизационную задачу по выбору маршрута наименьшей стоимости (наименьшей длины) для доставки сообщения с одного сервера на другой (между двумя наперед заданными вершинами графа).
Кластеры из серверов Notes
Кластер из серверов Notes
- группа из до шести серверов Notes, взаимосвязанных и взаимодействующих между собой, чтобы обеспечить высокую степень доступности, масштабируемости и балансировку загрузки.
Высокая степень доступности (high availability)
Для лучшего уяснения смысла этого понятия полезно сравнить понятия отказоустойчивость
и высокая степень доступности.
Отказоустойчивость. Модель fault tolerant и continuous availability базируется на специализированных аппаратных средствах, позволяющих обнаруживать аппаратные неисправности и выполнять практически мгновенные переключения на находящиеся в горячем резерве "избыточные" аппаратные компоненты - будь то процессор, оперативная память, питание, подсистема ввода/вывода или система хранения информации. Такое переключение (cutover) происходит практически мгновенно и обеспечивает непрерывность предоставляемого пользователям обслуживания, но характеризуется высокой стоимостью аппаратных средств. При этом "избыточные" аппаратные компоненты, пока все функционирует нормально, не выполняют никакой полезной обработки. Кроме того, в такой модели не учитываются отказы программного обеспечения. А именно программное обеспечение, а не аппаратные средства, является намного более частой причиной отказов.
Высокая степень доступности. Модель high availability и fault resiliency предполагает наличие набора общесистемных и совместно используемых ресурсов, которые сотрудничают друг с другом, "отслеживая" состояние друг друга, по возможности распределяют между собой рабочую нагрузку, а при отказе некоторых ресурсов по возможности "берут на себя" их функции, чтобы гарантировать предоставляемое пользователям обслуживание. Кластеры Notes реализуют высокую степень доступности посредством программного обеспечения, которое быстро восстанавливает предоставляемые пользователям услуги, когда компьютер, его операционная система или сервер Notes испытывают отказ.
Итак, отказоустойчивая среда не предлагает никакого прерывания предоставляемого сервиса, тогда как в среде с высокой степенью доступности предполагается прерывание предоставляемого сервиса на минимально короткое время. В нормальном режиме работы отказоустойчивая среда не предполагает использования резервных компонент. В среде с высокой степенью доступности в нормальном режиме работы все компоненты функционируют, обеспечивая полное использование вычислительной мощности, кроме относительно небольших затрат на "отслеживание" состояния других компонент.
Для многих организаций по экономическим соображениям более приемлема среда с высокой доступностью и малым количеством времени на переключение, чем дорогостоящая отказоустойчивая среда. При объединении двух или более серверов Notes в кластер для поддержки "критических" баз данных, пока все серверы кластера функционирует нормально, будет использоваться вся вычислительная мощность. При отказе программного обеспечения сервера Notes или программно-аппаратных средств "несущего его" компьютера "критические" базы данных продолжат функционировать после кратковременного прерывания, вызванного отказом.
Масштабируемость
Если разместить реплики используемой многими пользователями базы данных на нескольких серверах-членах кластера, то намного большее количество пользователей сможет работать с такой базой данных. Это происходит, во-первых, за счет синхронизации реплик внутри кластера не по расписанию, а "почти в реальном времени", и во-вторых, благодаря переключениям (failover) обращений пользователей к реплике на "сильно загруженном" или уже обслуживающем большое количество пользователей сервере в реплику на "менее загруженном работой или пользователями" сервере.
Балансировка загрузки серверов в кластере
Администратор имеет возможность "балансировать" рабочую нагрузку серверов-членов кластера, задавая "порог загрузки" для каждого сервера. При возникновении события load balance ("превышен порог загрузки") программное обеспечение станции "переключает" пользователей, пытающихся обратиться к базе данных на "сильно загруженном" члене кластера, на реплику этой базы на доступном (порог загрузки не превышен) члене кластера.
Команды консоли сервера
На Рис. 3.1 дан вид окна консоли сервера. Администратор сервера может вводить команды "после приглашения" > .
Рис. 3.1 Консоль сервера на платформе Windows NT
Рассмотрим наиболее часто используемые команды консоли сервера. Обратите внимание, что в приведенных ниже форматах команд минимально-допустимые сокращения ключевых слов подчеркнуты.
Help Дает подсказку по форматам команд.
> help
BROADCAST "msg" ["user"] Broadcast a message to user(s) of this server
DROP ["username"] [ALL] Drop one or more sessions
EXIT [password] Exit server
HELP Help (Displays this help information)
LOAD pgmname Load program
QUIT [password] Quit (exit server)
REPLICATE servername Replicate two-way request
PULL servername Replicate one-way (pull)
PUSH servername Replicate one-way (push)
ROUTE servername Route mail to server
SET Set server option:
CONFIGURATION "variable=value" Configuration variable
SECURE [current-password] [new-password] Secure Console Password
STAT [Facility] [Statname] Reset statistics
SHOW Show server information:
CONFIGURATION variable Configuration variable
MEMORY Memory information
PORT portname Port specific information
TASKS Server tasks
SERVER Server information
USERS Users with open sessions
DISKSPACE drive-letter Available disk space
SCHEDULE Next Schedule [Server/Program/Location] [Appl]
DIRECTORY Directory Information
TELL taskname command-string Send command-string to a task
Set Configuration "переменная=значение" Устанавливает значение переменной в файле NOTES.INI. Полезность команды состоит в том, что выполненное изменение "вступает в силу" немедленно. Перезапуска сервера, как после "ручной коррекции" файла NOTES.INI, не требуется.
> set conf "Log_Sessions=0"
08.09.96 09:51:47 LOG_SESSIONS changed to 0.
Show Configuration переменная Показывает на консоли текущее значение переменной из файла NOTES.INI.
> sh conf Log_Sessions
LOG_SESSIONS=1
Show Diskspace буква_диска Показывает, сколько памяти свободно на диске.
> sh disk e
Available disk space 15 345 152 bytes
Show Memory
Показывает, сколько памяти (включая виртуальную) свободно на сервере.
> sh mem
Memory Available (including virtual): 32 112K bytes
Show Port имя_порта Показывает текущее состояние порта сервера: количество открытых сессий и их характеристики, трафик по порту, статистику ошибок... В качестве имени порта задают имена, которые были выбраны для портов при их установке (LANx, TCPIP, SPX, COMx и др.).
> sh po spx
SPX Port Driver
NetWare Bindery Services: Advertising with SAP
Notes SessionID: 01BC0006
Local Address Net: 00777777 Node: 008029E04954 Socket: 6078
Remote Address Net: 00000000 Node: 000000000000 Socket: 0000
Session State: (listening)
> sh po tcpip
TCP/IP Port Driver
Transport Provider: TCP
Notes Session Local Address Foreign Address
00860004 *.* 194.73.241.129.1352
00890003 *.* 198.114.68.48.1352
00880006 194.220.151.250.1352 194.220.151.79.1033
008D0005 *.1352 *.*
> sh po lan4
NetBIOS Port Driver
Port LAN4 is using Unit/Lana 4 while the Notes server is running
Unit/Lana number: 2
This net has not been initialized by Notes
Unit/Lana number: 4
Unit ID: 00 80 29 E0 49 54 Version: 254.0
Reporting period (minutes): 0
Maximum packet size: 1482
Errors Transmits Receives
CRC 1 Successful 31995 Successful 30701
Alignment 0 Aborted 0 Dropped 0
Collision 4 Retransmitted 92
Control Blocks (NCBs) Sessions
Free 255 Current 3
Configured 255 Configured 254
Maximum 255 Maximum 254
Name Num Status
NOTESSRV400 + 2 04h registered
IRISNAMESERVER 3 3 84h registered group
xNotes......).IT 4 04h registered
LSN State Local Name Remote Name Receives Sends
48 03h connected NOTESSRV400 + xInterS.....).IQ 1 0
185 01h listening IRISNAMESERVER 3 * 0 0
186 01h listening NOTESSRV400 + * 0 0
> sh po com3
Answered incoming call from system KTEK_MAIN/KTEK/RU
Counts since the beginning of the current connection:
57600 Bit per second connection (port speed)
4800 Bit per second connection (carrier speed)
2 Currently active sessions
15 User messages sent
47 User messages received
1090 User bytes sent
66732 User bytes received
3 Retransmitted packets
0 CRC errors detected
0 Port errors detected
> sh po com4
Waiting for incoming call
Counts since the beginning of the last connection:
16 User messages sent
21 User messages received
3921 User bytes sent
2051 User bytes received
0 Retransmitted packets
0 CRC errors detected
0 Port errors detected
Show Tasks
Показывает имя сервера; его каталог; время функционирования (с момента старта сервера); число выполненных транзакций (с момента старта сервера); скорость как число транзакций в минуту - за последнюю минуту, за последний час и во время наибольшей загрузки (пик) с момента старта; наибольшее число одновременно работавших пользователей с момента старта; количество ожидающих и "мертвых" почтовых сообщений; список выполняющихся задач и их статус.
Основная часть информации в приведенном на Рис. 3.1 окне - отклик на команду SHow Tasks. Активны серверные задачи: Database Server (выполняет все транзакции удаленного пользователя: открытие, закрытие, чтение и запись баз; выполняет команды консоли; ожидает запросы на соединение по СOM- и LAN-портам и пр.), Replicator (выполняет репликации баз между серверами, но не между сервером и станцией), Router (занимается доставкой почты), Indexer (оперативно обновляет индексы баз), Agent Manager (занимается выполнением агентов в базах на сервере).
Show Users
Показывает список работающих с сервером пользователей и открытых ими баз, а для каждой открытой базы - время в минутах, прошедшее с момента последней транзакции станции пользователя с базой, например, чтения документа.
> sh us
User Name Databases Open Minutes Since Last Used
Nikolay N. Iontsev/InterTrustCorp/SU
mail\NIontsev.nsf 0
log.nsf 8
Show Directory
Показывает список баз в каталоге данных сервера Notes и рекурсивно в его подкаталогах, а также в каталогах Directory Link и рекурсивно их подкаталогах. Для каждой базы дается время модификации и количество реплик на данном сервере (если их более одной).
> sh dir
e:\notes400\data\mail.box, ModTime = 08.09.96 04:00:08
e:\notes400\data\mailobj.nsf, (2 Replica's) ModTime = 07.09.96 11:26:10
e:\notes400\data\x\ITNEWS.NSF, ModTime = 25.08.96 02:08:03
e:\notes400\data\x\DOC_KEY.NSF, ModTime = 11.06.96 02:08:53
e:\worksale\ITDocLib.nsf, ModTime = 21.08.96 16:10:45
e:\worksale\DLIB_rab.NSF, ModTime = 21.08.96 16:10:35
e:\notes400\data\web41.ntf, ModTime = 26.08.96 13:23:20
. . .
e:\notes400\data\log.nsf, ModTime = 08.09.96 09:59:27
e:\notes400\data\names.nsf, ModTime = 08.09.96 09:52:00
Show Schedule
Показывает список работ по расписанию, запланированных сервером для выполнения в ближайшее время.
> sh sched
ECURAN/MAPO/RU Mail Routing 21:25 Today
ECURAN/MAPO/RU Replication 21:44 Today
InterTrust/InterTrustCorp/SU Mail Routing 20:25 Today
InterTrust/InterTrustCorp/SU Replication 20:25 Today
Show Stat имя_статистики Выдает статистику о работе сервера. При запуске с параметром выдается только статистика по требуемой теме.
> sh stat
Agent.Daily.AccessDenials = 0
Agent.Daily.ScheduledRuns = 0
Agent.Daily.TriggeredRuns = 5
...
Agent.Hourly.UsedRunTime = 45 Seconds
Comm.NetWare.SPX.StatsLogged = 0
Database.BufferControlPool.Peak = 65406
...
Database.NSFPool.Used = 28570
Disk.C.Free = 8,136,704
...
Disk.L.Size = 629,129,216
Disk.Remote = 5
Mail.AverageDeliverTime = 163
...
MAIL.WaitingRecipients = 0
Mem.Allocated = 3494368
...
Mem.Free = 63,361,024
Mem.PhysicalRAM = 4427776
NET.LAN0.BytesReceived = 32,526
...
NET.LAN0.Sessions.Recycling = 0
NET.LAN4.BytesReceived = 0
...
NET.LAN4.Sessions.Recycling = 0
NET.Log.CN=NotesSrv400/O=InterTrustCorp/C=SU.UnwrittenEntries = 2
NET.SPX.BytesReceived = 3,134
...
NET.SPX.Sessions.Recycling = 0
NET.TCPIP.BytesReceived = 0
...
NET.TCPIP.Sessions.Recycling = 0
Replica.Docs.Added = 0
Replica.Docs.Deleted = 0
Replica.Docs.Updated = 0
Replica.Failed = 13
Replica.Successful = 257
Server.BootID = 2875960
Server.CPU.Count = 1
Server.CPU.Type = Intel Pentium
Server.Name = CN=NotesSrv400/O=InterTrustCorp/C=SU
Server.OpenRequest.MaxUsers = 0
Server.OpenRequest.PreV4Client = 0
Server.OpenRequest.Restricted = 0
Server.OpenRequest.V4Client = 16
Server.Path.Data = e:\notes400\data
Server.Ports = TCPIP,LAN0,LAN4,SPX
Server.Sessions.Dropped = 0
Server.Task = Database Server: Perform console commands
Server.Task = Database Server: Listen for connect requests on SPX
Server.Task = Admin Process: Idle
Server.Tasks = 9
Server.Time.Start = 09/08/96 11:59:32
Server.Title = Win NT 3.51
Server.Trans.PerMinute = 0
Server.Trans.PerMinute.Peak = 35
Server.Trans.PerMinute.Peak.Time = 09/08/96 12:08:35
Server.Trans.Total = 126
Server.Users = 1
Server.Users.1MinPeak = 1
Server.Users.1MinPeakTime = 09/08/96 12:05:33
Server.Users.5MinPeak = 1
Server.Users.5MinPeakTime = 09/08/96 12:05:33
Server.Users.Peak = 2
Server.Users.Peak.Time = 09/08/96 12:06:00
Server.Version.Notes = International English R4.1
Server.Version.W32 = Windows NT 3.51
Stats.Time.Current = 09/08/96 12:57:50
Stats.Time.Start = 09/08/96 11:59:16
> sh stat mail
Mail.AverageDeliverTime = 163
Mail.AverageServerHops = 4
...
MAIL.Dead = 0
...
MAIL.WaitingRecipients = 0
> sh stat mail.Dead
MAIL.Dead = 0
Show Cluster Показывает из кеша данного сервера имя кластера, в который входит этот сервер, список всех членов кластера и их состояние, основываясь на информации, полученной в процессе "исследований" кластера (cluster probes). Каждый сервер в кластере во-первых, постоянно отслеживает собственное состояние, а во-вторых, постоянно "исследует" другие серверы кластера для получения информации об их состоянии.
Если данный сервер не член кластера, выдается сообщение "This system is not configured for a cluster".
> show cluster
Cluster Information
Cluster name: IntTrustCluster, Server name: NotesSrv400/InterTrustCorp/SU
Server cluster probe timeout: 1 minute(s)
Server cluster probe count: 10784
Server availability threshold: 0
Server availability index: 100 (state: AVAILABLE)
Cluster members (2)...
server: InterTrust/InterTrustCorp/SU, availability index: 95
server: NotesSrv400/InterTrustCorp/SU, availability index: 100
Broadcast "сообщение" ["имена пользователей"] Посылает сообщение всем или только указанным пользователям. Если станция пользователя имеет активную сессию с сервером, сообщение появляется у пользователя на панели состояния (Status Bar),
> b "Server will be stopped on 10 minutes"
10:03:28 BROADCAST from NotesSrv400/InterTrustCorp/SU: Server will be stopped on 10 minutes (сообщение отправляется в том числе и серверу)
Рис. 3.2 Фрагмент панели состояния станции с полученным сообщением
Drop "имена пользователей" | All Закрывает перечисленные или все сессии пользователей или серверов.
> drop "Nikolay N. Iontsev/InterTrustCorp/SU"
08.09.96 12:07:25 Closed session for Nikolay N. Iontsev/InterTrustCorp/SU
Databases accessed: 1 Documents read: 1 Documents written: 0
Exit или Quit Останавливает сервер. Рекомендуется предварительно предупредить пользователей, чтобы они успели сохранить выполненные изменения в открытых документах из баз на сервере. Если этого не сделать, пользователи могут потерять эти изменения, если только не сохранят их (как текст) в локальной базе или файле или не дождутся рестарта сервера. Процессы же репликаций и пересылки почты будут остановлены и возобновлены в следующий по расписанию интервал после рестарта сервера.
Pull имя_сервера
[имя_базы] Запускает репликацию в одном направлении: ваш сервер принимает изменения с сервера, имя которого задано в команде.
Если параметр [имя_базы]
не указан в команде, в репликации участвуют все базы данных, реплики которых присутствуют на обоих серверах; если указан - в репликации участвует только заданная база (при условии, что ее реплика имеется на другом сервере).
> pull InterTrust/InterTrustCorp/SU names.nsf
08.09.96 12:10:15 Database Replicator started
08.09.96 12:10:15 Network: Connecting to InterTrust/InterTrustCorp/SU over LAN0
08.09.96 12:10:17 Network: Connected to server InterTrust/InterTrustCorp/SU
08.09.96 12:10:17 Starting replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:17 Finished replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:18 Database Replicator shutdown
> pull InterTrust names.nsf (к вопросу, следует ли указывать полное имя сервера)
08.09.96 12:09:39 Database Replicator started
08.09.96 12:09:39 Network: Connecting to InterTrust/InterTrustCorp/SU over LAN0
08.09.96 12:09:41 Network: Connected to server InterTrust/InterTrustCorp/SU
08.09.96 12:09:42 Starting replication with server INTERTRUST
08.09.96 12:09:42 Access control is set in names.nsf to not allow replication from INTERTRUST names.nsf
08.09.96 12:09:42 Finished replication with server INTERTRUST
08.09.96 12:09:42 Database Replicator shutdown
В последнем случае репликация начинается, но заканчивается неуспешно. В списке управления доступом принимающего информацию сервера только "полное" имя InterTrust/InterTrustCorp/SU имеет доступ менеджера, а заданное в команде "краткое" имя InterTrust отсутствует. Поэтому "краткое" имя InterTrust получает на принимающем информацию сервере только доступ читателя (как -Default-). Следовательно, информация при репликации не может быть записана в базу на принимающем сервере.
Push имя_сервера
[имя_базы] Запускает репликацию в одном направлении: ваш сервер "заталкивает" изменения на сервер, имя которого задано в команде.
> push InterTrust/InterTrustCorp/SU names.nsf
08.09.96 12:10:32 Database Replicator started
08.09.96 12:10:32 Network: Connecting to InterTrust/InterTrustCorp/SU over LAN0
08.09.96 12:10:34 Network: Connected to server InterTrust/InterTrustCorp/SU
08.09.96 12:10:34 Starting replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:34 Finished replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:34 Database Replicator shutdown
Replicate имя_сервера [имя_базы] Запускает репликацию в двух направлениях: ваш сервер сначала принимает изменения с сервера, имя которого указано в команде, а затем "заталкивает" изменения с вашего сервера на другой. Команда обычно используется для выполнения быстрых изменений в репликах баз (не дожидаясь репликации по расписанию) или при тестировании репликационных или коммуникационных проблем.
> rep InterTrust/InterTrustCorp/SU names.nsf
08.09.96 12:10:46 Database Replicator started
08.09.96 12:10:46 Network: Connecting to InterTrust/InterTrustCorp/SU over LAN0
08.09.96 12:10:48 Network: Connected to server InterTrust/InterTrustCorp/SU
08.09.96 12:10:48 Starting replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:48 Finished replication with server INTERTRUST/INTERTRUSTCORP/SU
08.09.96 12:10:48 Database Replicator shutdown
Route имя_сервера
Запускает процесс передачи почты на указанный сервер. Команда имеет смысл только при передаче почты через модемные соединения, поскольку при соединениях в пределах одной поименованной сети Notes передача почты выполняется почти немедленно.
Load имя_программы
Запускает программу на сервере. Это может быть как серверная задача, так и иная программа. Она должна находиться в каталоге сервера или в каталогах, в которых операционная система выполняет поиск запускаемых программ.
Tell имя_серверной_задачи команда_для_серверной_задачи Передает cерверной задаче команду. Передаваемая команда зависит от конкретной задачи. Например, команда консоли Tell ROUTER QUIT передает серверной задаче ROUTER команду QUIT - для завершения этой задачи.
Команды на консоль сервера можно "отправлять" и со станции, выбрав в меню File - Tools - Server Administration… , затем выбрав нужный сервер и нажав в окне кнопку Console. Но такой привилегией обладают только администраторы сервера. Список же администраторов сервера задается в адресной книге в документе Server, в поле с меткой Administrators.
"Ответ" сервера на команду появляется в подокне Server response. Отметим, что с версии 4.5 в окне Remote console появилась возможность Live console ("Живая консоль"), позволяющая получать в окне Remote console все команды и сообщения, появляющиеся на консоли сервера, а не только "отклики" сервера на введенные с "удаленной" консоли команды.
Рис. 3.3 Окно удаленной консоли с откликом на команду Show Port Com4
Конфигурирование POPсервера
Серверная задача POP3 позволяет любому клиенту, поддерживающему протокол POP3 (например, Microsoft Internet Explorer, Netscape Navigator или Eudora Pro), получать почту из почтового ящика, находящегося на сервере Notes. Принцип работы этой задачи был рассмотрен в 3.2.17. Здесь обсуждаются вопросы настройки задачи POP3, создания почтового ящика и документа Person для POP3-клиента и настройки программного обеспечения POP3-клиента.
Задача POP3 запускается командой консоли Load POP3, а останавливается командой Tell POP3 Quit.
Настройка задачи POP3
К задаче POP3 имеют отношение следующие переменные из файла NOTES.INI.
· MailCharSet = значение. Определяет кодировку, в которой задача POP3 должна передавать сообщения POP3-клиенту. Чтобы POP3-клиент получал сообщения в кодировке Cyrillic KOI-8 (KOI8-R), должно быть задано MailCharSet=3308. Рекомендуем задать нужное значение переменной MailCharSet предварительно, еще до первого запуска задачи POP3 на сервере. Если переменная MailCharSet не определена, задача POP3
воспользуется значением переменной WWWDsp_Codepage (используется задачей WEB), которая в условиях нашей страны обычно равна 81 (Cyrillic Codepage 1251).
· POP3Domain = значение. Задает имя домена Internet для POP3-сервера. Применяется, если домен Internet для POP3-сервера не совпадает с доменом Internet
для сервера Notes, на котором работает задача POP3. Например, POP3Domain=inttrust.rinet.ru.
· POP3Port = значение. Если для протокола POP3
используется порт не со стандартным номером 110, задает номер порта.
· POP3_Enable_SSL = 1. Значение 1 разрешает использовать Secure Sockets Layer (SSL) на сервере POP3. Значение 0 или отсутствие параметра - запрещает.
Регистрация POP3-клиента
Чтобы "зарегистрировать" POP3-клиента, нужно:
· создать для него почтовый ящик по шаблону Mail (R4.5) (MAIL45.NTF) на сервере Notes, "несущем задачу POP3;
· в общей адресной книге создать для него документ Person, в котором:
· в полях First name, Middle initial и Last name указать имя, букву отчества и фамилию клиента;
· в поле User name указать иерархическое имя клиента;
· в поле Short name указать краткое имя (обычно буква имени и вслед за ней, без пробела, фамилия);
· в поле HTTP password задать пароль для клиента;
· в поле Mail System выбрать POP3;
· в поле Domain задать имя домена, которому принадлежит сервер Notes;
· в поле Mail Server указать имя этого сервера Notes;
· в поле Mail File указать путь на файл почтового ящика клиента;
· убедиться, что в поле Encrypt incoming mail выбрано No, поскольку
клиент POP3 не может принимать зашифрованную почту;
· в список управления доступом почтового ящика добавить имя клиента (в точности как было указано в поле User name
документа Person) с уровнем доступа Manager.
Настройка POP3-клиента
Пример настроек, выполняемых для Microsoft Internet Mail в составе Microsoft Internet Explorer, дается на Рис. 10.9 и Рис. 10.10. Однако в данном случае на сервере Notes, установленном на компьютере с хост-именем inttrust.rinet.ru, функционирует не только задача POP3, но и задача SMTPMTA
(агент передачи почты по протоколу SMTP). Поэтому настройки "охватывают" не только вопрос приема почты по протоколу POP3 из почтового ящика клиента с именем Nik N. Iontsev на сервере Notes, но и вопрос отправки исходящей в Internet почты непосредственно из Microsoft Internet Mail по протоколу SMTP через SMTP
MTA
на компьютере с хост-именем inttrust.rinet.ru. Входящие сообщения из Internet для NIontsev@intrust.rinet.ru принимаются SMTPMTA, конвертируются в формат Notes и помещаются в почтовый ящик для Nik N. Iontsev.
Рис. 10.9 Настройки Microsoft Internet Mail в составе Microsoft Internet Explorer
Рис. 10.10 Дополнительные настройки Microsoft Internet Mail в составе Microsoft Internet Explorer
Конфигурирование сервера Domino
Сервер Domino представляет собой задачу
с именем HTTP, запускаемую на сервере Notes
и позволяющую
клиентам, оснащенным Web-броузерами, получать доступ как к информации из баз данных, находящихся на сервере Notes, так и к HTML-файлам, находящимся в каталогах компьютера сервера Notes. Принцип работы задачи HTTP был рассмотрен в 3.2.16, а здесь уделяется внимание вопросам настройки и эксплуатации этой задачи.
Вопросы разработки в Notes Web-приложений - баз данных,
ориентированных на доступ с использованием Web-броузеров - не рассматриваются в этой книге. Ответы на них вы сможете найти в базе данных Lotus Notes and the Internet (вид Printed Book, категория Chapter 11 Domino Application Developer's Information).
Задача HTTP загружается командой Load http, a завершается командой Tell http quit. Чтобы задача автоматически запускалась при старте сервера, ее имя следует внести в список задач в переменной ServerTasks в файле NOTES.INI. Статистика работы сервера Domino может быть получена командой консоли Show stat domino.
Секция HTTP Server документа Server
Основные настройки задачи HTTP задаются в секции HTTP Server из документа Server
в адресной книге. Рассмотрим, группа за группой, многочисленные поля этой секции.
Рис. 10.5 Группы полей Basics и Operational Information из секции HTTP Server
Группа полей Basics определяет, как сервер контактирует с Web-броузерами.
· TCP/IP port number (по умолчанию 80). Задает номер порта, на котором сервер Domino должен "ожидать" запросы по протоколу HTTP. Стандартно для протокола HTTP используется порт 80. Не используйте значений, меньших чем 1024 (кроме стандартного 80), поскольку они зарезервированы для других прикладных программ TCP/IP. Если задается нестандартный номер порта, клиенты будут вынуждены явно задавать этот номер порта в URL. Например, URL http://domino.lotus.com:8080/ "запрашивает" начальную страницу с хоста domino.lotus.com, который "ожидает" запросы по протоколу HTTP на порту 8080. После изменения номера порта, чтобы эти изменения "вступили в силу", сервер Notes следует перезапустить.
· TCP/IP port status (по умолчанию Enabled). Выбор Enabled разрешает серверу Domino обслуживать запросы по протоколу HTTP, а выбор Disabled - запрещает. Должно быть разрешено обслуживание запросов хотя бы по одному из двух возможных протоколов:
HTTP или HTTPS (SSL). Если обслуживание запрещено по обоим протоколам, Domino не сможет функционировать. Если Domino должен обслуживать запросы только по протоколу HTTPS (SSL), выберите в этом поле Disabled.
· SSL port number (по умолчанию 443). Задает номер порта, на котором сервер Domino должен "ожидать" запросы по протоколу HTTPS (SSL). После изменения номера порта, чтобы изменения "вступили в силу", сервер Notes следует перезапустить.
· SSL port status (по умолчанию Enabled). Выбор Enabled разрешает серверу Domino обслуживать запросы по протоколу HTTPS (SSL), а выбор Disabled - запрещает. Должно быть разрешено обслуживание запросов хотя бы по одному из протоколов HTTP или HTTPS (SSL).
· Host name (по умолчанию пусто).
Поле должно содержать хост-имя компьютера, на котором установлен Domino. Это может быть любое хост-имя, которое определено для вашего компьютера на используемом DNS-сервере. Имя, указанное в поле, "возвращается" броузеру. Если ваш компьютер не имеет зарегистрированного на сервере DNS хост-имени, можно задать в этом поле IP-адрес вашего компьютера. Но при этом случае клиенты будут вынуждены задавать его IP-адрес в URL, например, http://194.220.133.11. Если вы оставляете поле Host name пустым, Domino будет использовать хост-имя, определенное в стеке протокола TCP/IP операционной системы.
· DNS lookup (по умолчанию Disabled). Выберите Enabled, если требуется, чтобы сервер Domino выполнял поиск хост-имени каждого своего клиента, обращаясь к серверам DNS. Выбор Enabled несколько ухудшает эффективность работы сервера Domino, однако в протоколах работы сервера Domino будут содержаться хост-имена клиентов, а не IP-адреса, и в фильтрах протоколирования вы сможете использовать как маски на основе хост-имен клиентов, так и маски на основе IP-адресов клиентов. Если же выбрано Disabled, сервер Domino не обращается к серверам DNS для определения хост-имени клиента.
Выбор Disabled улучшает эффективность работы сервера Domino, однако в протоколах работы Domino будут содержаться только IP-адреса клиентов и в фильтрах протоколирования вы сможете использовать маски только на основе IP-адресов клиентов.
· Default home page (по умолчанию default.htm). Если в качестве начальной страницы (home page) должен использоваться файл в формате HTML, укажите в этом поле имя этого файла. Тогда при обращении клиента к серверу Domino без явного указания нужной страницы Domino
будет просто загружать клиенту этот файл. HTML-файл должен располагаться в каталоге domino\HTML, а поле Home
URL (в группе полей Mapping) должно быть пустым. Если же в качестве начальной страницы должен использоваться документ About или навигатор из базы данных Notes, оставьте в этом поле значение по умолчанию, но в поле Home
URL укажите соответствующий URL, например, что-то подобное http://domino.lotus.com/domino.nsf?OpenDatabase для документа About или http://domino.lotus.com/domino.nsf/Main+Navigator?OpenNavigator
для навигатора.
· Maximum active threads (по умолчанию 40). Задает максимально возможное количество параллельно работающих подпроцессов (thread's), порождаемых задачей HTTP. Если заданный максимум достигнут, сервер Domino "отказывается отвечать" на новые запросы, пока уже принятые им запросы не будут обслужены и исполнявшие их подпроцессы не освободятся. Чем более мощный компьютер используется в качестве сервера, тем и большее максимально возможное количество подпроцессов должно задаваться в этом поле. Однако выбор слишком большого значения может привести к излишней трате ресурсов компьютера на "прокачку страниц" между оперативной памятью и файлом страниц. На платформе Windows NT рекомендуется экспериментально исследовать этот вопрос с применением приложения Performance Monitor.
· Minimum active threads (по умолчанию 20). Задает минимальное количество подпроцессов, всегда поддерживаемых задачей HTTP. Сервер Domino не будет закрывать подпроцессы "ниже этого минимума", даже если они неактивны, т.е. не обслуживают запросы. Подпроцессы же "сверх этого минимума" при переходе в неактивное состояние будут закрываться задачей HTTP
и открываться снова, когда это требуется.
Группа полей Operational Information управляет кэшированием, определяет используемый формат и стиль отображения графики, отображение видов и используемый набор символов.
Управление кэшированием.
· Cache directory (по умолчанию domino\cache). Определяет каталог, который сервер Domino должен использовать для сохранения графических и присоединенных файлов. Когда клиент запрашивает страницу с элементами графики, Domino преобразует каждый графический элемент в файл соответствующего графического формата, передает файл клиенту и сохраняет копию файла в каталоге кэша. Если Domino получает другой запрос на ту же самую страницу, он уже передает клиенту соответствующие файлы непосредственно из кэша. То же самое происходит и с присоединенными файлами - будучи "отсоединенными" из документа Notes для передачи клиенту, они "попадают" в кэш, а откуда в течение некоторого времени могут повторно использоваться Domino. Если в поле указывается не полный путь, то считается, что он был задан относительно каталога данных Notes.
· Garbage collection (по умолчанию Enabled) и Garbage collection interval (по умолчанию 60 минут). Чтобы не допустить "разрастания" кэша сверх максимального размера, рекомендуется разрешить (выбором значения Enabled в поле Garbage collection) периодическое выполнение сервером Domino процесса "уборки мусора". Процесс "уборки мусора" удаляет файлы из кэша, начиная с наименее часто используемых. Период, с которым запускается процесс "уборки мусора", запускается в поле Garbage collection interval.
· Maximum cache size (по умолчанию 50 MB). Максимальное количество дискового пространства, доступного для кэша (в МБ). Размер кэша обычно остается ниже заданного максимума, но может иногда становиться и немного большим. Когда максимальный размер кэша достигнут, автоматически запускается процесс "уборки мусора". Если никакое значение не задано (поле Maximum cache size пустое), сервер Domino вообще не применяет кэширование.
· Delete cache on shutdown (по умолчанию Disabled). Если выбрано Enabled, Domino будет "очищать кэш" при остановке сервера Notes. Если же выбрано Disabled, при перезапусках сервера Notes кэш будет сохраняться.
Формат и стиль отображения графики.
· Image conversion format (по умолчанию GIF). Domino может преобразовывать графические элементы из форм и документов Notes или в формат GIF, или в формат JPEG. В зависимости от того, какой из форматов был выбран вами в данном поле, будут присутствовать или отсутствовать следующие поля.
· (Выбран GIF) Interlaced rendering (по умолчанию Enabled). Если выбрано Enabled, Domino создает GIF-файлы в "чередуемом" формате. В GIF-файле "чередуемого" формата строки изображения сохранены не в обычной последовательности (строка за строкой от первой
до последней), а, например, вначале каждая восьмая строка изображения, затем каждая четвертая строка изображения, затем каждая вторая строка... Поэтому GIF-файл "чередуемого" формата в процессе загрузки в броузер отображается в окне броузера, как бы "приобретая все более и более четкие очертания". Поскольку глаз человека обладает свойством "восстанавливать" отсутствующие части изображения, у клиента создается впечатление, что загрузка изображения происходит быстро. Если же выбрано Disabled, Domino создает файлы GIF в обычном формате - такое изображение в окне броузера появляется "сверху вниз строка за строкой".
· (Выбран JPEG) Progressive rendering (по умолчанию Enabled). Если выбрано Enabled, Domino создает JPEG-файлы в "прогрессирующем" формате. Броузеры обычно загружают и отображают JPEG-файл обычного формата за один проход. JPEG-файл в "прогрессирующем" формате загружается и отображается за несколько проходов: изображение в окне броузера с каждым проходом приобретает "все более и более четкие очертания". В результате клиент может "идентифицировать" возникающее изображение прежде, чем оно полностью загружено в броузер.
· (Выбран JPEG) JPEG image quality (по умолчанию 75). Целое число в диапазоне от 5 до 100 (процентов), определяющее "качество изображения" в создаваемом Domino JPEG-файле. Большие значения - больший по размеру файл и лучшее качество изображения, малые значения - меньший по размеру файл, меньшее количество времени на загрузку, но более низкое качество изображения.
Отображение информации из вида и используемый набор символов.
· Default lines per view (по умолчанию 30). Количество "линий" из вида в базе данных Notes, "показываемое" сервером Domino в броузере на один запрос. Учтите, что эта установка используется для всех баз на сервере.
· Default character set group (по умолчанию Western). Набор символов, в котором HTML-текст будет предоставляться клиенту. Такой же набор символов должен поддерживаться и на компьютере клиента. Возможные варианты: Western, Central European, Japanese, Traditional Chinese, Simplified Chinese, Korean, Cyrillic, Greek, Turkish, Thai и Multilingual. Чтобы обеспечить поддержку русских букв, выбирают Cyrillic.
· Character set mapping (по умолчанию Latin1). Сервер Domino использует заданный в поле Default character set group набор символов и заданную в поле Character set mapping (Рис. 10.6) таблицу кодов символов при создании HTML-текста для броузера. Выбор в поле Character set mapping зависит от выбора в поле Default character set group. Если Default character set group
= Cyrillic, в поле Character set mapping можно выбрать таблицы кодов символов ISO-8859-5, CP1251 или KOI8-R.
Рис. 10.6 Группы полей Mapping, Logging, Timeouts и Character Set Mapping из секции HTTP Server
Группа полей Mapping задает местоположение HTML-файлов для сервера Domino. Учтите, что на одном компьютере "под одним сервером Notes" может функционировать несколько виртуальных серверов Domino (рассматривается ниже). В этом случае для каждого виртуального сервера Domino информация из группы полей Mapping "перекрывается" аналогичной информацией из документов Virtual Server базы данных DOMCFG.NSF.
· HTML directory (по умолчанию domino\html). Каталог для HTML-файлов. Если указан не полный путь, он "отсчитывается" относительно каталога данных Notes.
· Home URL
(по умолчанию /?Open). Укажите URL документа About, навигатора или иного элемента из базы данных Notes, HTML-образ которых Domino должен возвращать, когда клиенты "входят на сервер", не указывая явно (например, http://domino.lotus.com) требуемый им каталог или страницу. Использование значения по умолчанию /?Open влечет отображение списка баз данных на сервере (как по File - Database - Open в клиенте Notes). Для документа About
из базы данных URL выглядит подобно http://domino.lotus.com/domino.nsf?OpenDatabase, для навигатора из базы данных подобно http://domino.lotus.com/domino.nsf/Main+Navigator?OpenNavigator. Полное же описание
синтаксиса URL, поддерживаемого сервером Domino, вы сможете найти в базе данных Lotus Notes and the Internet
(вид:
Printed Book, категория: Chapter 11 Domino Application Developer's Information, документ: About the Domino URL commands). Но если вы используете начальную страницу (home page) непосредственно в формате HTML, очистите поле Home URL и укажите имя HTML-файла в поле Default home page.
· CGI URL path (по умолчанию /cgi-bin). Укажите URL-путь к каталогу программ CGI на сервере Domino. Этот путь, указываемый клиентом в URL.
· CGI directory (умолчанию domino\cgi-bin). Каталог для программ CGI. Если указан не полный путь, он "отсчитывается" относительно каталога данных Notes.
· Icon URL Path
(по умолчанию /icons). Укажите URL-путь к каталогу пиктограмм Domino. Этот путь, указываемый клиентом в URL. В большинстве случаев вы не должны изменить значения этого поля. Только если вы имеете собственный существующий каталог пиктограмм, укажите в поле URL-путь для доступа к этому каталогу.
· Path to icons (по умолчанию domino\icons). Каталог пиктограмм. Если указан не полный путь, он "отсчитывается" относительно каталога данных Notes.
Группа полей Timeouts задает временные ограничения для контактов между сервером Domino и Web-клиентом.
· Idle thread timeout (по умолчанию 0 минут). Интервал времени в минутах, в течение которого сервер Domino не должен закрывать неактивный подпроцесс. Подпроцесс становится неактивным после того, как он выполнил свой последний запрос. Если текущее количество подпроцессов больше, чем указано в поле Minimum active threads, и сервер Domino не использует некоторый подпроцесс в течение заданного интервала времени, сервер закрывает этот подпроцесс. Чтобы Domino вообще не закрывал неактивные подпроцессы, в поле задают значение 0.
· Input timeout
(по умолчанию 2 минуты). Максимальное время в минутах с момента установления клиентом HTTP-соединения с сервером Domino до посылки клиентом запроса на ресурс (GET URL). Если клиент не посылает запрос за заданное время, сервер Domino разрывает HTTP-соединение с ним.
· Output timeout
(по умолчанию 20 минут). Максимальное время в минутах, отводимое на передачу данных сервером Domino клиенту. По истечении этого времени сервер Domino "разрывает" HTTP-соединение с клиентом. Ограничение касается запросов на получение локальных файлов и информации из баз данных Notes, но не касается запросов, выполнение которых влечет запуск программ CGI.
· CGI timeout
(по умолчанию 5 минут). Максимальное время в минутах, отводимое на работу программе CGI, запущенной сервером Domino. Когда отведенное время истекает, сервер Domino
посылает программе CGI сообщение. Затем, еще через пять минут, сервер Domino "уничтожает" эту программу.
Протоколирование обращений к серверу Domino
По каждому HTTP-запросу, выполняемому броузером, сервер Domino способен протоколировать следующую информацию:
с какого IP-адреса (или DNS-имени) поступил запрос, какой броузер использует клиент, какой URL использовался для доступа, сколько байт передано, какие ошибки (если были) сгенерированны программами CGI. Протоколируемая информация может быть сохранена или в текстовом файле, или в базе данных Notes с именем DOMLOG.NSF, или в обоих местах сразу. Протоколирование в базу данных Notes обычно более удобно, но оно требует привлечения несколько больших ресурсов компьютера, чем протоколирование в текстовый файл.
Чтобы установить протоколирование в базу Notes, создайте базу данных DOMLOG.NSF в каталоге данных Notes по шаблону Domino Web Server Log (DOMLOG.NTF). Чтобы установить протоколирование в текстовый файл, заполните поля Access Log
(каталог для файлов протокола доступа) и Error Log (каталог для файлов протокола ошибок) в секции HTTP server документа Server (Рис. 10.6). Если установлены оба способа протоколирования, Domino записывает информацию в оба места. Поле Time stamp определяет формат, в котором записывается время обращения. Поле No Log
может содержать список тех IP-адресов, DNS-имен (если выбрана опция DNS Lookup) или их шаблонов, доступ с которых не должен протоколироваться.
Действие поля No Log распространяется как на протоколирование в базу Notes, так и на протоколирование в текстовый файл.
Чтобы отказаться от протоколирования в базу DOMLOG.NSF, удалите эту базу. Чтобы отказаться от протоколирования в текстовые файлы, "очистите" поля Access Log и Error Log в секции HTTP server документа Server.
Секция Security документа Server
Рассмотрим поля из секции Security
документа Server, относящиеся к вопросам безопасности сервера Domino.
Рис. 10.7 Секция Security документа Server
· Allow anonymous HTTP connections (по умолчанию Yes). Если в поле выбрано Yes, сервер Domino допускает анонимные HTTP-подключения. Каждый анонимный HTTP-клиент "будет фигурировать" на сервере под именем Anonymous. Доступ такого анонимного HTTP-клиента в каждой базе Notes определяется прежде всего списком управления доступом этой базы: как Anonymous или, если в ACL отсутствует имя Anonymous, как -Default-, но не выше максимального уровня доступа для HTTP-клиентов (Maximum internet brouser access). Если же в поле выбрано "No", сервер Domino вообще не допускает анонимных подключений. Тогда все HTTP-клиенты получают запрос на ввод имени и пароля при обращении к серверу Domino
и получают к нему доступ, только если они правильно указали имя и пароль, определенные для них в документе Person (пароль задается в поле с меткой HTTP Password:). В этом случае для "авторизованных" HTTP-клиентов уровень доступа для Anonymous
в списках управления доступом баз утрачивает смысл.
· Allow HTTP clients to browse databases (по умолчанию Yes). Если в поле выбрано Yes, HTTP-клиенты, указав URL http://host-name/?OpenServer, смогут получить список баз данных на сервере Notes. Когда же выбрано No, HTTP-клиенты не смогут получить список имеющихся на сервере баз, но смогут открывать конкретные базы данных, если знают их имена файлов и имеют к ним доступ.
· SSL key file (default=keyfile.kyr). Если сервер Domino сконфигурирован для SSL-транзакций, он может шифровать данные, передаваемые между сервером и HTTP-клиентом. Если такая возможность выбрана, в процессе шифрования используется указанный в данном поле файл.
Виртуальные серверы Domino (hosting multiple sites on one server)
На одном компьютере, "несущем" один сервер Notes
и одну задачу HTTP, может функционировать несколько виртуальных серверов Domino. Каждый виртуальный сервер Domino имеет собственные IP-адрес, Home URL, начальную страницу и каталоги HTML, CGI и Icons, но при этом структура каталога данных Notes для всех виртуальных серверов Domino остается одинаковой.
Подчеркнем, что каждый из виртуальных серверов Domino должен иметь свой собственный уникальный IP-адрес. Недостаточно иметь много DNS-имен, "отображенных" на один и тот же IP-адрес. Количество виртуальных серверов Domino
ограничивается только имеющимся оборудованием компьютера и способностью используемой операционной системы поддерживать для сетевых устройств компьютера (сетевой карты или модема, которым поддерживается PPP-соединение) соответствующее количество IP-адресов.
На сервере Notes создается база данных DOMCFG.NSF по шаблону Domino Configuration (DOMCFG.NTF). В этой базе для каждого "очередного" виртуального сервера Domino создается документ Virtual Server. Чтобы выполненные изменения "вступили в силу", перезапускают задачу HTTP. Таким образом, настройки для "первого" сервера Domino задаются в секции HTTP Server из документа Server, а настройки "очередных" получаются из настроек "первого" сервера Domino
заменой значений одноименных полей на значения из соответствующего документа Virtual Server.
Рис. 10.8 Документ Virtual Server
Обратите внимание, что в базе DOMCFG.NSF
имеются еще три могущие оказаться полезными формы для создания документов:
· Mapping URL ®
Directory - для перемещения каталогов HTML, CGI, images и других в новое местоположение без изменения URL, используемых клиентами для доступа к ним;
· Mapping URL ®
URL - для автоматической замены входящего URL на другой, соответствующий реальному местоположению на этом же HTTP-сервере;
· Redirection URL ®
URL - для автоматической замены входящего URL на другой, в том числе и расположенный на другом HTTP-сервере.
Кратко об ID-файле пользователя
Каждый сервер или пользователь Notes имеет свой уникальный ID - ассоциированный с сервером или пользователем уникальный файл. ID-файл идентифицирует своего владельца, как паспорт гражданина.
ID-файл создает сертификатор (certifier) - лицо, имеющее специальный ID-файл - так называемый ID-файл сертификатора. ID-файл сертификатора необходим только для сертификации ID-файлов пользователей и серверов. ID-файл сертификатора можно рассматривать как "печать-инструмент", с помощью которого сертификатор "ставит печать-оттиск" в ID-файл пользователя, т.е. добавляет в него сертификат.
При создании в ID-файл включаются:
· имя владельца ID (оно может быть изменено сертификатором в дальнейшем)
· тип и номер лицензии Notes
· сертификат ("печать-оттиск"), обеспечивающий серверу возможность аутентифицировать пользователя (устанавливать его подлинность), а станции пользователя в свою очередь аутентифицировать сервер. Когда вы впервые в сеансе работы пробуете открыть базу данных на сервере, сервер "заглядывает" в ваш ID, чтобы убедиться, имеете ли вы и этот сервер сертификат от одного и того же сертификатора. Если имеете, обычно доступ разрешается; если нет, доступ обычно отклоняется. Дополнительно на решение вопроса о предоставлении доступа могут повлиять взаимные сертификаты (но они хранятся не в ID-файлах, а в адресных книгах) и настройки в документе Server из общей адресной книги
· публичный ключ, используемый при шифровании почты и обеспечении "электронной подписи". Его копия заносится также в общую адресную книгу и становится доступной другим пользователям домена
· личный ключ, используемый при шифровании почты и обеспечении "электронной подписи". Он имеется только в ID-файле и нигде более. Невозможно извлечь личный ключ из ID-файла или создать новый ID-файл с таким же личным ключом. Однако сам ID-файл (вместе с хранящимся в нем личным ключом) может быть похищен
· пароль, применяемый для предотвращения неавторизованного доступа к базам на серверах с использованием вашего ID-файла.
После создания в ID-файле может быть:
· изменен пароль
· добавлены, удалены дополнительные ключи шифрования (они используются при шифровании полей в документах)
· заменены личный и публичный ключи.
Для исследования или изменения содержимого вашего ID-файла используйте диалоговое окно, получаемое из меню File - Tools - User ID.
Локальное шифрование баз данных
Пользователи с доступом менеджера к локальной базе данных (все, если опция Enforce a consistent Access Control List... не выбрана, или только указанные в ACL базы, если эта опция выбрана), могут "локально зашифровать" эту базу. Локальное шифрование осуществляется с использованием ID-файла пользователя (сервера). Такая возможность предотвращает доступ к данной базе или ее копии, сделанной средствами операционной системы, со станции Notes под другим ID-файлом.
При локальном шифровании базы данных Notes генерирует случайный ключ шифрования, использует его для шифрования информации в базе (криптосистема DES), а сам этот ключ шифрования шифрует публичным ключом используемого ID-файла (криптосистема RSA) и добавляет в зашифрованном виде в базу данных. Когда пользователь (сервер) пытается обращаться к локальной базе данных, Notes обеспечивают доступ только тогда, когда личный ключ в ID-файле этого пользователя позволяет расшифровать ключ шифрования (криптосистема RSA), используемый для шифрования информации в базе (криптосистема DES).
Пользователь может выбрать один из трех уровней шифрования. Выбор уровня шифрования основан на компромиссе трех факторов: степень защиты, быстродействие при доступе к базе и возможность применять средства сжатия (не Notes) для этой базы.
| Уровень шифрования | Степень защиты | Быстродействие при доступе | Применение сжатия | ||||
| Simple | Минимальная | Высокое | Да | ||||
| Medium | Средняя | Высокое | Нет | ||||
| Strong | Высокая | Более низкое | Нет |
Шифрование Simple удобно для предотвращения доступа к базе "взломщика" среднего уровня, и оно допускает применение средств сжатия для базы. Шифрование Strong обеспечивает наибольшую степень защиты, но неблагоприятно отражается на скорости доступа. Шифрование Medium - значение по умолчанию - дает большую скорость доступа, чем при шифровании Strong, но предлагает сравнимую со Strong степень защиты.
Локальное шифрование баз данных разработано для того, чтобы предотвратить несанкционированный локальный доступ к базе, оно вовсе не предназначено для замены шифрования на уровне полей в документе.
Локальное шифрование выбирается кнопкой Encryption в окне свойств базы.
Рис. 9.11 Нажимаем кнопку Encryption…
Рис. 9.12 Выбор локального шифрования
В следующем окне выбираем локальное шифрование (радиокнопкой Locally encrypt this database using …) и его уровень (выпадающий список), используемый ID-файл (обычно, текущий) и нажимаем кнопку Ok. Начинается процесс шифрования, "прогресс" которого отображается в окне. В этом же окне можно отменить локальное шифрование для уже зашифрованной базы, выбрав Do not locally encrypt this database.
Если другой пользователь (под другим ID-файлом) попытается получить доступ к базе с локальным шифрованием, он получит следующее диалоговое окно.
Рис. 9.13 Вашему ID-файлу к этой базе данных доступа нет
Mail-In Database - база, способная получать почту
Документы формы Mail-In Database используются для описания баз данных, в которые пользователи могут посылать почту. Документ означает, что любое письмо, отправленное по адресу, который совпадает с указанным в поле с меткой Mail-in name:, должно доставляться на сервер Server: из домена Domain: и помещаться на нем в базу данных Filename:. Исполняет "содержащееся в документе утверждение" серверная задача Mail Router.
Рис. 4.15 Пример документа Mail-In Database
Mail Transfer Agent's - агенты передачи почты
Функция агента передачи почты состоит, во-первых, в преобразовании сообщений Notes в формат "чужой" почтовой системы и доставке их по этой почтовой системе адресату, и, во-вторых, в приеме сообщений из другой почтовой системы, преобразовании их в формат сообщений Notes и доставке адресату по почте Notes. В отличие от почтового шлюза (mail gateway) агент как бы "двулик": со стороны "чужой" почтовой системы он "выглядит" как полнофункциональный почтовый сервер этой системы, а со стороны Notes - как сервер Notes, выполняющий функцию доставки почты. Шлюз же, в отличие от агента, не имеет в своем составе почтовый сервер "чужой" почтовой системы. Он способен лишь конвертировать сообщение в "чужой" формат и передать его, как файл, почтовому серверу "чужой" почтовой системы для доставки, и, в обратную сторону, получив как файл, сообщение от почтового сервера "чужой" почтовой системы, преобразовать его в формат Notes и организовать доставку.
В настоящее время компанией Lotus выпущены следующие MTA:
· SMTP MTA - обмен сообщениями с почтовыми системами, поддерживающими протокол SMTP (платформы Windows NT, OS/2, UNIX, версия 1.06),
· Х.400 MTA - обмен сообщениями с почтовыми системами стандарта Х.400 (платформы Windows NT и OS/2, версия 1.01),
· cc:Mail MTA - обмен сообщениями с cc:Mail (платформы Windows NT и OS/2).
Далее подробно рассматривается принцип работы SMTP MTA и документы, которыми выполняется его настройка.
Мониторинг доставки почты
Нормальная работа системы доставки почты слишком критична для пользователей. Поэтому администратор должен ежедневно наблюдать за функционированием системы доставки.
MAIL.BOX
В нем следует обращать внимание на количество ждущих отправки сообщений, на "мертвые" сообщения, а так же на количество свободного места на диске, содержащем эту базу.
Notes Log
В протоколе работы сервера есть вид Mail Routing Events, содержащий относящиеся к доставке почты события. Можно также управлять подробностью протоколирования в этом виде почтовых событий.
Серверная задача Reporter
Если она используется, то регулярно протоколирует статистику доставки почты в базе Statistics Reporting (STATREP.NSF). Администратор должен просматривать соответствующий вид в этой базе.
Серверная задача Event
Позволяет протоколировать отдельные группы событий, в том числе и связанные с доставкой почты.
Команды, передаваемые Mail Router
· Tell Router Delivery Stats - показывает статистику о доставке почты.
· Tell Router C
- уплотняет MAIL.BOX.
· Tell Router Show Queues - показывает сообщения, передаваемые на другие серверы.
· Tell Router Quit
- завершает задачу.
> tell router delivery stats
Message Sizes Minimum Average Maximum
1 K 214 K 40010 K
Delivery Times Minimum Average Maximum
00:00:01 00:03:56 07:31:14
Server Hops Minimum Average Maximum
1 Hops 1 Hops 8 Hops
> tell router C
03.09.96 18:13:40 Router: Shutdown is in progress
03.09.96 18:13:40 Router: Beginning mailbox file compaction
03.09.96 18:13:45 Router: Completed mailbox file compaction
> tell router show queues
Server Name Msgs Ready
Max Threads = 4; Total Threads = 1; Inactive Threads = 0
Настройка сетевых портов
Если сервер должен работать по нескольким сетевым протоколам, необходимо настроить порты. Настройки сетевых портов для сервера выполняются со станции Notes, запущенной на компьютере, где установлен сервер Notes, но при условии, что программа сервера Notes остановлена. Аналогично выполняются и настройки сетевых портов для станции Notes.
Выбор в меню File - Tools - User Preferens и далее закладки Ports даст диалоговое окно, используемое для настройки портов.
Рис. 2.18 Настройка портов
В списке Communication Ports: перечислены имеющиеся порты. Галочкой отмечены используемые порты. Часть портов в этом списке не используется. Чтобы задействовать неиспользуемый порт, достаточно выбрать порт в списке и включить флажок Port Enabled или дважды щелкнуть мышью по названию порта. Аналогично поступают, чтобы сделать порт неактивным. Кнопка New служит для добавления нового порта, Rename - для изменения имени существующего порта, Delete Port - для удаления порта, а Show Status - для отображения текущего состояния порта.
Рис. 2.19 Добавление нового порта
Имя порта (при добавлении нового порта или изменении имени существующего) можно задать любым. "Область действия" имени порта - только данный сервер или станция. Драйвер - название драйвера Notes, который должен обслуживать данный порт: NETBIOS - драйвер для поддержки протокола NetBIOS, NWSPX - драйвер для поддержки протокола Novell SPX, TCP - драйвер поддержки протокола TCP/IP (Windows 95/NT, Novell NetWare, OS/2), XPC - драйвер для поддержки последовательного порта и управления подключенным к нему модемом. Ошибиться в имени драйвера при создании нового порта невозможно - в версиях 4.х оно выбирается из раскрывающегося списка. Каждый драйвер порта реализуется соответствующей библиотекой динамической компоновки, входящей в комплект поставки. Только драйверы портов X.25 и SNA поставляются отдельно, а не в комплекте поставки Notes.
Для некоторых портов (это зависит от используемого драйвера порта) становится доступной кнопка <имя драйвера> Options. При нажатии кнопки появляется окно для задания специфической информации для конкретного драйвера.
Рис. 2.20 Для драйвера NETBIOS на сервере необходим номер Unit/Lana
Рис. 2.21 Для драйвера NETBIOS на станции возможно автоматическое определение номера Unit/Lana
Для портов сервера Notes, обслуживаемых драйвером NETBIOS, необходимо явно задавать номер Unit/Lana. Номер Unit/Lana используется только драйвером NETBIOS. Это связано с тем, что NetBIOS - "высокоуровневый интерфейс", и он всегда реализуется по какому-то "более низкоуровневому" протоколу (Novell IPX, TCP/IP, NETBEUI…). На одном компьютере (обычно, сервере Notes) может быть установлено несколько интерфейсов NetBIOS, но при этом каждый из них реализуется по разным "низкоуровневым" протоколам. Чтобы различать "разные реализации" NetBIOS, используется номер Unit/Lana.
Наиболее наглядно значения Unit/Lana можно наблюдать в настройках интерфейсов NetBIOS для компьютера под Windows NT (Рис. 2.22 - Рис. 2.24). В этом примере на сервере имеется два порта NETBIOS, например, с именами LAN0 и LAN4. Пусть для порта LAN0 задан Lana Number 0, что соответствует интерфейсу NetBIOS, реализуемому "поверх" Novell IPX, а для порта LAN4 - Lana Number 4, что соответствует интерфейсу NetBIOS, реализуемому "поверх" NETBEUI. Таким образом, к этому серверу могут получить доступ два типа клиентов Notes.
Во-первых, клиенты Notes, на компьютерах которых установлена поддержка протоколов Novell IPX/SPX
и интерфейса NetBIOS поверх Novell IPX (например, NetWare Client for Windows 3.1). На таком клиенте Notes в настройках порта, обслуживаемого драйвером NETBIOS
(обычно порт с именем LAN0), выбирают Automatic setup. Такой клиент будет получать доступ к серверу по "серверному" порту, поддерживающему интерфейс NetBIOS "поверх" Novell IPX (порт сервера LAN0).
Рис. 2.22 Несколько интерфейсов NetBIOS, каждый реализуется по своему "низкоуровневому" протоколу
Рис. 2.23 NetBIOS "поверх" NW Link IPX имеет Lana Number 0
Рис. 2.24 NetBIOS "поверх" NETBEUI (NBF) имеет Lana Number 4
Во-вторых, клиенты Notes, на компьютерах которых установлена поддержка сети Microsoft c интерфейсом NetBIOS (например, Windows 3.11 или Windows 95). При этом неявно имеется в виду, что интерфейс NetBIOS реализуется "поверх" NETBEUI. На таком клиенте Notes в настройках порта, обслуживаемого драйвером NETBIOS
(обычно порт с именем LAN0), также выбирают Automatic setup. Такой клиент будет получать доступ к серверу по "серверному" порту, поддерживающему интерфейс NetBIOS "поверх" NETBEUI (порт сервера LAN4).
Для драйвера NWSPX "вопросы" касаются использования NDS (Novell NetWare версий 4.х) и (или) Bindery Services (Novell NetWare версий 3.11, 3.12). Учтите, что работа сервера Notes по протоколу SPX в сети на базе Microsoft Windows NT, имеющей несколько сегментов, но не имеющей ни одного файл-сервера Novell NetWare, невозможна. Кроме того, для клиентов Notes на станциях Windows NT в такой ситуации желательно устанавливать NetWare Client for Windows NT, причем самых последних версий, за которыми рекомендуем обращаться на сервер www.novell.com компании Novell.
Рис. 2.25 Настройки для драйвера NWSPX
Для драйвера TCP задается только величина таймаута (в секундах) при попытке установить соединение.
Рис. 2.26 Настройки для драйвера TCP
Все выполненные вами настройки портов "запоминаются" в файле NOTES.INI (см. 2.3).
Для сервера информацию о сетевых портах необходимо также вручную перенести в документ Server в адресной книге, в таблицу Network Configuration. Если этого не сделать, то сервер будет использовать только один порт и сеть Notes, занесенные в таблицу во время установки сервера. Ниже дается пример таблицы Network Configuration.
Рис. 2.27 Фрагмент документа Server - используются три порта
В этой таблице Port
- имя порта - вводится точно так, как вы его задали или выбрали при настройке порта. Notes Network - название поименованной сети Notes (см. пункт 1.4.3), доступной по этому порту. Net Address - сетевой адрес - для драйверов NETBIOS и NWSPX указывается крайняя левая компонента (CN) из полного имени сервера Notes, для драйвера TCP - IP-адрес или хост-имя этого сервера Notes (подобно 197.94.222.84 или flintstone.acme.com), для иных драйверов - смотрите во входящей в комплект поставки сервера книге Network Configuration Guide. И, наконец, Enabled - флажок, разрешающий или не разрешающий серверу использовать данный порт.
После произведенных исправлений в документе Server запустите сервер и проверьте работоспособность его портов - либо со станции администратора, запущенной на том же компьютере, используя в окне Рис. 2.18 кнопку Show status, либо командой консоли Show Port
имя_порта.
Назначение ID-файлу множественных паролей
Если вы имеете информацию, которая должна охраняться так, чтобы только несколько одновременно присутствующих пользователей, но не каждый в отдельности, смогли получить к ней доступ, вы можете зарегистрировать фиктивного пользователя и назначать его ID-файлу множественные пароли. Имя фиктивного пользователя может быть указано в ACL баз для обеспечения доступа к ним, в ID-файле фиктивного пользователя могут содержаться ключи шифрования, обеспечивая шифрование документов в базах, и, наконец, фиктивный пользователь может получать шифрованную почту. Затем вы "добавляете реальных пользователей" в этот ID-файл. Каждому из реальных пользователей назначается свой собственный пароль. В свойствах ID-файла с множественными паролями указывается количество реальных пользователей (как минимум один, но обычно два или более), которые должны собраться вместе и последовательно ввести свои пароли, чтобы стало возможным воспользоваться таким ID-файлом. Например, вы можете назначать четыре пароля для ID-файла, но требовать ввода только любых двух из четырех паролей, чтобы воспользоваться этим ID-файлом. Но возможен и "вырожденный" вариант, когда назначается несколько паролей, но для того, чтобы воспользоваться ID-файлом, необходимо ввести любой из этих паролей. Множественные пароли могут быть назначены и существующему ID-файлу. Любой пароль, назначенный ID-файлу до назначения ему нескольких паролей, после назначения нескольких паролей перестает действовать.
Такая возможность полезна, когда вы не хотите давать полномочий пользоваться ID-файлом сертификатора одному лицу, а как минимум двум одновременно присутствующим лицам.
Вы можете также использовать эту возможность, чтобы создать "безопасный" архив ID-файлов пользователей в виде присоединенных файлов в документах некоторой базы данных. Для этой базы рекомендуется применить "локальное шифрование" на основе ID-файла, для использования которого требуется несколько паролей. Тогда, чтобы обратиться к этой базе за ID-файлом пользователя, который забыл свой пароль, "испортил" или "утерял" свой ID-файл, будет необходимо присутствие нескольких уполномоченных лиц, каждый из которых знает только свой пароль.
Назначение ключей шифрования к полям
Ключи шифрования могут назначаться документу разными путями.
1. Разработчик может выбрать в окне свойств формы один или несколько ключей шифрования, используемых для шифрования документов, созданных по данной форме.
Рис. 9.28. Выбор ключей шифрования "по умолчанию" в форме
В каждом документе, созданном по этой форме, шифруемые поля будут шифроваться всеми выбранными для формы ключами.
2. Разработчик разрешает шифрование для полей, но не делает выбор ключей шифрования "по умолчанию" в форме. Создатель документа может выбрать ключи шифрования для каждого документа в отдельности в окне свойств этого документа
Рис. 9.29. Выбор ключа шифрования для документа
Если создатель документа не выберет ни одного ключа шифрования, шифрование полей выполняться не будет.
Если в форме нет шифруемых полей, а пользователь делает попытку шифровать создаваемый по форме документ, он получит следующее сообщение об ошибке "No encryptable fields found in document. Encryptable fields must be specified in form".
3. Разработчик добавляет в форму предопределенное поле с именем SecretEncryptionKeys. В это поле в формате текстового списка каким-либо способом добавляется список названий ключей шифрования.
4. Разработчик использует для назначения ключей шифрования документу возможности встроенных классов LotusScript.
По своей внутренней реализации в Notes все эти способы ничем не отличаются. В документе всегда появляется предопределенное поле SecretEncryptionKeys, содержащее текстовый список названий ключей шифрования. Вместо каждого шифруемого поля появляется поле $SealData, в котором, используя окно свойств документа на закладке Fields, удается "прочитать" настоящее название соответствующего шифруемого поля. И, наконец, появляется только одно на весь документ поле $Seal, которое и содержит в зашифрованном виде информацию из всех шифруемых полей документа. Наблюдения за размером поля $Seal в зависимости от количества использованных ключей шифрования позволяют сделать вывод, что каждый новый ключ "добавляет" в поле $Seal еще один экземпляр зашифрованных этим ключом данных. Становится понятно, почему для того, чтобы расшифровать информацию, достаточно иметь всего один ключ.
Неиерархические (простые) сертификаты
Простой сертификат удостоверяет простое имя или общую часть иерархического имени. Простые сертификаты используются только тогда, когда хотя бы одна из двух участвующих в контакте сторон - сервер или пользователь - имеют простое имя.
Очередной простой сертификат просто добавляется к набору сертификатов в ID-файле пользователя. Например, пользователь Mary Jones, работающая в Lotus Development, могла бы иметь в своем ID-файле сертификаты от сертификаторов с именами Lotus Development, Notes Domain и ADMIN_2. Каждый из этих сертификатов был получен от независимого сертификатора. Каждый из сертификатов устанавливает ассоциацию между именем Mary Jones и ее публичным ключом "за подписью" соответствующего сертификатора (см. Рис. 8.4). В результате Mary Jones получает возможность доступа к серверам, в ID-файлах которых имеется хотя бы один сертификат, выданный сертификатором с именем Lotus Development, Notes Domain или ADMIN_2.
Notes Named Network - поименованная сеть Notes
Поименованная сеть Notes (Notes Named Network, NNN) - группа серверов Notes из одного домена, использующих для "общения" между собой один и тот же сетевой протокол на постоянной основе (постоянное соединение). Серверы из одной поименованной сети Notes "могут в любое время напрямую" соединяться между собой по этому протоколу.
При присвоении имен сетей Notes должно быть учтено следующее:
· серверы Notes, использующие один и тот же сетевой протокол и расположенные физически в одной и той же локальной сети, должны иметь одно и то же имя сети Notes
· серверы Notes, использующие разные сетевые протоколы, не могут принадлежать к одним и тем же сетям Notes
· серверы Notes, использующие один и тот же сетевой протокол, но расположенные физически в разных локальных сетях, должны принадлежать к разным сетям Notes. Серверы Notes, использующие один и тот же сетевой протокол, расположенные в разных локальных сетях и устанавливающие соединение между собой по модему (X.PC) или посредством Microsoft RAS с активизацией его из Notes, должны принадлежать к разным сетям Notes. Только в случае, если между этими двумя локальными сетями существует постоянно действующий мост (реализуемый сетевыми программными или аппаратными средствами, а не средствами Notes), по соображениям нагрузки на мост возможно соотнесение серверов из этих разных локальных сетей как в одну сеть Notes, так и в разные сети Notes
· серверы Notes, использующие два или более сетевых протокола, должны принадлежать к нескольким сетям Notes, по одной на каждый протокол.
Понятие "поименованная сеть Notes" существенно используется при передаче почты между серверами. Считается, что серверы, находящиеся в одной и той же поименованной сети Notes, всегда могут напрямую соединиться друг с другом для передачи почты. Поэтому сервер, обнаружив почту, которую необходимо передать на другой сервер в той же самой поименованной сети, передает ее "автоматически" - связывается с сервером назначения по общему протоколу и передает, игнорируя при этом приоритеты писем и не используя информации из документов Connection о расписании передачи почты. Если бы понятие "поименованная сеть Notes" не использовалось, то для того, чтобы "описать" все возможные варианты передачи почты между N серверами, администратору потребовалось бы создать в адресной книге N*(N-1) документов Connection типа Network (если N=10, то N*(N-1) = 90).
Пример 3. Организация (Рис 1.10) расположена в 4-х территориально-удаленных местах. В организации один домен. Локальные сети из офисов San Francisco и San Jose соединены внешним мостом, который обеспечивает свободное прохождение пакетов NETBIOS. Остальные соединения выполняются по обычным телефонным линиям с использованием модемов. Станции Notes на рисунке не приведены. Серверы Notes поддерживают протоколы:
|
A,D,E,I,H |
NETBIOS |
|
H,E |
TCP/IP |
|
A,B,C,F,G |
Novell SPX |
Рис. 1.10 Поименованные сети Notes в территориально-распределенной организации
Какие поименованные сети Notes присутствуют?
В Атланте: "AtlantaNetBIOSLAN" (серверы I, H)
"AtlantaTCPIPLAN" (сервер H)
В Далласе: "DallasNovellSPX" (серверы G, F)
В Сан-Франциско: "SanFranciscoTCPIPLAN" (сервер E)
"SanFranciscoSanJoseNetBIOSLAN" (серверы A, D, E)
В Сан-Хосе: "SanJoseNovellSPX" (серверы A, B, C)
"SanFranciscoSanJoseNetBIOSLAN" (серверы A, D, E)
Пример 4. В домене 3 сервера: InterTrust/InterTrustCorp/SU (под OS/2), поддерживающий протоколы SPX и NetBIOS, InterWork/InterTrustCorp/SU (под Novell Netware), поддерживающий протокол SPX, и NotesSrv400/InterTrustCorp/SU (под Windows NT), поддерживающий протоколы SPX и TCP/IP. Из документов Server (рис. 1.10 - 1.12) видно, что имеются три поименованных сети Notes (смотрите информацию в столбце Notes Network таблицы Network Configuration). На Рис. 1.13 дается графическая форма представления этих поименованных сетей.
Рис. 1.10 Сервер InterTrust принадлежит двум поименованным сетям Notes
Рис. 1.11 Сервер InterWork принадлежит одной поименованной сети Notes
Рис. 1.12 Сервер NotesSrv400 принадлежит двум поименованным сетям Notes
Рис. 1.13 Такая форма представления поименованных сетей используется в Notes View
Новый домен, первый сервер, но та же организация
Установка начинается как в варианте 2.1.1, т.е. без предварительной регистрации будущего сервера. В первом окне выбирают "Первый сервер Lotus Notes в вашей организации". Но в диалоговом окне Advanced Server Setup Options (Рис. 2.7) снимают пометку с опции Create Organization Certifer ID. В результате ID нового сервера будет сертифицирован уже существующим (например, созданным при установке первого сервера в организации) ID сертификатора - в процессе установки появится диалоговое окно, в котором администратор должен будет "предоставить" ID-файл сертификатора. Все остальное совершенно аналогично варианту 2.1.1.
О двухбайтовой кодировке русских букв
Текстовая информация любого типа (в полях типа Text, RichText - кроме объектов и присоединенных файлов, Names ...) в базах данных Notes хранится в кодировке LMBCS (Lotus MultiByte Character Set). В кодировке LMBCS один символ кодируется, вообще говоря, несколькими байтами: английские буквы - одним байтом, русские - двумя, китайские, японские, корейские - тремя... В базе данных Notes в принципе допустимы тексты, в которых "рядом" могут встречаться и английские буквы, и русские буквы, и японские иероглифы.
Однако при выводе текстовой информации из баз данных на экран клиента Notes происходит ее перекодирование из кодировки LMBCS в кодировку, поддерживаемую данным компьютером (так называемую native). Наоборот, введенная с клавиатуры текстовая информация (в кодировке native) при записи в базу данных перекодируется в LMBCS. Перекодировка ведется по таблицам перекодировки, которые хранятся в каталоге программ Notes в файлах с именами l_cp*.cls. При этом не на всех платформах такое преобразование может работать взаимно однозначно - в настоящее время в кодировке native символ обычно кодируется только одним байтом. Если какой-то символ из текстового поля в базе данных по используемой на станции таблице перекодировки не может быть сопоставлен символу в кодировке native, он заменяется на символ с кодом 128 (0х7F), который обычно "будет виден" на экране на Windows-платформах как "Ђ" или "черный прямоугольник" под OS/2.
Кроме того, при построении индексов видов в базах сортировка текстовой информации выполняется с использованием таблиц сортировки, которые хранятся в каталоге программ Notes в файлах с именами coll* .cls.
Станция и сервер Notes используют в качестве "активных" таблиц перекодировки файлы l_cpdos.cls (Windows и OS/2), l_cpnlm.cls (только сервер под Novell NetWare), l_cpwin.cls (только Windows), а сортировки - collstd.cls. Для "правильной" поддержки русского языка сразу после первой фазы установки сервера или станции Notes вам необходимо "записать" в эти файлы соответствующие таблицы:
· Windows-подобные платформы:
l_cp866.cls ® l_cpdos.cls
l_cp1251.cls ® l_cpwin.cls
collcyr.cls ® collstd.cls
· OS/2:
collcyr.cls ® collstd.cls
· Novell NetWare:
l_cp866.cls ® l_cpnlm.cls
collcyr.cls ® collstd.cls
Выполнять эту операцию на Windows-платформах проще всего следующим BAT-файлом
REM Двухбайтовая кодировка русских букв
copy l_cp866.cls l_cpdos.cls
copy l_cp1251.cls l_cpwin.cls
copy collcyr.cls collstd.cls
Поместите BAT-файл в каталоге программ Notes. Файлы l_cp866.cls, l_cp1251.cls, collcyr.cls входят в состав интернациональной версии Notes. Выполнение файла перед запуском Notes обеспечит двухбайтовую кодировку русских букв и правильную сортировку по русским буквам. BAT-файл выполняется однократно - и впоследствии Notes при старте использует информацию из файлов l_cpdos.cls, l_cpwin.cls, collstd.cls. Такая же операция должна быть однократно проделана и на сервере Notes, причем желательно сразу после его установки. Обратите внимание, что после upgrade существующего сервера или станции на более новую версию Notes файлы l_cpdos.cls, l_cpwin.cls, collstd.cls заменяются одноименными файлами с дистрибутива, поэтому перед запуском "обновленных" сервера или станции необходимо снова однократно выполнить "русифицирующий" BAT-файл.
Разрабатывайте новые приложения Notes только с использованием двухбайтовой кодировки русских букв.
Признаком того, что текущая установленная на станции или сервере кодировка русских букв не соответствует кодировке текстовой информации в базе данных, является появление на экране вместо русских букв символов "Ђ" (или "черных прямоугольников" под OS/2). Однако "отображение греческих букв вместо русских" - уже проблема, связанная со шрифтами, и не имеющая никакого отношения к используемой в Notes "внутренней" кодировке.
И, наконец, практика показывает, что для правильного экспорта русскоязычных текстов из Notes через буфер обмена в Microsoft Word достаточно скопировать файл l_cp1251.cls в l_cp1252.cls.
Обновление дизайна почтовых ящиков при переходе от Notes версий х к версиям х
Для почтовых ящиков в версиях 4.х (но до версии 4.5) используется новый дизайн-шаблон StdR4Mail (MAIL4.NTF). Он предоставляет такие новые возможности, как папки для хранения входящих и отправленных писем, черновиков писем, удаляемых писем; кнопки акций для быстрого доступа к возможностям; пиктограммы в видах и формах для индикации типа письма; удобные средства для адресации писем и агенты, выполняющие команды автоматически.
Возможны два способа обновления дизайна ПЯ:
· использование администратором серверной задачи-утилиты Convert,
· замена дизайна пользователем "вручную" с последующим использованием агента.
При использовании утилиты Convert производится обновление всех, части или только некоторых ПЯ на сервере. Утилита заменяет у почтовой базы текущий дизайн-шаблон на StdR4Mail, обновляет дизайн, создает папки из категорий, подпапки из подкатегорий, добавляет категоризированные документы в соответствующие папки и подпапки, а некатегоризированные - в Inbox. Этот метод предпочтительнее как при массовом обновлении почтовых баз, так и при обновлении одиночных, но больших по размеру почтовых баз.
"Ручное" обновление более предпочтительно для разового преобразования относительно небольших по размеру ПЯ. Вначале у базы заменяют шаблон на StdR4Mail, затем обновляют дизайн, и после этого запускают агента "(Convert Categories to Folders)". Агент создает папки из категорий, подпапки из подкатегорий, добавляет категоризированные документы в соответствующие папки и подпапки, а некатегоризированные - в Inbox.
Обновление реплик почтовых ящиков на станциях пользователей происходит за счет репликаций.
Обратите внимание, что в почтовом ящике допускается не более 200 папок (это принципиальное ограничение, оно не зависит от способа обновления).
При использовании утилиты Convert последовательность действий такова.
· Убедитесь, что вы обновили все (!) станции и серверы.
· Предупредите пользователей, имеющих в своих ПЯ собственные формы, виды и макросы, чтобы они сохранили дизайн во временных базах.
· Запустите сервер Notes.
· Остановите маршрутизатор почты командой Tell Router Quit
.
· Запустите утилиту преобразования почтовых ящиков. Примеры команд приведены ниже, а подробное описание синтаксиса можно найти базе Notes Migration Guide.
· По окончании работы утилиты вновь запустите маршрутизатор почты командой Load Router.
· Предупредите пользователей, что они могут скопировать свои собственные элементы дизайна из временных баз в обновленные почтовые ящики, однако их элементы дизайна не должны иметь имена, которые уже используются в обновленном дизайне, иначе почта не будет правильно функционировать.
Пример 1. Если база mail\user.nsf наследует дизайн с шаблона StdNotesMail, то шаблон заменяется на StdR4Mail (MAIL4.NTF) и выполняется обновление.
load convert mail\user.nsf stdnotesmail mail4.ntf
Пример 2. Для тех баз в каталоге \mail, которые наследуют дизайн с шаблона StdNotesMail, выполняется обновление.
load convert mail\*.nsf stdnotesmail mail4.ntf
> load convert mail\*.nsf stdnotesmail mail4.ntf
03.09.96 13:23:58 Mail Conversion Utility starting
03.09.96 13:24:00 Mail Convert: Started replacing design template 'stdnotesmail' with 'StdR4Mail' in 'mail\ADANILIN.NSF'
03.09.96 13:24:04 Adding '-' to database 'Alexandr V. Danilin' from template 'Mail (R4)'
03.09.96 13:24:05 Adding 'Archive Profile' to database 'Alexandr V. Danilin' from template 'Mail (R4)'
03.09.96 13:24:06 Adding 'Bouncy Earth' to database 'Alexandr V. Danilin' from template 'Mail (R4)'
… и так далее на 3 листа, какой-то элемент дизайна добавляет, какой-то заменяет.
03.09.96 13:24:25 Adding '($All)' to database 'Alexandr V. Danilin' from template 'Mail (R4)'
03.09.96 13:24:40 Deleting ' All by Person' from database 'Alexandr V. Danilin'
03.09.96 13:24:40 Deleting 'All by Size' from database 'Alexandr V. Danilin'
03.09.96 13:24:40 Deleting 'Attachments' from database 'Alexandr V. Danilin'
03.09.96 13:24:41 Deleting 'Drafts by Category' from database 'Alexandr V. Danilin'
03.09.96 13:24:41 Deleting 'Memo to Manager' from database 'Alexandr V. Danilin'
03.09.96 13:24:42 Deleting 'Received by Category' from database 'Alexandr V. Danilin'
03.09.96 13:24:42 Deleting 'Sent by Category' from database 'Alexandr V. Danilin'
03.09.96 13:24:42 Deleting 'To Do' from database 'Alexandr V. Danilin'
03.09.96 13:24:43 Mail Convert: Finished replacing design template in 'mail\ADANILIN.NSF'
03.09.96 13:24:45 Mail Convert: Started converting categories to folders in 'mail\ADANILIN.NSF'
03.09.96 13:24:45 Mail Convert: Building a categorized view
03.09.96 13:24:46 Mail Convert: Checking for the maximum number of categories
03.09.96 13:24:51 Mail Convert: Creating & populating folder 'Lotus'
03.09.96 13:24:58 Mail Convert: Opening & repopulating existing folder '$Inbox'
03.09.96 13:25:02 Mail Convert: Finished converting categories to folders in 'mail\ADANILIN.NSF'
03.09.96 13:25:05 Mail Convert: Started replacing design template 'stdnotesmail' with 'StdR4Mail' in 'mail\DVOLKOV.NSF'
. . .
03.09.96 13:27:02 Mail Convert: Finished converting categories to folders in ' mail\DVOLKOV.NSF '
03.09.96 13:31:34 Mail Convert: Skipping database mail\ykornvei.nsf, its design template 'StdR4Mail' does not match 'stdnotesmail'
03.09.96 13:31:34 Mail Conversion Utility shutdown
Пример 3. Для всех баз в каталоге \MAIL и рекурсивно всех его подкаталогах выполняется обновление.
load convert -r mail\*.nsf
Пример 4. В файле C:\TEMP\MAILLIST.TXT создается список всех почтовых баз на сервере.
load convert -l c:\temp\maillist.txt
Пример 5. Просматриваются все базы, перечисленные в файле c:\temp\maillist.txt, полученном в предыдущем примере, и в тех из них, которые наследуют дизайн с шаблона, первые три буквы названия которого STD (например, StdNotesMail) , шаблон заменяется на StdR4Mail (MAIL4.NTF) и выполняется обновление.
load convert -f c:\temp\maillist.txt std* mail4.ntf
При обновлении "вручную" последовательность действий такова.
· Запустите станцию Notes.
· Скопируйте модифицированные вами формы, виды и макросы во временную базу.
· Выберите пиктограмму базы и из меню File - Database - Replace Design.
· Выберите дизайн-шаблон Mail (R4).
· Нажмите кнопку Replace.
· Выберите из меню View - Go To Agents, затем агента с именем "(Convert Categories to Folders)", и далее из меню Actions - Run.
· Добавьте в базу из временной базы собственные элементы дизайна, но не заменяя при этом существующих.
Переход от Notes версий 4.х к версиям 4.5 тоже влечет изменение дизайна почтовых ящиков. Основные изменения здесь связаны с появлением системы календарного планирования и учета свободного времени. Для поддержки этих возможностей в язык LotusScript пришлось добавить несколько новых классов. Естественно, что новый дизайн-шаблон почтового ящика StdR45Mail (MAIL45.NTF) использует методы этих новых классов. Так же естественно, что станция Notes версий ниже 4.5 интерпретировать методы этих новых классов не может, "выдавая" при попытке открыть на ней почтовый ящик дизайна StdR45Mail многочисленные предупреждения об ошибках.
Однако такой "остроты" проблемы, как при переходе от версий 3.х к версиям 4.х, здесь уже нет. Сервер Notes версии 4.5 с одинаковым успехом поддерживает как почтовые ящики дизайна StdR45Mail, так и StdR4Mail. Замена дизайна осуществляется просто заменой используемого почтовым ящиком дизайн-шаблона. Если пользователь желает продолжать работать на станции версии 4.11а (обычно, потому что она русифицирована), обеспечьте, чтобы его почтовый ящик наследовал дизайн с шаблона StdR4Mail. При регистрации нового пользователя для него создается почтовый ящик дизайна StdR45Mail. Если этот пользователь будет работать на станции версии 4.11а, сразу после регистрации измените дизайн его ПЯ на StdR4Mail.
Обычные модемные соединения по коммутируемым линиям
Здесь мы предполагаем, что на вызывающем компьютере (станции или сервере) и на вызываемом сервере модемы подключены непосредственно к COM-портам, т.е. изображенные на Рис. 5.1 управляемые устройства УУ1 и УУ2 и скрипты "приобретения" и соединения отсутствуют.
Рассмотрим действия, которые необходимо выполнить по настройке станции или сервера для работы с использованием модема, а так же некоторые аспекты такой работы со станции.
Установка COM-порта
Выбрав в меню File - Tools - User Preferences..., получаем диалоговое окно, в котором выбираем закладку Ports, а на ней COM-порт, к которому подключен модем.
Рис. 5.2 Настройка COM-порта начинается из окна User Preferens на закладке Ports
При нажатии кнопки COMx Options… получаем окно Additional Setup.
Рис. 5.3 Окно Additional Setup при использовании драйвера XPC
В нем выбираем тип используемого модема (из списка Modem Type:). Допустимые типы используемых модемов определяются наличием в каталоге NOTES\DATA\MODEMS файлов управления модемами (расширение *.MDM). Если в списке нет используемого вами модема, рекомендуем сначала попробовать подобрать "наиболее близко подходящий" к нему из числа имеющихся в списке. Если это не удается, выберите .Auto Configure (for unlisted modems, only), что соответствует файлу AUTO.MDM. Используя этот файл, драйвер XPC в процессе автоподстройки к модему "перебирает" несколько стандартных файлов управления модемами. Однако по нашему опыту, это не всегда "спасает". Даже если ваш модем и будет работать с файлом AUTO.MDM, скорее всего не все возможности вашего модема при этом будут задействованы, а в результате не будет получено хороших, а иногда даже и удовлетворительных результатов.
В поле Maximum port speed:
выбирается максимальная скорость, обеспечиваемая компьютером по COM-порту. Она должна превосходить скорость, на которой будет осуществляться соединение модемов, и должна быть согласована с установками для порта на уровне операционной системы (для Windows-платформ пиктограмма Ports в Control Panel). В поле Speaker volume: выбирается необходимый уровень громкости "звукового сопровождения" модема при установлении соединения, в поле Dial mode: - применяемый метод набора номера ("пульсовый" или "тоновый"). Протоколирование команд, посылаемых на модем, а так же ответов модема на них в базе LOG.NSF (опция Log modem I/O:) может быть полезна при отладке. Выбирать опцию Log script I/O:
в рассматриваемой нами ситуации бессмысленно - ведь никакие скрипты не используются. Опция Hardware flow control: обычно выбирается для современных модемов, но должна быть согласована с возможностями модема и установками для порта на уровне операционной системы (для Windows-платформ пиктограмма Ports в Control Panel). Значение в поле Dial timeout: определяет, сколько секунд ваш модем при установлении соединения после набора номера будет ожидать ответа вызываемого модема. Значение в поле Hang up if idle for: определяет количество минут "бездействия" при установленном соединении, по истечении которого принимается решение разорвать соединение. Администратор обычно "управляет" этим значением на сервере, чтобы последний автоматически разрывал соединения со станциями, пользователи которых "держат линию", не выполняя при этом полезной работы - обмена данными. Наконец, число в поле Port number: должно совпадать с номером используемого COM-порта.
Кнопка Modem File…
"открывает" окно редактора используемого файла управления модемом. Можно редактировать этот файл и любым текстовым редактором. В большинстве случаев требуются лишь незначительные корректировки строк инициализации модема - они даются в строках файла с префиксом "SETUP=". Команды и возможности вашего модема можно найти только в руководстве к модему. Чтобы осознанно редактировать файл управления модемом или создавать собственные файлы, вы должны знать используемый при этом язык. Для получения информации по языку файлов управления модемами просмотрите файл TEMPLATE.MDM.
Кнопка Acquire Script... "открывает" окно, в котором выбирается скрипт "приобретения", работающий перед тем, как начнутся посылки команд на модем. В рассматриваемой нами ситуации ("обычные модемные соединения") скрипт "приобретения" не используется, и вам лишь остается обратить внимание, выбрано ли в этом окне -NONE-. Кнопка Edit... станет активна только после того, как вы выберите существующий скрипт "приобретения", и "откроет" в окне редактора файл этого скрипта.
Рис. 5.4 Для обычных модемных соединений скрипт "приобретения" не используется
Документ Location в адресной книге станции
В персональной адресной книге создаем новый или модифицируем существующий документ Location (см. Рис. 5.5).
В поле Location type: выбираем Dialup Modem, в списке используемых в этом местоположении портов (Ports to use:) - используемый COM-порт. Задаем полные имена почтового сервера, сервера-посредника по умолчанию и InterNotes-сервера.
Обратите также внимание на префикс телефонного номера в поле с меткой Prefix for outside line:
(например: "9," для выхода в город с местной телефонной станции). В этом местоположении он будет автоматически добавляться к номеру телефона из документа Connection.
Если в поле Schedule: выбрано Enabled, то временные интервалы (Replicate daily between:), интервал повторения (Repeat every:) и дни (Days of week:) определяют моменты времени, когда станция должна автоматически связываться с сервером для выполнения фоновой репликации и передачи почты между станцией и сервером. Чтобы запретить автоматический вызов сервера (работу по расписанию), выберите Disabled в поле Schedule:.
В поле с меткой Mail file location: по финансовым соображениям обычно выбирают режим Local. Режим касается только способа передачи почты на сервер, но не вызова сервера с использованием модема. Проверьте в поле с меткой Mail file: путь и имя файла для используемого почтового ящика. Почтовые ящики пользователя на сервере и станции должны быть репликами (см. Рис. 5.6). Входящие письма пользователю сервер из своего MAIL.BOX помещает в почтовый ящик пользователя на сервере. Из него письма поступают в почтовый ящик пользователя на станции за счет репликаций. Исходящие письма пользователя, станция которого находится в режиме Local, создаются в почтовом ящике на станции и при отправке заносятся в MAIL.BOX на станции. Из MAIL.BOX на станции они в некоторые моменты времени переносятся в MAIL.BOX на сервере. Дальнейшей их доставкой занимаются уже серверы. Сохраненные пользователем копии отправленных писем из его почтового ящика на станции реплицируются также и в его почтовый ящик на сервере.
Рис. 5.5 Пример документа Location (версия 4.11a)
Рис. 5.6 Схема режима Local
Документ Connection
В локальной адресной книге инициирующего соединение сервера или станции создаем документ Connection. Основное в этом документе - номер телефона. В рассматриваемой нами ситуации ("обычные модемные соединения") скрипт соединения не используется, поэтому поля Login script filename: и Login script arguments: должны быть пусты.
Рис. 5.7 Пример документа Connection (версия 4.11а, персональная адресная книга)
Вызов сервера
Сервер вызывает другой сервер в соответствии с расписанием, указанным в документе Connection. Станция, в текущем документе Location которой в поле Schedule: выбрано Enabled, так же вызывает сервер в соответствии с заданным в этом документе расписанием.
Пользователь станции может в любое время "вручную" инициировать вызов сервера. Для этого, убедившись, что станция находится в соответствующем местоположении, пользователь выбирает в меню File - Mobile - Call server…
и в появившемся окне нажимает кнопку Auto Dial. Если все хорошо, должен произойти набор номера и, через несколько минут, соединение с сервером. Обратите внимание, что список серверов в окне Call Server станция "строит" по документам Connection типа Dialup Modem из локальной адресной книги, но с учетом текущего местоположения. Если список пуст, в локальной адресной книге нет ни одного документа Connection типа Dialup Modem, "применимого" в текущем местоположении.
Рис. 5.8 Окно вызова сервера
Инициировать вызов сервера можно и другими способами, например, кнопкой
Для принудительного завершения сеанса выбирают в меню File - Mobile - Hang Up ("повесить трубку") или нажимают кнопку
Работа со станции по модемному соединению
По модемному соединению возможны два стиля работы:
· интерактивная работа - работа во время активности соединения с сервером, точно так же, как по локальной сети, только медленнее, "со скоростью канала". Однако по финансовым соображениям этот стиль обычно нецелесообразен, поскольку пользователь не может "равномерно загрузить" открытый канал
· локальная работа с периодическим вызовом сервера - работа с локальными репликами имеющихся на сервере баз данных, подготовка почты в локальном почтовом ящике и вызов сервера только для выполнения репликаций с репликами баз на сервере и отправки почты. Этот стиль работы позволяет полностью загрузить открытый канал между станцией и сервером, и по финансовым соображениям обычно более целесообразен.
Наиболее удобно управлять процессом репликаций между станцией и сервером с закладки Replicator.
Рис. 5.9 Внешний вид закладки Replicator
Содержимое закладки "привязано" к местоположению, в котором находится станция. Когда вы создаете локальную реплику базы с сервера, ее пиктограмма автоматически добавляется на закладку Replicator. Если все-таки вам необходимо "вручную" добавить пиктограмму базы на закладку Replicator, просто перетащите ее туда мышью. Для удаления пиктограммы базы с закладки Replicator
выберите ее и нажмите клавишу Delele.
Для каждой имеющейся на закладке базы можно выбрать необходимые репликационные установки (правой кнопкой мыши).
Рис. 5.10 Как реплицируется локальная база
Можно реплицировать как "все" базы, так и только предварительно выбранные на закладке (отмечаются "галочкой"). Кнопка Send & Reseive Mail служит для пересылки ваших исходящих писем из локальной базы MAIL.BOX в базу MAIL.BOX на сервере и приема входящих писем из реплики почтового ящика на сервере в локальный почтовый ящик.
В режиме Local в репликационных установках локального почтового ящика рекомендуется выбрать:
· не реплицировать выполненные в локальном почтовом ящике изменения и удаления в почтовый ящик на сервере
· автоматически удалять документы, которые не изменились за последние XXX дней.
Для репликаций и передачи почты по расписанию следует предварительно "разрешить" работу по расписанию в документе Location. Это же можно сделать и непосредственно с закладки Replicator, "отметив галочкой" первый элемент (Start replication at:) на закладке.
Замечания
· Перед завершением работы станции Notes, функционирующей в режиме Local, появляется диалоговое окно с предложением обменяться почтой с сервером, если локальный MAIL.BOX не пуст. При положительном ответе происходит автоматическое соединение и обмен почтой.
· Документы в Notes версий 3.х передаются и реплицируются целиком, даже если в них изменилось только одно поле. В Notes версий 4.х репликации и сохранение документа выполняются на уровне полей - передаются только изменившиеся поля.
· При интерактивной работе с сервером виды передаются частями - приблизительно по 2 "экранных страницы". Хорошее впечатление оставляет выполнение запроса полнотекстового поиска к базе на сервере, так как вы получаете быстрый ответ.
· По опыту автора хороший модем (мы использовали модемы фирм US Robotics или ZyXEL) достаточно стабильно обеспечивает на обычных городских телефонных линиях скорость 19600 bps и выше. Интерактивная работа на такой скорости вполне приемлема. При скорости ниже 9600 bps
интерактивная работа происходит "мучительно медленно". Однако качество модема еще не решает все проблемы - очень многое зависит от используемых телефонных линий и автоматических телефонных станций.
Обзор баз данных, используемых администратором в своей работе
Администратор в своей повседневной работе наиболее часто использует базы данных:
· NAMES.NSF - Public Address Book (PAB) - общая адресная книга,
· LOG.NSF - Notes Log - протокол работы сервера,
· CATALOG.NSF - Database Catalog - каталог баз данных на сервере,
· CERTLOG.NSF - Certification Log - протокол сертификаций.
Это далеко не полный список системных баз, но цель данной главы - подробное рассмотрение перечисленных баз данных, и прежде всего общей адресной книги.
Обзор обеспечения безопасности сервера Notes
Сервер или станция Notes (клиент A) обращается к серверу Notes (B), например, устанавливает соединение с сервером, открывает базу на сервере и работает с документами, выполняет репликацию или передачу почты. При этом клиенту, чтобы получить доступ к информации на сервере, образно говоря, приходится последовательно "пройти через пять следующих дверей и не споткнуться на дополнительных возможностях".
Очередной сервер в домене
Процесс начинается с регистрации будущего очередного сервера. Администратор первого сервера домена со своей рабочей станции выбирает в меню File - Tools - Server Administration…, и далее в окне Administration выбирает в меню кнопки Server пункт Register Server…
Рис. 2.10 Большинство действий по администрированию выполняются из окна Administration…
Рис. 2.11 Первое диалоговое окно при регистрации очередного сервера в домене
В диалоговом окне Register Servers кнопкой Registration Server... администратор выбирает любой из уже функционирующих серверов домена: в общую адресную книгу этого сервера будет добавлен документ Server на создаваемый сервер. Регистрационный сервер - это сервер, в адресную книгу которого в ходе регистрации заносится информация о регистрируемом сервере, пользователе... Впоследствии при репликациях эта информация попадет и в адресные книги других серверов домена.
Кнопкой Certifer ID... администратор выбирает ID-файл сертификатора, которым должен быть сертифицирован ID будущего сервера. От этого выбора зависят старшие компоненты в имени нового сервера.
В поле Certificate expiration date можно изменить "дату истечения" сертификата - дату, до которой будет иметь силу сертификат, добавляемый в создаваемый ID сервера.
После этого нажимают кнопку Continue… и получают второе окно Register Servers, в котором две закладки.
Рис. 2.12 Второе диалоговое окно при регистрации очередного сервера в домене, закладка Basics
На закладке Basics
задают:
· имя создаваемого сервера (только имя сервера, без старших компонент, включающих названия оргединиц (OU), организации (O) и страны (С), поскольку эти компоненты будут "взяты" из уже выбранного ID-файла сертификатора и автоматически добавлены к введенному вами имени)
· имя домена, в состав которого будет входить сервер
· если необходимо, пароль для ID-файла создаваемого сервера. Если же пароль не нужен, очистите поля Password и Minimum password length.
· полное имя администратора создаваемого сервера.
На закладке Other
определяется (см. диалоговое окно на Рис. 2.13) имя поименованной сети Notes и "место", в которое следует поместить ID создаваемого сервера (в файл или/и в адресную книгу). Учтите, что если вы помещаете ID создаваемого сервера в адресную книгу, вам все равно придется защитить его паролем. Если же ID создаваемого сервера помещается только в файл, то очисткой полей Password и Minimum password length вы сможете создать "беспарольный" ID сервера.
В поле Local Administrator может быть указан список полных имен лиц, которым следует предоставить возможность редактировать документ Server создаваемого сервера, но не все другие документы из общей адресной книги. Этот список будет помещен в поле типа Authors создаваемого в ходе регистрации документа Server. Впоследствии эти лица смогут редактировать данный документ, имея к общей адресной книге лишь доступ автора. Однако удобнее добавить список этих лиц непосредственно в поле Administrators секции Administration в документе Server позже, после регистрации и установки сервера.
После этого нажатием кнопки Register администратор "запускает" процесс регистрации. В ходе процесса регистрации Notes:
· создает ID нового сервера и сертифицирует его выбранным ID сертификатора
· создает документ Server для нового сервера в общей адресной книге
· добавляет сервер в группу LocalDomainServers в общей адресной книге
Рис. 2.13 Второе диалоговое окно при регистрации очередного сервера в домене, закладка Other - дополнительные параметры
· добавляет имя администратора в соответствующее поле в документе Server нового сервера
· присоединяет ID сервера в документ Server в адресной книге или (и) записывает его в файл
· создает документ формы Certified User для сервера в базе данных "Протокол Сертификаций"
(Certification
Log, CERTLOG.NSF), если эта база была создана на регистрационном сервере. Не удивляйтесь названию формы Certified User - "сертифицированный пользователь". Во-первых, ID пользователя и сервера практически ничем не отличаются, а во-вторых, в базе Certification
Log только протоколируются все акты сертификаций, без различия, для "кого" (пользователя, сервера и др.) они выполнялись.
После регистрации появляется возможность внести некоторые изменения непосредственно в созданный документ Server. Но во избежание возможных проблем при последующей установке сервера рекомендуем сделать это уже после установки.
Только после этого на компьютере, который должен стать новым сервером Notes, начинают собственно процесс установки. После выполняемого программой INSTALL.EXE копирования информации на локальный диск сервера, выбора соответствующих стране и используемому языку таблиц перекодировки и сортировки и запуска программы станции в диалоговом окне Notes Server Setup
(Рис. 2.5) выбирают An addditional Lotus Notes server in your organization ("Дополнительный сервер в вашей организации"). В следующем окне (Рис. 2.14) необходимо указать имя нового сервера (такое же, как было указано при его регистрации), а также имя регистрационного сервера и способ связи с ним. Если ID устанавливаемого сервера при регистрации был записан в файл, нужно отметить опцию New server's ID supplied in a file. Если ID администратора сервера имеется в виде файла, а не присоединен к документу Person в общей адресной книге, в окне на Рис. 2.15 необходимо отметить опцию Administrator's ID is supplied in a file. Остальное аналогично варианту установки 2.1.1.
Рис. 2.14 Установка очередного сервера в домене
Рис. 2.15 Дополнительные параметры при установке очередного сервера в домене
В процессе инсталляции Notes:
· открывает сетевой или коммуникационный порт нового сервера
· подключается к регистрационному серверу
· извлекает ID устанавливаемого сервера из адресной книги регистрационного сервера или из файла. Обратите внимание, что если ID-файл извлекается из адресной книги, он вначале копируется в каталог данных на устанавливаемом сервере, а затем автоматически удаляется из документа Server
· реплицирует к себе адресную книгу с регистрационного сервера
· создает LOG.NSF
· добавляет адресную книгу и LOG.NSF в рабочее пространство (если инсталлируемый сервер одновременно рабочая станция администратора).
Отправка шифрованной почты в другой домен
Зашифрованное сообщение Notes может быть отправлено в другой домен. Чтобы шифрование было возможным, для получателя должен иметься документ Person в одной из адресных книг, которые "просматривает" Mailer - часть программного обеспечения станции, отвечающая за отправку почты. Это может быть личная или общая адресная книга. Кроме того, документ Person должен содержать публичный ключ получателя, если его имя простое (неиерархическое), или сертифицированный публичный ключ, если его имя иерархическое. Обычно получатель предварительно "присылает" будущему отправителю свой публичный ключ "открытым текстом", а тот создает в своей адресной книге документ Person на будущего получателя и вставляет в соответствующее поле публичный ключ.
Отсоединение ПЯ от СПЯ
Если вы хотите удалить СПЯ, вы должны сначала "отсоединить" от него все ПЯ. Эта операция для каждого сообщения из ПЯ, которое содержит ссылку на тело сообщения в СПЯ, восстанавливает в этом ПЯ тело сообщения. Очевидно, при такой операции может быть "израсходовано" значительное количество дискового пространства.
Для отсоединения всех ПЯ от СПЯ используют команду консоли:
Load Object Unlink SHARED.NSF ,
где SHARED.NSF - имя СПЯ.
Если же вы хотите удалить только некоторые ПЯ, которые были связаны с СПЯ, то следует сначала отсоединить эти ПЯ от всех возможных СПЯ, с которыми они могли быть связаны. Если не сделать этого перед удалением ПЯ, в СПЯ могут остаться "тела сообщений", на которые не ссылается ни один из ПЯ, и они будут продолжать храниться в СПЯ "вечно", поскольку функция Collect не может их удалить, ибо счетчик ссылок не равен нулю.
Для отсоединения только одного ПЯ от СПЯ используется команда консоли:
Load Object Unlink USERMAIL.NSF ,
где USERMAIL.NSF - имя отсоединяемого ПЯ.
Переменные из файла NOTES.INI, относящиеся к почте
· Log_MailRouting задает подробность протоколирования почтовых событий в Notes Log.
· MailCompactDisabled разрешает/запрещает уплотнение MAIL.BOX на сервере.
· MailDisablePriority значение 1 предписывает Mail Router игнорировать установленный отправителем приоритет сообщения и доставлять сообщение как сообщение нормального приоритета.
· MailDynamicCostReset задает интервал в минутах, по истечении которого сервер восстанавливает в таблицах маршрутизации указанные в общей адресной книге стоимости соединений. Значение по умолчанию - 60 минут.
· MailEncryptIncoming требует шифровать всю почту, получаемую пользователями, почтовые ящики которых находятся на этом сервере.
· MailLowPriorityTime=<time range> Отрезок времени для передачи почты низкого приоритета. По умолчанию (когда в файле NOTES.INI нет этой переменной) Router передает почту низкого приоритета между полуночью и 6:00 часами утра. Для изменения этого отрезка времени установите в качестве значения переменной MailLowPriorityTime желаемый отрезок, используя в нем время в 24-х часовом формате. Пример - с 9 до 11 вечера: MailLowPriorityTime=21:00-23:00 . Обратите внимание, что должен быть указан именно отрезок времени. Почта низкого приоритета не будет передаваться, если указано конкретное время, например 4:00.
· MailMaxThreads задает максимальное число параллельно работающих подпроцессов (threads), которые Mail Router может создавать для доставки почты. Подпроцесс реализует акт передачи почты: устанавливает соединение с сервером назначения, открывает его MAIL.BOX, "переписывает" в него сообщение и удаляет оригинал в "своем" MAIL.BOX. По умолчанию один подпроцесс на порт.
· MailServer на станции задает имя сервера, на котором находится почтовый ящик пользователя.
· MailSystem задает почтовую систему, которую пользователь выбрал при установке станции.
· MailTimeout задает число дней, по истечении которых сервер возвращает недоставленную почту отправителю. По умолчанию 1 день.
· MailTimeoutMinutes задает число минут, по истечении которых сервер возвращает недоставленную почту отправителю. Используется вместо MailTimeout, когда необходим более короткий интервал.
· ReportUseMail разрешает серверной задаче Report использовать Mail Router для отправки своей статистики на другой сервер в том же домене.
· ServerTasks
дает список задач, запускаемых при старте сервера и работающих до его останова. Обычно содержит и задачу Router.
· SecureMail для станции требует, чтобы вся отправляемая этой станцией почта была подписана и зашифрована.
· Shared_Mail
указывает, использует ли, и как задача Mail Router СПЯ на сервере.
Переменные NOTES.INI, которые влияют на репликации
· Allow_Access Список пользователей, групп и серверов, имеющих доступ на этот сервер.
· Create_Replica_Access Список пользователей и групп, которые могут создавать реплики на этом сервере.
· Deny_Access Список пользователей, групп и серверов, не имеющих доступа на этот сервер.
· Log_Replication Значение 1 требует протоколировать начало и конец репликационной сессии в протоколе и на консоли сервера, значение 0 - не протоколировать.
· Repl_Error_Tolerance задает количество ошибок одного и того же типа, которое может произойти при репликации двух баз, прежде чем сервер закроет репликацию.
· ReplicationTimeLimit Задает максимальное время (в минутах), которое может занимать репликация между данным сервером и другими серверами.
· Replicators Указывает количество задач Replicator, которые должны одновременно выполняться на сервере.
Переменные ServerPushReplication и ServerNoReplRequests
ServerPushReplication = 1
Сервер с ServerPushReplication=1 будет выполнять все репликации по расписанию, начатые с этого сервера, по схеме Pull-Push. Другие серверы, которые начинают репликацию с этим сервером по схеме Pull-Pull, будут принимать изменения от этого сервера (первая фаза в схеме Pull-Pull), но этот сервер уже не станет принимать запросы на прием изменений от них (вторая фаза в схеме Pull-Pull).
Неприятность в том, что такой сервер "заставляет" все остальные серверы вести себя подобным ему образом - иначе изменения с других серверов по их инициативе не поступят на сервер с ServerPushReplication=1.
ServerNoReplRequests=1
Сервер с ServerNoReplRequests=1 отказывается от запроса на репликацию с другого сервера и вынуждает запрашивающий сервер выполнять репликацию типа Pull-Push.
Пусть сервер A имеет ServerNoReplRequests=1 в файле NOTES.INI, а сервер B не имеет. Будет происходить следующее.
· Когда сервер B, инициировавший репликацию по схеме Pull-Pull, принял изменения с сервера A, он будет выдавать запрос для A, чтобы теперь сервер A принял изменения с сервера B. Это "нормальное поведение" - вторая фаза в схеме Pull-Pull.
· Однако сервер A будет отказываться от этого запроса из-за наличия в его файле NOTES.INI переменной ServerNoReplRequests=1, и будет отвечать серверу B, что "тот сам должен послать изменения на сервер A, если хочет, чтобы репликация завершилась успешно".
· Серверу B "остается только согласиться с таким ответом" сервера А и самому "затолкнуть" (Push) на него эти изменения.
Вы также можете задать обе переменные на одном сервере. Результатом будет то, что этот сервер будет выполнять все инициированные им репликации по схеме Pull-Push, и отказываться от всех запросов на репликацию от других серверов по схеме Pull-Pull, вынуждая другие серверы выполнять репликацию по схеме Pull-Push, "даже если они этого не хотят".
Перенос ПЯ, использующего СПЯ, на другой сервер
Перенос осуществляется следующим образом:
· отсоединить ПЯ от СПЯ (Unlink);
· создать реплику ПЯ на другом сервере (File - Replication - New Replica при условии, что ПЯ доступен локально);
· удалить ПЯ (File - Database - Delete при условии, что ПЯ доступен локально);
· изменить в общей адресной книге в документе Person пользователя почтовый сервер;
· сообщить пользователю, чтобы он исправил имя почтового сервера в своей персональной адресной книге.
Person - пользователь
Документы формы Person служат для редактирования информации о пользователях в домене. Документ этой формы создается автоматически при регистрации пользователя и уже рассматривался в 2.2.1.
Первый сервер первого домена в организации
Вы выбираете "Первый сервер Lotus Notes в вашей организации" в окне на Рис. 2.5, нажимаете OK и получаете диалоговое окно First Server Setup.
Рис. 2.6 Диалоговое окно First Server Setup
В нем задаете:
· Server Name
- имя сервера
· Organization Name
- название организации (оно же станет и названием домена, если не внести никаких изменений в дополнительном диалоговом окне, "вызываемом" кнопкой Advanced Options...)
· Last Name, First Name and Middle Initial of the Notes Administrator - фамилия, имя и буква отчества (необязательно) администратора, ответственного за сервер и домен
· Password
- пароль для ID-файла администратора, который также будет использован как пароль ID-файла сертификатора организации CERT.ID
· Network Type
- тип сети - один из сетевых протоколов, который будет использоваться для доступа к серверу. Поддержка этого сетевого протокола на уровне операционной системы должна быть установлена предварительно, до установки сервера Notes.
· Serial Port
- последовательный порт (COM1, COM2,...), используемый одним из модемов, подключенных к серверу
· Modem Type -
тип модема, подключенного к выбранному последовательному порту (если модемы подключены к серверу)
· Server is also administrators personal workstation - сервер также будет использоваться и как рабочая станция для администратора.
Весьма желательно сразу и надолго решить вопрос об именах сервера, организации и домена. Их изменение в дальнейшем возможно, но относительно трудоемко. Имеются определенные правила и принципы для выбора имен.
Имена серверов должны быть уникальны в пределах организации и могут состоять из одного или более слов (до 79 символов) из любых символов, кроме "(", ")",
"@", "/",
"\", "=",
"+" . Символ "&" , хотя его можно использовать в имени сервера, может причинять серьезные проблемы на некоторых платформах и в некоторых сетях. Символ "пробел" также не рекомендуется в имени сервера - иначе вам придется в командах консоли сервера вводить имена серверов "в кавычках". Имя организации должно быть не короче 3 символов и не длиннее 64 символов. Имя домена - до 32 символов, причем пробелы и символ "точка" использовать не рекомендуется. Имена поименованных сетей Notes должны быть не длиннее 32 символов. Наконец, при использовании протокола NetBIOS первые 15 символов имен серверов должны быть уникальны в пределах поименованной сети, при использовании AppleTalk - первые 32 символа, SPX - первые 47 символов.
В "вызываемом" по кнопке Advanced Options... диалоговом окне Advanced Server Setup Options (см. Рис. 2.7) можно задать имя домена (по умолчанию оно совпадает с названием организации), название поименованной сети Notes (по умолчанию Network1), необязательный код страны, заказать регистрацию событий (репликации, сеансы пользователей, протокол работы модема) в базе-протоколе LOG.NSF, изменить минимальную длину пароля. Важно не убирать выставляемый по умолчанию выбор опций Create Organization Certifer ID, Create Server ID, Create Administrator ID.
Рис. 2.7 Диалоговое окно Advanced Server Setup Options
После этого останется только выбрать в последнем диалоговом окне часовой пояс (например, ZE3
- 3 часа к востоку от Гринвича). Это важно для правильного выполнения репликаций баз между серверами, расположенными в разных часовых поясах.
Что происходит при установке первого сервера в первом домене?
В каталоге данных Notes создаются базы данных:
· NAMES.NSF - общая адресная книга
· LOG.NSF - протокол работы сервера Notes
Создаются файлы:
· CERT.ID - ID- файл для сертификатора организации; сертификатор организации будет использовать этот файл для сертификации ID пользователей, ID дополнительных серверов и, если необходимо, для создания ID сертификаторов оргединиц
· SERVER.ID - ID-файл этого сервера, причем он автоматически сертифицируется, т.е. в него автоматически добавляется сертификат, создаваемый с использованием CERT.ID
· USER.ID - пользовательский ID-файл для администратора, причем он автоматически сертифицируется с использованием CERT.ID.
Файлы SERVER.ID и CERT.ID помещаются в каталог данных сервера. Если сервер не является одновременно рабочей станцией администратора, USER.ID администратора присоединяется к документу Person, созданному для администратора в общей адресной книге. Если же сервер одновременно является рабочей станцией администратора, его USER.ID помещается в каталог данных сервера. Введенный вами пароль устанавливается для файлов CERT.ID и USER.ID - при последующих обращениях к этим файлам Notes будет требовать ввода данного пароля.
В общей адресной книге создается документ Server, в него заносится имя сервера, домена, поименованной сети и администратора сервера. Имя сервера добавляется в создаваемый документ Group с именем LocalDomainServers ("серверы этого домена") в общей адресной книге. Имя администратора и имя сервера также добавляются в список управления доступом (ACL) общей адресной книги с доступом менеджера. Кроме того, в адресной книге создается документ Certifier для сертификатора организации (владельца CERT.ID).
Наконец, в каталоге данных создается подкаталог почты mail\ и в нем база данных "Почтовый ящик" для администратора.
Рис. 2.8 Вид рабочего пространства по завершении установки сервера
Если по каким-то причинам вторая часть установки не удалась, ее можно повторить, не выполняя заново первую часть установки - копирование файлов. Для этого вы должны удалить из файла NOTES.INI (обычно он находится в каталоге Windows) все строки, расположенные после приведенных здесь 4-х строк
[Notes]
KitType=2
Directory=f:\notes45\data
FileDlgDirectory=f:\LOTUSTMP.000
и удалить из каталога данных Notes файлы DESKTOP.DSK, NAMES.NSF, ADMIN4.NSF, LOG.NSF, CERT.ID, SERVER.ID, USER.ID и, если имеются, MAIL.BOX и CATALOG.NSF.
Если при попытке начать вторую часть установки вы не получаете диалогового окна Notes Server Setup, "найдите" оставшийся от предшествующих установок сервера или станции файл NOTES.INI и исправьте его подобно описанному выше.
После завершения установки сервера ...
Завершите программу станции и запустите сервер двойным щелчком по его пиктограмме. Несколько сообщений появится в его окне.
Рис. 2.9 Так выглядит окно консоли сервера при его первом запуске
Первые сообщения отражают инициализацию различных процессов сервера. Notes сообщает, какие задачи и процессы начинаются, выполняются или завершаются. Символ >
- "приглашение"
ввести команду сервера.
С имеющимися в этом окне "предложениями" изменить в реестре Windows NT значения двух параметров ("ключей") для улучшения производительности работы сервера Notes в принципе можно согласиться. Однако учтите, что предлагаемое изменение первого параметра (...\LargeSystemCache) в случае, когда оперативной памяти на компьютере только на уровне минимально допустимого количества, может повлечь совсем обратный эффект, поскольку усилится свопинг (страничный обмен между оперативной памятью и файлом pagefile.sys).
Сообщение о том, что для общей адресной книги не назначен сервер администрирования, побуждает администратора после ознакомления с серверной задачей Administration Process (3.2.14) выполнить необходимое назначение.
Если сервер работает, можно заняться установкой первой станции клиента. Если с этой станции удается обратиться к серверу (например, открыть базу данных на нем), скорее всего все нормально.
Планирование репликаций и приоритеты баз
Репликации между серверами не происходят автоматически, они должны быть запланированы. Расписание репликаций задается набором документов Connection в общей адресной книге. Вы должны обычно составлять расписание репликаций так, чтобы только один из двух серверов выполнял вызов другого. Ситуация, когда оба сервера вызывают друг друга поочередно, в принципе допустима, но требует наличия двух согласованных документов Connection, тогда как обычно можно обойтись только одним.
Репликация может быть намечена на заданный отрезок времени с интервалом повторения или только на заданное время. Если вы намечаете репликацию только однократно на заданное время, вы должны задать интервал повторения равным "0". Если в документе Connection поле интервала повторения пустое, сервер принимает интервал повторения равным 60 минут.
1. Отрезок времени с интервалом повторения - 8:00-18:00 с инт. 180 мин.
R__.__.__R__.__.__R__.__.__R__.
8 9 10 11 12 13 14 15 16 17 18
Репликатор впервые вызывает другой сервер в 8:00. Если попытка неуспешна, он повторяет попытку соединения в течение интервала (180 мин.), пока она не будет успешной (см. ниже Randomized exponential backoff algorithm). Следующий вызов будет производиться через 180 мин после успешного завершения репликации. Такой вариант рекомендуется для баз, которые должны реплицироваться наиболее часто.
Рис. 6.13 На отрезке времени с интервалом повторения 60 минут
2. Отрезок времени без интервала повторения - 8:00-18:00 с инт. 0 мин.
Репликатор впервые вызывает другой сервер в 8:00. Если попытка неуспешна, он повторяет попытку соединения в границах отрезка (до 18:00), пока она не будет успешной. После успешного соединения сервер не будет производить новых вызовов. Такой вариант рекомендуется для баз, которые должны реплицироваться со средней частотой.
3. Заданное время
- 8:00 с инт. 0 мин.
Репликатор впервые вызывает другой сервер в 8:00. Если попытка неуспешна, он повторяет попытку соединения в течение часа, пока она не будет успешной (обычно не более 4 попыток). После успешного соединения сервер не будет производить новых вызовов. Такой вариант рекомендуется для баз, которые должны реплицироваться относительно редко.
4. Список заданных времен - 8:00 AM; 1:00 PM; 4:00 PM с инт. 0 мин.
Репликатор впервые вызывает другой сервер в 8:00 утра. Если попытка неуспешна, он повторяет попытку соединения в течение часа, пока она не будет успешной. После успешного соединения сервер не будет производить новых вызовов, пока не наступит следующий указанный в списке момент времени (1:00 дня). Такой вариант рекомендуется для баз, которые должны реплицироваться со средней частотой.
Рис. 6.14 Три раза в заданное время
В окне Replication Settings (Рис. 6.12) для каждой базы можно также задать приоритет участия базы в репликациях. Указывая приоритет, вы фактически относите эту базу в одну из трех групп баз: редко реплицируемые базы (Low); базы, реплицируемые со средней частотой (Medium); базы, реплицируемые часто (High). Соответствующим образом составляя расписание, вы можете реплицировать критические базы данных более часто, чем другие. Например, базы с приоритетом High - несколько раз в день, базы с приоритетом Medium - один раз в день ночью, а базы с приоритетом Low - один раз в неделю по субботам. Для этого потребуется создать несколько документов Connection: например, один для баз только высокого приоритета, один для баз высокого и среднего приоритета и один для баз всех трех приоритетов.
Учтите, что документы Connection для баз данных различного приоритета не должны содержать перекрывающиеся отрезки времени. Если отрезки времени накладываются даже всего на минуту, расписание репликаций считается составленным некорректно. В этом случае репликации могут происходить беспорядочно или могут быть пропущены части списков реплицируемых баз.
|
Результат |
High Высокий |
High & Medium Средний и высокий |
|
Это правильно |
03:00 A.M. - 04:59 A.M. |
05:00 A.M - 10:00 P.M. |
|
Возможны проблемы |
03:00 A.M. - 06:00 A.M. |
05:00 A.M - 10:00 P.M. |
Сервер создает в своей виртуальной памяти список запланированных вами репликаций (расписание) из скрытого вида ($Connections) в общей адресной книге. Этот вид нельзя изменять, ибо в противном случае репликаторы всего домена не будет работать должным образом.
В документах Connection следует задавать полные имена связывающихся серверов. Часто начинающие администраторы задают неполные имена инициирующих репликацию серверов (например, InterTrust вместо InterTrust/InterTrustCorp/SU) и удивляются, почему в заданное время не происходит вызов. А вызов не происходит потому, что сервер (в этом примере InterTrust/InterTrustCorp/SU) "считает", что этот документ Connection "просто не имеет к нему никакого отношения" - документ должен "исполнять" несуществующий сервер InterTrust.
Подключение и исключение ПЯ пользователя к (от) СПЯ
Вы можете использовать Shared Mail, но выборочно исключить ПЯ некоторых пользователей от использования ими СПЯ. Для этого используется команда консоли:
Load Object Set -Never USERMAIL.NSF ,
где USERMAIL.NSF - имя исключаемого ПЯ или имя каталога, содержащего исключаемые ПЯ.
После того, как вы используете эту команду, все сообщения, направляемые в соответствующие ПЯ, будут сохраняться в них полностью. Однако такого не будет происходить с теми ПЯ, которые "подключены" к СПЯ.
Чтобы повторно подключить к использованию СПЯ ранее "исключенные" ПЯ, используется команда консоли:
Load Object Reset -Never USERMAIL.NSF ,
где USERMAIL.NSF - имя "вновь подключаемого" файла ПЯ или имя каталога, содержащего "вновь подключаемые" ПЯ.
Подписанная почта
Когда пользователь при отправке документа почтой требует подписывать сообщение, Notes сначала вычисляет контрольную сумму подписываемых полей сообщения, шифрует ее личным ключом отправителя и сохраняют в дополнительном поле $Signature. Когда другой пользователь получает подписанное сообщение, Notes при наличии поля $Signature декодирует его содержимое публичным ключом отправителя и сверяет с вновь вычисленной контрольной суммой по подписываемым полям принятого сообщения. Если совпадение не обнаружено, получатель предупреждается об этом (диалоговое окно с кнопкой Ок и предупреждением о нарушении подписи). В типовой форме письма Notes подписываются поля SendTo, CopyTo, BlindCopyTo, From, FromDomain, Logo, Subject и Body, если пользователь требует подписывать письмо.
Рис. 9.32 Предупреждение о нарушении подписи
Подписанные секции в документе
В процессе создания формы разработчик может выбрать для поля атрибут signable ("подписываемое"). Если этот атрибут назначен некоторому полю в форме, то поле будет подписано всякий раз, когда отправляют почту, используя эту форму. Если подписываемое поле не входит в состав секции с управляемым доступом, подпись будет действовать только при отправке документа этой формы по почте, тогда как документы этой формы будут сохраняться в базе "неподписанными". При отсутствии секций с управляемым доступом при посылке почтой подпись сохраняется в дополнительном поле $Signature.
Рис. 9.33 Выбор для поля формы атрибута "подписываемое"
Секция с управляемым доступом - область формы с ограниченным доступом на редактирование. "Внутри" секции находятся одно или несколько полей данных. Если хотя бы одно из этих полей имеет атрибут "подписываемое", после сохранения созданного документа при его новом открытии вы увидите на месте заголовка секции с управляемым доступом "электронную подпись".
Рис. 9.34 "Электронная подпись" на заголовке секции документа
Секция с управляемым доступом, в которой есть подписываемые поля, "подписывается" при сохранении документа. Подпись сохраняется в поле $Sig_SectionName, где SectionName - название поля секции с управляемым доступом.
Каждая секция с управляемым доступом "хранит" только одну подпись. Если документ с одной секцией последовательно "подписывают" несколько лиц, на секции всякий раз "стоит" подпись последнего сохранившего документ лица, заменяя подпись ранее сохранившего документ лица.
Секция с управляемым доступом не может содержать вложенных секций с управляемым доступом. Однако документ может иметь больше чем одну секцию с управляемым доступом. Например, каждому подписывающему документ лицу разработчик может предусмотреть свою секцию. В результате документ может иметь много подписей, каждая из которых хранится в собственном поле $Sig_SectionName. При открытии такого документа Notes проверяет все подписи. Чтобы при сохранении документа очередным подписывающим лицом сохранились подписи предыдущих (т.е. их секции не были "пере-подписаны" данным лицом), текущее лицо должно иметь доступ к "чужим" секциям только на чтение.
Рис. 9.35 Фрагмент документа, содержащего две "электронные подписи"
Поле Cutoff Date и история репликаций базы
Проверки поля Cutoff Date и истории репликаций позволяют репликатору максимально сократить множество документов, просматриваемых на предмет возможного участия в репликации.
Поле Cutoff Date
(в версиях 4.х метка поля Only replicate incoming documents saved or modified after:) требует при репликациях принимать в данную реплику только те документы, которые имеют дату модификации позже указанной в поле.
Документы из других реплик этой базы с датой модификации до Cutoff Date никогда не включаются в списки реплицируемых документов и, следовательно, никогда не будут приняты в эту реплику. Репликатор всегда проверяет Cutoff Date и принимает в "свою" реплику только документы, созданные или измененные после этой даты. Аналогично и "окурки" документов, удаленных ранее Cutoff Date, не будут приниматься в реплику этой базы с других серверов. Даже если вы очищаете "историю репликаций".
Рис. 6.15 История репликаций - база на сервере NotesSrv400 в последний раз "отправляла" изменения на сервер InterTrust в 11:10:13, а принимала с него изменения в 10:47:49
Рис. 6.16 История репликаций - база на сервере InterTrust в последний раз "отправляла" изменения на сервер NotesSrv400 в 10:47:49, а принимала с него изменения в 11:10:13
История репликаций содержит время и дату последней успешной репликации с перечисленными в записях истории серверами. Notes при очередной репликации будет при составлении списков реплицируемых документов учитывать только документы, добавленные, измененные или удаленные по времени позднее времени из записи в истории репликаций для этого сервера. После очередной успешной репликации с этим сервером относящиеся к нему записи в истории репликаций заменяются. Если списки истории на обеих сторонах не согласованы (например, если вы очищаете историю на одной стороне), в базе данных будут проверены на предмет участия в репликации все документы, более новые, чем Cutoff Date базы.
При некоторых ситуациях может быть даже полезно очистить историю, потому что этим вы обеспечите полную проверку всех документов в базе на предмет репликации. Вот одна из множества таких ситуаций. Предположим, в документах базы имелись поля типа Readers, в которых использовались имена групп. Ваш сервер не входил ни в одну из этих групп, и такие документы были серверу "не видны", а потому и не реплицировались. Вы добавили имя сервера в состав групп, и теперь хотите реплицировать "прежде невидимые" документы. Но не тут то было... Теперь эти документы стали "видны" серверу, но не реплицируются, поскольку изменения в составе групп не привели к модификации самих документов, а согласно истории репликаций эти документы уже не учитываются.
Так что, если базы данных после репликации не синхронизированы или не имеют одинакового количества документов, причиной этого могли бы быть Cutoff Date или история репликаций. Но не только они.
Полнотекстовый поиск по многим базам данных
Для обеспечения этой возможности создается специальная база данных (типа Multi DB Search) - Search Site. Имеющиеся в базе Search Site
документы определяют область поиска
- набор баз данных, по которым должен осуществляться поиск информации. Эти базы данных могут находиться как на том же сервере, что и база Search Site, так и на других серверах домена или серверах из других доменов. Затем для базы Search Site
создается индекс полнотекстового поиска. Однако, поскольку мы имеем дело с базой типа Multi DB Search, в ее индекс полнотекстового поиска будет включена информация из баз, входящих в ее область поиска, а не из самой базы Search Site. Храниться же этот индекс, обычно немалого размера, будет в каталоге SEARCHSITE.FT, где SEARCHSITE
- имя файла базы Search Site.
Пользователь, чтобы осуществить поиск информации по многим базам данных, открывает базу Search Site. Обычно при этом автоматически открывается поисковая форма. Пользователь заполняет поля поисковой формы, вводя поисковый запрос и, если надо, уточняя подобласть поиска. Синтаксис поисковых запросов практически такой же, как и для поисковых запросов по обычным базам данных.
Рис. 10.13 Пример поискового запроса
"В ответ" пользователь получает "обзорный" документ, содержащий список названий удовлетворяющих его запросу документов и ссылок на них. Выполняя "переход по ссылке", пользователь может открыть найденный документ, если конечно имеет к содержащей его базе и самому документу доступ читателя.
Рис. 10.14 Пример "ответа" на поисковый запрос
Может быть создано несколько баз Search Site. Например, одна из них имеет область поиска по базам данных, содержащим информацию маркетингового характера, другая - в базах данных, содержащим информацию по вопросам технической поддержки, и т.п.
Рассмотрим шаг за шагом те действия, которые необходимо выполнить, чтобы создать, сконфигурировать и обеспечить работоспособность базы Search Site.
1. Разрешение на участие в полнотекстовом поиске по многим базам
· Domain - в область поиска включаются все базы данных на серверах из домена Domain, у которых выбрано свойство Include in multi database indexing.
Кроме того, для набора баз, "описываемого" таким документом, выбирается опция индексирования по умолчанию, обычно Index Full Document.
Рис. 10.16 Пример документа формы Search Score Configuration
После этого на сервере, содержащем базу Search Site, запускают задачу UPDALL со следующими параметрами
Load UPDALL SEARCHSITE [-B] ,
где SEARCHSITE
- имя файла базы Search Site, а -B - необязательный, но желательный в данной ситуации ключ. Ключи этой задачи, относящиеся к вопросам полнотекстового поиска по многим базам данных, рассматриваются ниже.
Задача UPDALL, обнаружив, что база SEARCHSITE имеет тип Multi DB Search, по содержащемуся в этой базе в документах Search Score Configuration "предварительному" описанию области поиска создает "рабочее" описание области поиска, в котором каждая входящая в область поиска база представлена своим документом Database Entry.
Рис. 10.17 Пример документа Database Entry
После этого в документе Database Entry можно изменить только используемую для конкретной базы опцию индексирования и вид, применяемый для поиска документов.
Следующие два примера позволяют лучше понять принцип формирования области поиска.
Пример 1. В домене имеется шесть серверов, и требуется обеспечить возможность поиска по всем базам данных, кроме баз данных на двух серверах. Для этого следует создать один документ Search Score Configuration с опцией индексирования Index Full Document для поиска в пределах домена, а затем создать два документа Search Score Configuration с опцией индексирования No Index для каждого сервера, в базах на котором не должен выполняться поиск. Все базы данных со свойством Include in multi-database indexing на всех серверах будут включены в "рабочую" область поиска, но для баз, расположенных на "не участвующих" в поиске серверах, в документах Database Entry будет выбрано No Index.
Пример 2. Имеется десять баз данных, по которым должен выполняться полнотекстовый поиск. Они находятся на двух серверах. Если только для этих баз данных выбрано свойство Include in multi-database indexing, достаточно создать два документа Search Score Configuration
для поиска в пределах сервера. Все базы данных, для которых выбрано свойство Include in multi-database indexing, будут включены в "рабочую" область поиска. Если же на серверах имеются некоторые базы данных, у которых выбрано свойство Include in multi-database indexing, но они не должны включаться в область поиска данной базы Search Site, опять следует создать два документа Search Score Configuration для поиска в пределах сервера. Но затем следует модифицировать в базе Search Site
документы Database Entry, выбрав для тех баз, которые не должны включаться в область поиска данной базы Search Site, опцию No Index.
Рассмотрим ключи задачи UPDALL, относящиеся к вопросам полнотекстового поиска по многим базам данных.
· Ключ - A требует для баз типа Multi DB Search не обновлять названия баз данных и список видов в документах Database Entry. Однако документы Search Score Configuration
типа Server и Domain, изменившиеся с предыдущего запуска задачи UPDALL, обрабатываются. Обновление индексов полнотекстового поиска выполняется как для баз типа Multi DB Search, так и для "обычных" баз.
· Ключ - B
требует для баз типа Multi DB Search обновить все "рабочее" описание области поиска, но не выполнять обновления индексов полнотекстового поиска. Обновление индексов полнотекстового поиска для "обычных" баз выполняется.
4. Создание индекса полнотекстового поиска базы Search Site
Создание индекса полнотекстового поиска для базы Search Site выполняется обычным образом. Один из вариантов - с закладки Full Text в окне свойств базы. Другой вариант - из окна Server Administration кнопкой Database Tools с последующим выбором "инструмента" Full Text Index. Следует только учитывать, что обычно такие индексы имеют достаточно большой размер и требуют немалого времени на их построение. Поэтому не следует выбирать "излишних" опций создаваемого индекса. Обновлять же такие индексы рекомендуется не чаще раза в день.
5. Передача базы Search Site в эксплуатацию
Убедившись, что база данных нормально функционирует, следует восстановить автоматическое открытие поисковой формы, выбрав в окне свойств базы на закладке Launch в поле On database open: значение Launch 1st doclink in "About database", и выбрать в списке управления доступом Reader для -Default-.
Пользователь изменяет свое имя по почте
1. Пользователь выбирает в меню File - Tools - User ID, затем закладку More Options и на ней кнопку Request New Name. Вводит новое имя и нажимает кнопку OK, затем выбирает адрес своего сертификатора, дописывает свой текст в письмо и отправляет его кнопкой Send.
2. Сертификатор из открытого письма выбирает Actions - Certify Attached ID File, заполняет окно по изменению имени пользователя в документе Person, заполняет окно по формированию обратного письма, затем выбирает изменение имени в группах адресной книги, списках управления доступом почтового ящика и других баз, а так же в полях типа Readers и Authors вручную или с помощью задачи Administration Process.
3. Пользователь из открытого письма выбирает Actions - Accept Certificate. В любом случае после этого пользователя могут ожидать определенные проблемы, подобные рассмотренным при ресертификации с использованием почты. Однако если сертификатор возложил их решение на задачу Administration Process, они будут решены автоматически спустя некоторое время.
Пользователь заменяет свой публичный ключ
Обычно пользователь решает сменить публичный ключ в случае, когда знает или подозревает, что у него был похищен ID-файл и "злоумышленнику" известен его пароль.
Прежде всего давайте обсудим, что собственно может дать смена публичного (и связанного с ним личного) ключа. Предварительно пользователь должен "расшифровать" зашифрованную почту в своем почтовом ящике и базы данных, для которых было применено локальное шифрование, иначе он рискует потерять все это. Все выпущенные для пользователя взаимные сертификаты станут недействительными (поскольку публичный ключ изменяется) и их придется получать снова. Незначительным преимуществом смены публичного ключа по сравнению с регистрацией заново, но под прежним именем, является сохранение имеющихся в ID-файле ключей шифрования. Однако их обычно можно "выгрузить" из прежнего ID-файла и "загрузить" в новый. Процесс установления подлинности (процедура аутентификации) будет с одинаковым успехом выполняться и для ID-файла пользователя с новыми ключами, и для похищенной копии со старыми ключами. Если вы сомневаетесь в справедливости последнего факта, еще раз внимательно рассмотрите алгоритм процесса установления подлинности в 8.3. Поэтому администратор может предотвратить доступ "злоумышленника" под похищенной копией ID-файла к серверам только в том случае, если во всех документах Server запросит сравнение значения публичного ключа из ID-файла со значением, сохраненным в документе Person. Администратор может сделать это, если к серверам имеют доступ только пользователи и другие серверы этого домена. Если же к серверам домена имеют доступ многие пользователи и серверы других доменов, такой путь по практическим соображениям отпадает. Тогда остается только возможность зарегистрировать пользователя под новым именем, а "старое" имя внести в группу Terminations, доступ членов которой запрещен ко всем серверам домена.
Элегантный выход из ситуации с похищением ID-файла имеется только при использовании Notes версий от 4.5. При этом не нужно менять публичный ключ - достаточно сменить пароль в ID-файле и обратиться к администратору, чтобы тот обеспечил доступ ко всем серверам только ID-файла с новым паролем (см. 8.5.9).
Техника смены публичного ключа такова.
1. Пользователь выбирает в меню File - Tools - User ID, затем закладку More Options и на ней кнопку New Public Key. В течение 1-3 минут происходит генерация пары ключей (публичного и личного). В следующем окне пользователь выбирает адрес администратора или своего сертификатора, дописывает свой текст в письмо и отправляет его кнопкой Send.
2. Сертификатор из открытого письма выбирает Actions - Certify Attached ID File, далее кнопку Recertify, после чего осуществляет формирование обратного письма.
3. Пользователь из открытого письма выбирает Actions - Accept Certificate.
протокол Internet, позволяющий любому клиенту,
POP3 Post Office Protocol версии 3 (POP3) - протокол Internet, позволяющий любому клиенту, поддерживающему POP3 (например, Microsoft Internet Explorer, Netscape Navigator, Eudora Pro и др.), получать почту с любого POP3-сервера.
Чтобы использовать сервер Notes как POP3-сервер, на нем запускают задачу POP3, а для каждого POP3-пользователя создают почтовый ящик и документ Person в общей адресной книге. Задача POP3
функционирует на сервере постоянно и ожидает запросов на соединения от POP3-клиентов по протоколу TCP/IP на порту 110. Станция Notes
на компьютере POP3-клиента не запускается и может быть вообще не установлена. Клиент, используя приложение Microsoft Internet Explorer, Netscape Navigator или Eudora Pro, периодически соединяется с сервером по протоколу TCP/IP, порт 110, чтобы "забрать" к себе свою почту. Когда клиент устанавливает соединение, задача POP3 опознает клиента, используя стандарт POP3 для установления подлинности. Это сводится к правильному вводу имени клиента и соответствующего пароля. Если установление подлинности клиента прошло успешно, задача POP3 дает клиенту возможность "забрать" к себе новую почту из его почтового ящика на сервере.
Рис. 3.33 Доступ к почтовому ящику на сервере Notes по протоколу POP3
Вопросы настройки задачи POP3, создания почтового ящика и документа Person для POP3-клиента и настройки программного обеспечения POP3-клиента (на примере Microsoft Internet Explorer) рассматриваются в 10.3.
Пример применения кластера
Рассмотрим пример, в котором применение кластера решает сразу массу проблем. Этот пример позволит вам понять основные принципы применения кластеров, и далее, "через призму этого примера", легче воспринимать приводимый материал.
Исходно в домене (см. Рис. 10.11) имелось два сервера баз данных (Navy и Royal) и один коммуникационный сервер. Сервер Navy использовался в основном как почтовый сервер - он содержал почтовые ящики всех пользователей домена. Сервер Royal содержал две "критические" для бизнес-процесса компании базы данных SALES.NSF и PARTS.NSF. Кроме того, на обоих серверах имелись и другие, менее часто используемые базы данных.
Из-за увеличения количества пользователей в домене резко возросла рабочая нагрузка как на почтовую систему, так и на базы данных, особенно SALES.NSF и PARTS.NSF. Кроме того, когда один из серверов останавливается на профилактику, пользователи теряют возможность обратиться к их почте на сервере Navy или к базам данных на сервере Royal.
Чтобы решить эти проблемы, создаем кластер из двух существующих серверов (Navy и Royal) и нового сервера True. При планировании кластера используем следующие соображения.
Рис. 10.11 Пример кластера из трех серверов Notes
· Выбираем аппаратную платформу нового сервера так, чтобы общая вычислительная мощность трех серверов с определенным запасом позволяла справиться с имеющейся рабочей нагрузкой.
· Создаем дополнительные реплики баз данных на серверах кластера так, чтобы при сбое или отключении на профилактику любого одного из серверов пользователи могли обратиться к их репликам на каком-то из серверов, продолжающих функционировать.
· Поскольку базы SALES.NSF и PARTS.NSF наиболее критичны для бизнес-процесса, создаем их реплики на каждом из трех серверов кластера. Посредством внутрикластерных репликаций изменения из одной реплики "в реальном времени" будут распространяются в реплики на других серверах. За счет переключений (failover) доступ к этим базам будет возможен, даже если откажут два из трех членов кластера. В нормальном же режиме работы пользовательские запросы к этим базам должны "распределяться" по всем трем серверам, благодаря чему будет обеспечено малое время отклика.
· Чтобы обеспечить доступность почты, создадим по две реплики почтового ящика каждого пользователя на разных серверах кластера. Распределим файлы почтовых ящиков так, чтобы на каждом сервере имелось примерно две трети от увеличенного вдвое общего количества файлов почтовых ящиков. В документах Person распределим почтовые серверы (поле Mail Server) внутри кластера так, чтобы на каждый сервер приходилось примерно одна треть пользователей. Имея две реплики каждого почтового ящика на разных серверах кластера и благодаря переключениям (failover), обеспечиваемым кластером, мы гарантируем, что пользователь будет способен и посылать и получить почту, даже если его почтовый сервер не функционирует.
· Может быть желательно создать дополнительные реплики некоторых других баз данных, чтобы обеспечить их более высокую доступность.
· В качестве дополнительной меры можно рекомендовать создание отдельного сегмента локальной сети между серверами кластера и настройку серверов кластера так, чтобы весь внутрикластерный обмен происходил именно по этому сегменту сети.
Примеры доставки почты
Рассмотрим различные варианты доставки почты в конфигурации, приведенной на Рис. 7.8. Имеется три домена. В домене X две поименованных сети Notes: в состав первой входят серверы A, B и C, в состав второй - серверы J, K и H. В адресной книге этого домена три документа Connection: два между серверами A и J (типа Dialup Modem), и один с сервера K на сервер Q из домена Y
(тоже типа Dialup Modem). Все серверы домена Y в одной поименованной сети. В адресной книге домена Y два документа Connection: один с сервера Q на сервер K из домена X (типа Dialup Modem), а второй - с сервера S на сервер T из домена Z
(типа Local Area Network). В домене Z одна поименованная сеть, а в адресной книге один документ Connection - с сервера T на сервер S из домена Y (типа Local Area Network).
У пользователей один и тот же почтовый сервер
Jon, чей почтовый сервер - A, посылает сообщение Ed, чей почтовый сервер тоже A. Сообщение поступает из почтового ящика Jon в MAIL.BOX на сервере A. Обнаружив сообщение в своем MAIL.BOX, Router перемещает его в почтовый ящик Ed.
Рис. 7.8 Конфигурация сети Notes
Одна и та же поименованная сеть, но разные почтовые серверы
Jon посылает сообщение Peggy, чей почтовый сервер - C. Router на сервере А просматривает адресную книгу для определения местоположения почтового ящика Peggy. Он обнаруживает, что файл почты Peggy
находится на сервере C, который в той же поименованной сети, что и А, устанавливает соединение с сервером C
и передает сообщение в MAIL.BOX на сервере C. Router на сервере C перемещает сообщение в файл почты Peggy.
Разные поименованные сети
Peggy, чей почтовый сервер C, посылает сообщение Bud. Router на сервере C проверяет адресную книгу и обнаруживает, что почтовый сервер Bud называется H и находится в другой поименованной сети. Router проверяет документы Connection, находит, что сервер A имеет соединение с сервером J, который в одной поименованной сети с H, и передает сообщение с C на A. Когда наступает указанное в расписании время передачи почты, сервер А передает сообщение на сервер J. Router на сервере J проверяет адресную книгу и поставляет сообщение в MAIL.BOX на сервере H. Router на сервере H перемещает сообщение в файл почты Bud.
Разные домены
Peggy из домена X посылает сообщение Sue из домена Y. Документ Connection в адресной книге показывает, что сервер K из домена Peggy может связываться с сервером Q в домене Sue. Сообщение перемещается с почтового сервера Peggy, C, на сервер A, через модемное соединение на J, и далее на K по локальной сети. Сервер K передает сообщение на сервер Q. Router на Q находит в адресной книге домена Sue почтовый сервер Sue, R, и отправляет сообщение на сервер R. Router на R помещает сообщение в почтовый ящик Sue.
Одна и та же локальная сеть, но разные домены и поименованные сети
Sue из домена Y посылает сообщение Bob из домена Z. Router исследует адресную книгу домена Y и находит документ Connection, показывающий, что сервер S может соединяться с сервером T в домене Bob. Сообщение передается по локальной сети с почтового сервера Sue, R, на сервер S, и с него на T. Сервер T отправляет сообщение на почтовый сервер Bob, где Router помещает сообщение в файл почты Bob.
Примеры доставки почты при наличии документов Domain
Домен Dom1 состоит из 4 серверов в 2 поименованных сетях Notes - Net1 (серверы s1, s2, s3, протокол SPX) и Net2 (серверы s3 и s4, протокол NETBIOS). В адресной книге имеется два документа Connection: s2 ® s6 (домен Dom2) и s4 ® s5 (домен Dom2). Кроме того, имеется документ Non-adjacent Domain: почту, адресованную в домен Dom3, следует отправлять в домен Dom2.
Домен Dom2 имеет 2 сервера s5 и s6 в одной поименованной сети (например, Net1, протокол TCP IP). В адресной книге 3 документа Connection: s6 ® s7 (домен Dom3), s6
® s2 (домен Dom1) и s5
® s4 (домен Dom1).
Домен Dom3 имеет 2 сервера s7 и s8 в одной поименованной сети (например, Net3, протокол NETBIOS поверх NETBEUI). В адресной книге один документ Connection:
s7 ® s6 (домен Dom2) и один документ Non-adjacent Domain, согласно которому почту, адресованную в домен Dom1, следует отправлять в домен Dom2.
Рис. 7.12 Конфигурация сети Notes
Обратите внимание, что в следующих примерах имеется в виду, но для простоты не оговаривается тот факт, что Router-ы работают с информацией из документов адресной книги, уже загруженной в таблицы маршрутизации в виртуальной памяти, а не с реальными документами из адресной книги.
Один домен, разные поименованные сети
Пользователь u1/Org1 из домена Dom1 (почтовый сервер s1) посылает сообщение пользователю u2/Org1 из домена Dom1 (почтовый сервер s4). В поле SendTo сообщения: u2/Org1.
1. Mailer на станции u1 проверяет адрес в поле SendTo. "Свой" домен. Получатель u2/Org1 имеется в адресной книге. Mailer помещает сообщение в MAIL.BOX на s1.
2. Router на сервере s1 проверяет адрес получателя сообщения и его документ Person, и определяет, что почтовый ящик получателя u2/Org1 находится на сервере s4. Router проверяет документы Server и узнает, что s1 в поименованной сети Net1, s4 в поименованной сети Net2, и s3 в обеих поименованных сетях Net1 и Net2. Router соединяется напрямую с сервером s3 и помещает сообщение в MAIL.BOX на s3.
3. Router на сервере s3 проверяет документ Person получателя и определяет, что его почтовый ящик на сервере s4. Router проверяет документы Server и "узнает", что s4 в той же самой поименованной сети Net2. Router соединяется напрямую с сервером s4 и помещает сообщение в MAIL.BOX на s4.
4. Router на сервере s4 проверяет документ Person и определяет, что почтовый ящик получателя находится "на нем самом". Router помещает сообщение в почтовый ящик получателя.
5. Mailer на станции u2 (если она работает и на ней запущен Notes) проверяет почтовый ящик пользователя каждые 15 минут. Он обнаруживает "непрочитанное" сообщение и информирует пользователя: "You have new mail".
Разные домены, разные поименованные сети
Пользователь u1/Org1 из домена Dom1 (почтовый сервер s1) посылает почту пользователю u3/Org3 из домена Dom3 (почтовый сервер s8). В поле SendTo сообщения: u3/Org3 @ Dom3.
1. Mailer на станции u1 проверяет адрес в поле SendTo. Mailer "видит", что сообщение адресовано в другой домен, следовательно, проверить адрес получателя не представляется возможным. Поэтому Mailer просто помещает сообщение в MAIL.BOX на s1.
2. Router на сервере s1 проверяет адрес в поле SendTo и "видит", что получатель в другом домене. Router проверяет документы Domain и "узнает", что почту в домен Dom3 следует отправлять в домен Dom2. Router проверяет документы Connection на любой сервер в домене Dom2 и находит, что сервер s2 может соединяться с сервером s6 из домена Dom2 и сервер s4 тоже может соединяться с сервером s5 из Dom2. Router определяет маршрут "наименьшей стоимости", в данном случае s1®s2®s6 (стоимость 1+5=6). Следующий сервер в маршруте s2. Router проверяет документы Server и находит, что s2 в той же самой поименованной сети, что и s1. Router напрямую соединяется с s2 и помещает сообщение в MAIL.BOX на s2.
3. Router на сервере s2 проверяет адрес в поле SendTo и "видит", что получатель в другом домене. Router проверяет документы Domain и обнаруживает, что почта в домен Dom3 должна отправляться в домен Dom2. Router проверяет документы Connection "на домен" Dom2 и находит, что сервер s2 ("он сам") может соединяться с сервером s6 из Dom2 и сервер s4 может соединяться с сервером s5 из Dom2. Router выбирает маршрут "наименьшей стоимости": s2®s6 (стоимость 5). Следующий сервер в маршруте s6. Router соединяется с сервером s6 (согласно документу Connection и с учетом приоритета сообщения) и помещает сообщение в MAIL.BOX на s6.
4. Router на сервере s6 проверяет адрес в поле SendTo. Разные домены. Router проверяет документы Domain и не находит ничего полезного. Router проверяет документы Connection "на домен" Dom3 и находит, что сервер s6 может соединяться с сервером s7 из Dom3. Router находит маршрут наименьшей стоимости на сервер назначения: s6®s7 (стоимость 5). Следующий сервер на маршруте s7. Router соединяется с сервером s7 (согласно документу Connection и с учетом приоритета сообщения) и помещает сообщение в MAIL.BOX на s7.
5. Router на сервере s7 проверяет адрес в поле SendTo. Получатель из "своего" домена. Router проверяет документ Person получателя и "узнает", что его почтовый ящик находится на сервере s8. Router проверяет документы Server и узнает, что s8 в одной с ним поименованной сети. Router напрямую соединяется с s8 и помещает сообщение в MAIL.BOX на s8.
6. Router на сервере s8 помещает сообщение в почтовый ящик получателя.
7. Mailer на станции u3 сообщает получателю: "You have new mail".
