Шифрование полей в документах
Notes позволяет ограничивать доступ к определенным полям в документах посредством шифрования (encryption) их содержимого. Шифрование - кодирование данных так, чтобы только те пользователи, которые имеют ключ, могли эти данные читать. Встречаются системы шифрования с одним ключом ("симметричная" система) и с двумя (личным и публичным) ключами ("асимметричная" система).
В первом случае один и тот же ключ используется и для кодирования, и для декодирования информации. Обе стороны должны знать тот же самый ключ. Этот метод неудобен при передаче почты в больших сетях, где пользователи могут и не знать друг друга лично. Но он удобен в случае использования зашифрованных документов из одной базы ограниченным кругом лиц, каждому из которых можно предоставить ключ шифрования. В Notes "на этом поприще" используется криптосистема с одним ключом DES (Data Encryptions System), разработанная фирмой IBM по заказу правительства США и считающаяся одной из наиболее "быстрых".
Во втором случае один из пары ключей используется для кодирования, а другой для декодирования информации. В Notes "на этом поприще" используется криптосистема RSA с двумя ключами. Эта криптосистема была изобретена в 1977 году тремя профессорами Ronald Rivest, Adi Shamir и Leonard Adelman (отсюда и аббревиатура RSA) из MIT, впоследствии основавшими компанию RSA Data Security Inc. в Redwood City, Калифорния. В криптосистеме RSA каждому субъекту (пользователю, серверу) назначается уникальная пара ключей: личный (private) ключ, который этот субъект хранит в тайне, и публичный (public) ключ, который, напротив, должен быть известен многим. Данные, зашифрованные одним из пары ключей, могут быть расшифрованы только при наличии другого ключа из этой пары.
Личный ключ хранится только в ID-файле субъекта. Публичный ключ хранится и в ID- файле субъекта, и в общей адресной книге. Любой пользователь сети Notes может отправить для пользователя Х сообщение, зашифрованное публичным ключом пользователя Х, ибо общая адресная книга с этим ключом общедоступна. Только пользователь Х может расшифровать это сообщение, ибо только в его ID-файле хранится его личный ключ. При регистрации нового пользователя в общую адресную книгу добавляется его публичный ключ. Пользователь без публичного ключа в адресной книге вообще не может получить шифрованную почту.
В Notes для шифрования используются обе криптосистемы (RSA и DES), причем во многих случаях комбинированно. Алгоритмы шифрования полей документа и шифрования почтового сообщения различны.
Информация в полях документов, хранимых в базах данных Notes, шифруется по схеме с одним ключом. Ключи шифрования (encryption keys) создаются пользователями и сохранятся в ID-файлах пользователей. Информация в документах и шифруется, и дешифрируется одним и тем же ключом шифрования. Чтобы иметь доступ к зашифрованной информации, нужно иметь в ID-файле соответствующий ключ. Ключи шифрования также могут быть ограниченно распространены среди группы пользователей, имеющих доступ к зашифрованной этими ключами информации (по аналогии с ключами от рабочих помещений). Таких ключей может быть создано много, каждый для своего специального применения. Чтобы "отличать" ключи друг от друга, все ключи "внутри" одного ID-файла имеют уникальное имя.
Кроме того, информация в одном документе может быть зашифрована сразу несколькими ключами шифрования, которые находятся в ID-файле "шифрующего" документ. Для дешифрирования информации в документе достаточно наличия в ID-файле только одного из использованных при шифровании ключей. Для "запоминания" этого момента полезна аналогия с комнатой, имеющей три двери: три ключа необходимы, чтобы запереть все двери, но только один ключ необходим, чтобы войти в комнату. А в качестве примера целесообразного использования можно предложить следующий. В подразделении два отдела. Отдел А имеет ключ шифрования "КлючА", а отдел В - "КлючВ". Руководство подразделения, в который входят эти отделы, имеет оба ключа "КлючА" и "КлючВ". Если документ создан в отделе А и зашифрован ключом "КлючА", к информации в нем могут получить доступ только имеющие "КлючА" - отдел А и руководство подразделения, но не отдел В. Если документ создан в отделе В и зашифрован ключом "КлючВ", к информации в нем могут получить доступ только имеющие "КлючВ" - отдел В и руководство подразделения, но не отдел А. Если же документ был создан в подразделении и был зашифрован обоими ключами "КлючА" и "КлючВ", к информации в нем могут получить доступ как в подразделении, так и в отделе А (имея "КлючА") и в отделе В (имея "Ключ В").
Итак, для обеспечения шифрования документов необходимы три шага: создание ключа и распространение его среди группы пользователей, создание в документе шифруемых полей и назначение ключа для документа.
Шифрование сохраненной почты
Пользователь может запросить шифрование почты, сохраняемой им в своем почтовом ящике. Шифруется только содержимое поля Body сообщения, шифрование выполняется случайно сгенерированным ключом шифрования, который затем шифруется публичным ключом пользователя. Для дешифрирования сохраненной почты необходим личный ключ пользователя, имеющийся только в его ID-файле.
Шифрование сохраняемой в почтовом ящике почты выбирается посредством установок в диалоговом окне User Preferences на закладке
Mail (опция Encrypt Saved Mail). Когда пользователь отправляет почту, то после её отправки перед записью "копии" в почтовый ящик выполняется шифрование поля Body сохраняемого документа. Если пользователь просто сохраняет почту, так и не отправив ее, поле Body тоже шифруется. Однако выбор этой опции автоматически не зашифрует ранее сохраненную почту - чтобы зашифровать ее, пользователь должен ее повторно открыть и повторно сохранить.
Шифрование входящей почты
Шифрование входящей почты работает аналогично шифрованию исходящей почты: случайно сгенерированный ключ шифрования с его последующим шифрованием публичным ключом получателя. Только это происходит во время поступления сообщения в почтовый ящик получателя, когда серверная программа Router "перекладывает" поступившее письмо из базы входящих писем сервера - MAIL.BOX - в почтовый ящик.
Администратор Notes может "затребовать" автоматическое шифрование всей прибывающей на сервер входящей почты, установив в файле NOTES.INI сервера ненулевое значение переменной MailEncryptIncoming, например: MailEncryptIncoming = 1.
Пользователь тоже может выбрать шифрование входящей почты, но только для себя. В его документе Person в общей адресной книге в группе полей Misc есть поле с меткой Encrypt Incoming Mail:. Для шифрования входящей почты в нем надо выбрать Yes.
Система электронной почты
Термин сообщение
используется повсюду в этой главе для обозначения документа Notes, который передается системой почты Notes. Сообщение может быть составлено как с использованием стандартной почтовой формы Notes, так и по совершенно иной форме.
Система электронной почты Notes содержит четыре основных компоненты:
· Mailer
- подсистема, отвечающая за поиск имен (адресов) получателей сообщений, помещение адресов в почтовую форму, отправку сообщений на почтовый сервер и некоторые другие почтовые возможности, в частности, возврат отправителю уведомления о прочтении получателем его сообщения и предупреждение получателя о наличии новых сообщений. Mailer работает на станции клиента. Он - часть программного обеспечения станции. Однако вы явно не обнаружите в каталоге программ Notes соответствующих этой подсистеме выполняемых файлов или библиотек динамической компоновки - Mailer "размазан" по программному обеспечению станции.
· Router
- подсистема, осуществляющая доставку сообщений. Router выполняется на сервере Notes. Это отдельная серверная программа Mail Router (хROUTER.exe, где х зависит от платформы). В ходе своей работы она создает подпроцессы (threads), выполняющие доставку сообщений - по умолчанию по одному подпроцессу на каждый порт сервера.
· Служба имен
- подсистема, ответственная за работу с адресной книгой. Служба имен обычно постоянно работает на сервере, но может в некоторые моменты времени работать и на станции.
· Gateways (шлюзы)
и (или) Mail Transfer Agents (агенты передачи почты) - программы, которые могут передавать сообщения между пользователями почтовой системы Notes и пользователями "чужой" (т. e. не - Notes) почтовой системы. Программа шлюза или агент передачи почты обычно выполняются на сервере Notes и пользуются услугами, обеспечиваемыми Router. Чтобы Router "знал" о наличии шлюза (агента), в общей адресной книге создается документ формы Foreign Domain, содержащий имя "чужого" домена, имя сервера Notes, на котором функционирует шлюз (агент), и имя файла почтовой базы, через которую Router и шлюз (агент) обмениваются сообщениями.
Хотя перечисленные компоненты распределены по разным компьютерам, они действуют совместно и согласованно, чтобы исполнить одну основную функцию: перемещение документа Notes - сообщения - со станции отправителя через цепочку серверов в почтовый ящик получателя, который определен своим именем (адресом).
Соединения через асинхронный PAD по сети X.
Здесь мы предполагаем, что на вызывающем компьютере (станции или сервере) модем подключен непосредственно к COM-порту. Однако он выполняет телефонный вызов на модем, находящийся "на входе" асинхронного ассемблера/дизассемблера пакетов (асинхронный PAD). PAD территориально расположен у "ближайшего" провайдера услуг X.25 и своей "второй стороной" подключен к сети X.25. Вызываемый сервер Notes оборудован картой X.25
фирмы Eicon
(подробнее смотрите в 4.1.1), которая также подключена к сети X.25.
Таким образом, с точки зрения модели, приведенной на Рис. 5.1, управляемое устройство УУ1 и скрипт его "приобретения" в данном случае отсутствуют. Роль управляемого устройства УУ2 выполняет асинхронный PAD. Диалог между вызывающим компьютером и PAD задается скриптом соединения. Этот диалог сводится к переводу PAD в необходимый режим и "вынуждению" его установить соединение с абонентом сети X.25, имеющим определенный DTE-адрес, т.е. картой X.25, установленной в вызываемом сервере Notes. Выполняется скрипт соединения, естественно, после того, как установлено соединение с установленным "на входе" PAD модемом.
Рис. 5.11 Схема соединения через асинхронный PAD по сети X.25
Рассмотрим действия, которые необходимо выполнить по настройке вызывающих станции или сервера в такой ситуации.
Настройки COM-порта
Единственным отличием от рассмотренного в 5.1 в конкретном случае, с которым имел дело автор, было то, что асинхронный PAD "требовал", чтобы модемное соединение с ним устанавливалось на фиксированной скорости 9600 bps. Однако модемы на вызывающем компьютере и PAD, а так же свойства соединяющей их телефонной линии при использовании штатного файла управления модемом "провоцировали" драйвер XPC на установление соединения на более высокой скорости. Проблема была устранена модификацией файла управления модемом: в строку инициализации модема ZyXEL U-1496+ была добавлена команда &N3, "вынуждающая" вызывающий модем устанавливать соединение с вызываемым на фиксированной скорости 9600 bps.
; а скрипт ожидает этого символа до 20 секунд.
WAIT 20 FOR "@"
; REPLY "String" посылает на УУ строку "String".
; В данном случае на PAD посылаются строки, переводящие PAD
; в режим, необходимый для работы с Notes. Все эти строки "SET"
; в точности заимствованы из "штатного" скрипта.
; ERROR <метка> после WAIT [N] [FOR "SubString"]
; передает управление на указанную метку, если за N секунд
; от УУ не получена строка, содержащая "SubString".
REPLY "SET 1:0,2:0,3:0,4:20,5:0,7:0,8:0,9:0"
WAIT 5 FOR "@"
ERROR TIMEOUT
REPLY "SET 10:0,12:0,13:0,14:0,15:0,16:0,17:0,18:0"
WAIT 5 FOR "@"
ERROR TIMEOUT
REPLY "SET 19:1,20:255"
WAIT 5 FOR "@"
ERROR TIMEOUT
; REPLY "^1" передает PAD значение первого аргумента: DTE-адрес
; абонента в сети X.25, с которым нужно установить соединение.
; WATCH [N]
; [FOR]
; "SubString1" Оператор1
; "SubString2" Оператор2
; . . .
; ENDW
; представляет собой "переключатель" в зависимости от того,
; содержится ли в "ответе" УУ указанная подстрока "SubStringI".
; Если за N секунд не получено предусмотренного ответа,
; выполняется следующий за ENDW оператор.
; "END" "нормально" завершает скрипт.
; FAIL String записывает строку в LOG.NSF и завершает скрипт "по ошибке".
; Если PAD возвращает строку "CONNECTED", соединение с абонентом X.25
; установлено, и скрипт "нормально" завершает работу.
; Иначе скрипт завершает работу "по ошибке".
REPLY "^1"
WATCH 15
"CONNECTED" END
"REJECTING" FAIL > Call rejected
"ILLEGAL ADDRESS" FAIL > Illegal DTE address
"?" FAIL > Unrecognized DTE address
ENDW
FAIL > Timed out trying to connect
; Инициализация модема станции
19.11.96 15:26:25 COM1: Send to Modem: AT&FE0X6&N3 (9600 bits per second)
19.11.96 15:26:25 COM1: Receive from Modem: OK
19.11.96 15:26:26 COM1: Send to Modem: ATM0 (9600 bits per second)
19.11.96 15:26:26 COM1: Receive from Modem: OK
19.11.96 15:26:26 COM1: Send to Modem: AT&H0 (9600 bits per second)
19.11.96 15:26:26 COM1: Receive from Modem: OK
19.11.96 15:26:26 COM1: Send to Modem: ATS9=6 (9600 bits per second)
19.11.96 15:26:27 COM1: Receive from Modem: OK
; Набор телефонного номера модема на PAD
19.11.96 15:26:27 COM1: Send to Modem: ATDP1234567, (9600 bits per second)
; Ответ модема на PAD на входящий вызов
19.11.96 15:26:56 COM1: Receive from Modem: CONNECT 9600/ARQ
19.11.96 15:26:56 COM1: 9600 bits per second connection established
; Соединение с модемом на PAD установлено, начинается выполнение скрипта соединения
19.11.96 15:26:59 COM1: Script Received: SPRINT NETWORKS
19.11.96 15:26:59 COM1: Script Received: 777 3350.07
19.11.96 15:26:59 COM1: Script Matched: @
; После ответа PAD на него посылаются команды SET
19.11.96 15:26:59 COM1: Script Sent: SET 1:0,2:0,3:0,4:20,5:0,7:0,8:0,9:0
19.11.96 15:26:59 COM1: Script Received: @SET 1:0,2:0,3:0,4:20,5:0,77:0,8:0,9:0
19.11.96 15:27:00 COM1: Script Matched: @
19.11.96 15:27:00 COM1: Script Sent: SET 10:0,12:0,13:0,14:0,15:0,16:0,17:0,18:0
19.11.96 15:27:00 COM1: Script Received: @SET 10:0,12:0,13:0,14:0,15:0,16:0,17:0,18:0
19.11.96 15:27:01 COM1: Script Matched: @
19.11.96 15:27:01 COM1: Script Sent: SET 19:1,20:255
19.11.96 15:27:01 COM1: Script Received: @SET 19:1,20:255
19.11.96 15:27:01 COM1: Script Matched: @
; На PAD посылается DTE-адрес, с которым нужно установить соединение
19.11.96 15:27:02 COM1: Script Sent: 7770123400
19.11.96 15:27:02 COM1: Script Received: @7770123400
19.11.96 15:27:02 COM1: Script Received: 777 1234 CONNECTED
19.11.96 15:27:02 COM1: Script Matched: CONNECTED
19.11.96 15:27:03 COM1: End of script file or END command reached
; Скрипт соединения завершил работу
; Далее станция устанавливает соединение с сервером Notes
19.11.96 15:27:25 Network: Determining path to server NS330/CROC
19.11.96 15:27:25 Network: Checking normal priority connection records only...
19.11.96 15:27:25 Network: Allowing wild card connection records...
19.11.96 15:27:25 Network: Enabling name server requests...
19.11.96 15:27:25 Network: Checking local COM1 names table for NS330/CROC
19.11.96 15:27:25 Network: Address found for NS330/CROC via COM1
19.11.96 15:27:25 Network: Connecting to NS330/CROC over COM1
19.11.96 15:27:25 Network: Use address 'NS330' on COM1
19.11.96 15:27:36 Network: Connected to server NS330/CROC
Остается отметить, что номера телефонов и DTE-адреса в документе Connection и протоколе заменены вымышленными.
Совместно используемый почтовый ящик (shared mail) и серверная задача Object store manager
OBJECT Установка на сервере возможности "совместно используемый почтовый ящик" (СПЯ) позволяет экономить дисковую память. Предположим, нескольким получателям, почтовые ящики которых находятся на этом сервере, приходит одно и то же сообщение. Вместо того чтобы помещать копию всего сообщения в почтовый ящик каждого получателя, в их почтовые ящики добавляется только заголовок сообщения со ссылкой на тело сообщения, а тело сообщения (содержимое поля Body типа Rich Text, включая присоединенные файлы) помещается в одном экземпляре в совместно используемый почтовый ящик. Например, если тело сообщения имеет размер 1 Мб, а сообщение адресовано 10 получателям на этом сервере, будет сэкономлено около 9 Мб памяти. В то же время для пользователя такое хранение его сообщения остается "полностью прозрачным". Когда пользователь открывает сообщение, заголовок активизирует связь с телом сообщения, сохраненным в СПЯ. Notes "показывает" получателю сообщение точно так же, как если бы все сообщение было целиком в почтовом ящике пользователя. Если пользователь удаляет такое сообщение, Notes удаляет только заголовок из почтового ящика пользователя, а тело сообщения остается в совместно используемом почтовом ящике, однако счетчик ссылок на тело сообщения уменьшается на единицу. После того, как все получатели на этом сервере удалили это сообщение из своих почтовых ящиков, счетчик ссылок на тело сообщения становится равным нулю, серверная задача Object store manager, запускаемая по умолчанию в 2 часа ночи с параметром Collect, удаляет уже более никому не нужное тело сообщения из совместно используемого почтового ящика.
Все работы по сопровождению и настройке совместно используемой почты администратор выполняет с использованием серверной задачи Object store manager - OBJECT.
Более подробно задача OBJECT
и ее многочисленные параметры будут рассмотрены в главе 7.
Создание дополнительных СПЯ
Пока имеется достаточно дискового пространства, чтобы поддерживать рост СПЯ, вам не имеет никакого смысла создать дополнительные СПЯ. Функция Collect, которая по умолчанию выполняется ежедневно, ограничивает рост СПЯ. Однако, когда размер "первого" СПЯ станет очень большим, возникает необходимость создать дополнительный СПЯ на другом диске и "пере-присоединить" к нему некоторые ПЯ.
Между тем, только один СПЯ будет использоваться серверной задачей Mail Router для доставки почты. Но можно иметь больше чем один СПЯ, содержащий тела сообщений, которые были доставлены ранее или присоединены к этим СПЯ вручную.
Чтобы создавать дополнительный СПЯ, используют команду:
Load Object Create NEWOBJ.NSF ,
где NEWOBJ.NSF - имя нового СПЯ, если необходимо, включая путь.
После этого к созданному СПЯ присоединяют необходимые ПЯ, используя опции Link и Relink команды Load Object.
Создание древовидного набора иерархических сертификаторов
Речь пойдет о создании набора ID-файлов для сертификаторов: ID-файла сертификатора организации (верхний уровень) и ID-файлов сертификаторов отделений, отделов и более мелких оргединиц. Эти ID-файлы создают остов "для развертывания" дерева имен вашей организации. Обычно каждый такой ID-файл передается конкретному лицу - сертификатору соответствующего уровня. Используя полученные ID-файлы,
сертификаторы будут создавать ID-файлы пользователей, серверов или других сертификаторов "на уровень ниже их самих" в дереве имен или ресертифицировать ID-файлы пользователей и серверов. Следовательно, вся немалая работа по сертификации и ресертификации может выполняться не одним сертификатором, а "целой иерархией" сертификаторов, возможно, даже территориально-удаленных.
Рис. 8.7 Древовидный набор иерархических сертификаторов - остов для "выращивания дерева" имен в организации
Создание и распространение ключа шифрования
Любой пользователь Notes может создать ключ шифрования, выбрав в меню File - Tools - User ID… , и нажав кнопку New в диалоговом окне на закладке Encryption (Рис. 9.17).
В очередном диалоговом окне (Рис. 9.18) ключу присваивается имя. По нажатию кнопки OК
ключ шифрования добавляется в ID-файл пользователя.
Чтобы другие пользователи могли читать шифрованные документы, им должны быть предоставлены ключи шифрования. Есть два пути распространения ключей шифрования: почтой Notes или через файлы (экспорт/импорт).
Распространение ключей почтой
Нажав кнопку Mail
в диалоговом окне на закладке Encryption (Рис. 9.17), пользователь может отправить ключ шифрования своим коллегам. Он заполняет в полученном окне (Рис. 9.19) адрес, нажимает кнопку Send и в следующем в диалоговом окне (Рис. 9.20) "решает вопрос", может ли получатель передавать полученный ключ другим лицам. Передаваемый ключ всегда автоматически шифруется и подписывается.
Коллеги, получившие такое письмо (Рис. 9.21), должны выбрать в меню Actions - Accept Encryption Key - ключ шифрования будет добавлен в их ID-файл.
Рис. 9.17. Окно свойств ID-файла пользователя - закладка Encryption
Рис. 9.18. Создание ключа шифрования
Рис. 9.19. Отправка ключа шифрования почтой
Рис. 9.20. Может ли получатель передавать ключ другим?
Рис. 9.21. Письмо с ключом шифрования
Распространение через файлы (экспорт/импорт)
Пользователь выбирает ключ шифрования и экспортирует его кнопкой Export в диалоговом окне на закладке Encryption (Рис. 9.17). Файл, в который экспортируется ключ, не шифруется, но пользователь может защитить его паролем (Рис. 9.22), а также указать, может или нет получатель передавать ключ другим (Рис. 9.23).
Рис. 9.22. Экспорт ключа шифрования
Рис. 9.23. Точное имя получателя и возможность передавать ключ другим
Рис. 9.24. Запись ключа в файл
Ключ экспортируется в файл с расширением .KEY в выбранном пользователем каталоге (Рис. 9.24). Создатель файла ключа передает его получателям, сам отвечая при этом за физическую безопасность.
Чтобы импортировать ключ (добавить его в свой ID-файл), пользователь-получатель нажимает кнопку Import в диалоговом окне на закладке Encryption (Рис. 9.17) и выбирает файл импортируемого ключа.
Рис. 9.25. Выбор файла с импортируемым ключом
Если файл ключа защищен паролем, получатель должен его ввести. Ключ добавляется в ID-файл получателя кнопкой Accept в следующем окне.
Рис. 9.26. Добавление ключа в ID-ФАЙЛЕ-файл
Создание ID-файла сертификатора организации
Обычно в качестве ID-файла сертификатора организации используют файл CERT.ID, созданный при установке первого сервера Notes в организации. Однако при необходимости всегда можно создать другой ID-файл сертификатора организации. Рекомендуется иметь только один ID-файл сертификатора организации
для одной организации, поскольку это исключает обмен взаимными сертификатами внутри организации. Но можно иметь и несколько таких ID-файлов, выпустив необходимые взаимные сертификаты.
Выбираем из меню File - Tools - Server Administration, далее кнопку Certifiers и в ее меню Register Organization ... .
Рис. 8.8 Окно Server Administration с раскрытым меню кнопки Certifiers
Получаем окно для регистрации сертификатора организации.
Рис. 8.9 Окно для регистрации сертификатора организации
В окне вводим обозначение страны, название организации и пароль для ID сертификатора организации. В поле Administrator вводим имя (адрес) лица, которое будет "владеть" ID-файлом и обслуживать запросы (в том числе и почтовые) на сертификацию. В окне по кнопке Other Certifier Settings можно задать дополнительную информацию о сертификаторе (она носит чисто информационный характер), а также изменить минимально-допустимую длину пароля.
Рис. 8.10 Окно Other Certifier Settings
Кнопка Registration Server позволяет выбрать сервер, в адресной книге которого будет создан документ Certifer со сведениями о сертификаторе организации. Кнопка Register выдает диалоговое окно для выбора местоположения и имени ID-файла сертификатора организации. После выбора местоположения и имени файла через 1-3 минуты ID-файл сертификатора организации будет создан.
Рис. 8.11 Документ Certifier
типа Notes Certifier содержит информацию о сертификаторе организации
Создание ID-файлов сертификаторов оргединиц
Оргединицы обычно соответствуют отделениям, отделам и рабочим группам в организации. Применять ID-файлы сертификаторов оргединиц особенно целесообразно в больших организациях с территориально удаленными офисами.
ID-файл сертификатора оргединицы "подчинен по рангу" ID-файлу сертификатора организации или вышестоящей оргединицы. С его помощью можно создавать ID-файлы сертификаторов подчиненных оргединиц и сертифицировать ID-файлы пользователей и серверов.
Для создания ID сертификатора оргединицы выбираем из меню File - Tools - Server Administration, далее кнопку Certifiers и в ее меню Register Organizational Unit ...
. Получаем окно для регистрации сертификатора оргединицы.
Рис. 8.12 Окно для регистрации сертификатора оргединицы
Кнопкой Certifer ID
выбираем ID-файл сертификатора, являющийся "родителем" для вновь создаваемого. Остальное похоже на создание ID-файла сертификатора организации... Кнопка Register создает ID-файл сертификатора оргединицы и документ Certifer со сведениями о сертификаторе оргединицы в адресной книге регистрационного сервера.
Рис. 8.13 Документ Certifier типа Notes Certifier содержит информацию о сертификаторе оргединицы
Отметим, что весь созданный набор ID-файлов иерархических сертификаторов должен сохраняться в безопасном месте и защищаться от несанкционированного использования. Пароли ID-файлов сертификаторов должны быть достаточно длинными, чтобы исключить возможность их подбора. Крайне желательно иметь несколько архивных копий этих файлов, чтобы исключить случайную потерю любого из них. Один из вариантов организации такого архива рассматривается в 9.6.
Создание реплики базы
Кто может создавать реплики баз на сервере? Не все, а только те, кто перечислен (явно или как член группы) в поле с меткой Create replica databases: документа Server из общей адресной книги.
Для создания реплики базы выберите из меню File - Replication - New Replica... Если перед этим на текущей закладке не была выбрана база, с которой необходимо создать реплику, появится диалоговое окно для выбора базы-оригинала. Выбор выполняется кнопкой Select.
Рис. 6.3 Оригинал можно выбрать и потом
Когда база-оригинал выбрана, вы получите диалоговое окно New Replica.
Рис. 6.4 Создание новой реплики
Укажите, где создается реплика: в поле Server - сервер или Local, в поле Title: - название, в поле File name: - имя файла. Выберите, как создавать реплику. Immediately - инициализировать и копировать базу сейчас. Такое может быть совершенно неприемлемо при создании реплик больших баз с сервера, доступ к которому возможен только по модему. Next scheduled replication - частично инициализировать базу (создать т.н. "окурок реплики" - "Replica Stub" размером в 176 Кб), предполагая при этом, что продолжение инициализации и копирование дизайна и документов состоится позже, при первой репликации. Выбор Copy Access Control List требует копировать в новую реплику ACL из оригинальной базы. Выбор Create full text index for searching требует создания для реплики индекса полнотекстового поиска.
Кнопка Encryption...
позволяет установить, кто сможет использовать создаваемую на локальном диске компьютера реплику. Если выбрано Do not locally encrypt this database, база может быть открыта локально даже без использования ID пользователя. В противном случае даже при локальном использовании базу сможет открыть только ее владелец, "предъявив" свой ID.
Рис. 6.5 Выбор локального шифрования для создаваемой реплики
Кнопка Size Limit...
позволяет ограничить максимально возможный размер создаваемой базы (1, 2, 3 или 4 Гб). Это именно максимально возможный размер - создаваемая база данных принципиально не сможет "разрастись" сверх этого размера. Для задания "практических" ограничений - "квот" на размер базы - используется иная последовательность действий:
File - Tools - Server Administration - кнопка Database Tools - выбор базы данных - выбор операции Quotas - выбор "практических" ограничений - кнопка Update.
Рис. 6.6 Ограничение максимального размера
Кнопка Replication Settings... позволяет выбрать репликационные установки для создаваемой базы. Они будут рассмотрены немного позже.
Созданная реплика будет иметь тот же идентификатор реплики, что и база, с которой реплика создана.
Еще раз напомним, что при копировании базы средствами Notes оригинал и копия будут иметь разные идентификаторы реплики. Но копия базы данных, выполненная средствами операционной системы, будет иметь тот же идентификатор реплики, что и оригинал, поскольку само значение идентификатора реплики хранится в файле базы. На практике в ряде случаев администраторы предпочитают создавать реплики баз именно путем их копирования как файлов. Однако во избежание возможных проблем, связанных с одновременной работой с файлом базы из нескольких приложений, рекомендуется перед созданием "физической копии" останавливать сервер Notes.
Создание шифруемых полей
Для шифрования полей в документе его форма должна иметь одно или более полей с атрибутом "шифруемые" (encryptable). Обычно разработчик базы данных присваивает этот атрибут - Enable encryption for this field - полям при проектировании формы.
Рис. 9.27. Окно свойств поля с установленным атрибутом "шифруемое"
В результате соответствующие поля в документах, созданных по этой форме, также "унаследуют" атрибут "шифруемое". Наконец, используя LotusScript, разработчик может присвоить этот атрибут полям непосредственно в создаваемом или существующем документе, не используя при этом форму.
Редактор на цветном мониторе может отличить шифруемые поля от обычных по красному цвету "полевых" скобок.
Обратите внимание на одну любопытную особенность шифруемых полей. Если документ с шифруемыми полями пытается прочитать пользователь, не имеющий нужного ключа шифрования, он "увидит" в зашифрованных полях формы значения, возвращаемые "формулами по умолчанию" этих полей, а не значения, хранящиеся в полях.
Информация из шифруемых полей, начиная с версий 4.х, уже может участвовать в полнотекстовом поиске. Но для этого в ID-файле сервера должны содержаться необходимые ключи шифрования.
Создание взаимных сертификатов
Взаимный сертификат (cross certificate) - документ, создаваемый иерархическим сертификатором, пользователем или сервером из одного дерева имен для иерархического сертификатора, пользователя или сервера из другого дерева имен. Документ необходим для того, чтобы в ходе выполнения процедуры аутентификации (8.3.2) удалось определить публичные ключи устанавливающих соединение сторон. Если же определить публичные ключи не удается, процедура аутентификации заканчивается неуспехом, в результате чего стороны обычно не предоставляют друг другу доступа.
Взаимный сертификат создается и хранится в адресной книге. Он называется "взаимным" потому, что и другая сторона симметрично должна создать и хранить в своей адресной книге взаимный сертификат для первой стороны. В процессе выполнения процедуры аутентификации каждая из сторон всегда использует взаимный сертификат из своей локальной адресной книги.
Рис. 8.29 Деревья имен компаний Acme и Omega
Для того чтобы создать взаимный сертификат, необходимо иметь имя и публичный ключ того субъекта (сертификатора, пользователя или сервера), для которого взаимный сертификат создается. Обычно источником имени и публичного ключа служит безопасная копия ID-файла этого субъекта. В ней содержится иерархический сертификат, который состоит из цепочки сертификатов-компонент, выданных сертификаторами из дерева имен организации, предоставившей безопасную копию. Следовательно, вам доступны как имя и публичный ключ самого субъекта, так и имена и публичные ключи всех его сертификаторов. И за вами право выбирать, для кого из них выпустить взаимный сертификат. Например, вы представляете компанию Omega, и вам была предоставлена безопасная копия ID-файла Alice/Sales/Acme. Если вы выпустите взаимный сертификат на Alice/Sales/Acme, ваша сторона в ходе процедуры аутентификации сможет определить только публичный ключ Alice/Sales/Acme. Если вы выпустите взаимный сертификат на /Sales/Acme, ваша сторона в ходе процедуры аутентификации сможет определить публичные ключи всех, кто в дереве имен ниже /Sales/Acme
(это SERVER1/Sales/Acme,
Alice/Sales/Acme, Bob/Sales/Acme и любые другие, кто появится там позже). Если вы выпустите взаимный сертификат на /Acme, ваша сторона в ходе процедуры аутентификации сможет определить публичные ключи всех, кто в дереве имен ниже /Acme (это все, как настоящие, так и будущие пользователи и серверы компании Acme).
Следующий вопрос - от чьего имени выпускать взаимный сертификат. Если вы просто пользователь, сертификат можно выпустить только от вашего имени. Тогда этим сертификатом сможет воспользоваться только ваша станция и никто другой более. Аналогично администратор сервера может выпустить взаимный сертификат от имени сервера. Тогда им сможет воспользоваться только этот сервер и никто другой. Если вы имеете ID-файл сертификатора, сертификат можно выпустить от его имени. Тогда этим сертификатом сможет воспользоваться любой пользователь или сервер, который в дереве имен вашей организации ниже выпустившего сертификат сертификатора. Единственная тонкость - сервер или станция всегда обращается за взаимным сертификатом к локальной адресной книге. Для сервера это общая адресная книга, для станции - персональная. Поэтому взаимный сертификат, выпущенный от имени сертификатора, обычно вначале помещают в общую адресную книгу, а затем копируют в персональные адресные книги тех пользователей, которым он действительно нужен. Если в нашем примере вы выпускаете взаимный сертификат от имени John/Marketing/Omega, им может воспользоваться только станция John/Marketing/Omega. Если вы выпускаете взаимный сертификат от имени /Marketing/Omega, им смогут воспользоваться все, кто в дереве имен ниже /Marketing/Omega (в нашем примере пока только John/Marketing/Omega и Mary/Marketing/Omega). Если вы выпускаете взаимный сертификат от имени /Omega, им смогут воспользоваться все, кто в дереве имен ниже /Omega (в данном примере пока только
John/Marketing/Omega, Mary/Marketing/Omega и SERVER3/Marketing/Omega).
Рассмотрим все возможные варианты
взаимного сертификата, которые вы, как представитель компании Omega, могли бы выпустить.
· От имени John/Marketing/Omega для Alice/Sales/Acme
- позволяет только станции John/Marketing/ Omega определять публичный ключ станции Alice/Sales/Acme. С точки зрения установления соединений совершенно бесполезен, поскольку станция не может соединяться со станцией. Однако может использоваться для того, чтобы станция John/Marketing/Omega могла проверять "электронную подпись" Alice/Sales/Acme.
· От имени John/Marketing/Omega для /Sales/Acme
- позволяет только станции John/Marketing/Omega определять публичный ключ любого из дерева имен компании Acme ниже /Sales/Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega потому, что может обеспечить ему доступ к серверу SERVER1/Sales/Acme
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени John/Marketing/Omega для /Acme
- позволяет только станции John/Marketing/Omega определять публичный ключ любого из дерева имен компании Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega потому, что может обеспечить ему доступ к серверам SERVER1/Sales/Acme и SERVER2/Development/Acme
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Marketing/Omega для Alice/Sales/Acme
- позволяет станциям John/Marketing/Omega и Mary/Marketing/Omega определять публичный ключ станции Alice/Sales/Acme. С точки зрения установления соединений совершенно бесполезен, поскольку станция не может соединяться со станцией. Может использоваться для того, чтобы станции John/Marketing/Omega и Mary/Marketing/Omega могли проверять "электронную подпись" Alice/Sales/Acme.
· От имени /Marketing/Omega для /Sales/Acme
- позволяет станциям John/Marketing/Omega и Mary/Marketing/Omega определять публичный ключ любого из дерева имен компании Acme ниже /Sales/Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega и Mary/Marketing/Omega потому, что может обеспечить им доступ к серверу SERVER1/Sales/Acme (если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Marketing/Omega для /Acme
- позволяет станциям John/Marketing/Omega и Mary/Marketing/ Omega определять публичный ключ любого из дерева имен компании Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega и Mary/Marketing/Omega потому, что может обеспечить им доступ к серверам SERVER1/Sales/Acme и SERVER2/Development/Acme
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Omega для Alice/Sales/Acme - позволяет всем из компании Omega определять публичный ключ станции Alice/Sales/Acme. С точки зрения установления соединений представляет интерес для Alice/Sales/Acme
потому, что может обеспечить ей доступ к серверу SERVER3/Omega
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Omega для /Sales/Acme - позволяет всем из компании Omega определять публичный ключ любого из дерева имен компании Acme ниже /Sales/Acme. С точки зрения установления соединений представляет интерес для John/Marketing/Omega и Mary/Marketing/Omega потому, что может обеспечить им доступ к серверу SERVER1/Sales/Acme (если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений). С той же точки зрения представляет интерес для Alice/Sales/Acme, Bob/Sales/Acme
и SERVER1/Sales/Acme
потому, что может обеспечить им доступ к серверу SERVER3/Omega
(если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
· От имени /Omega для /Acme - позволяет всем из компании Omega определять публичный ключ любого из дерева имен компании Acme. С точки зрения установления соединений представляет интерес для всех пользователей и серверов из обеих компаний, поскольку может обеспечить им доступ к серверам в другой компании (если на другой стороне тоже имеется необходимый взаимный сертификат и нет иных ограничений).
Однако мы рассмотрели только одну половину вопроса. Чтобы процедура аутентификации при установлении соединений завершалась успешно, в компании Acme "зеркально симметрично" тоже должен быть выпущен хотя бы один взаимный сертификат от имени кого-то из компании Acme для кого-то из компании Omega. И вариантов здесь будет не меньше, чем было рассмотрено для компании Omega.
Далее можно было бы рассмотреть всевозможные пары из возможных взаимных сертификатов двух компаний. Ограничимся лишь несколькими вариантами.
· Omega: от имени John/Marketing/Omega для /Sales/Acme.
Acme: от имени SERVER1/Sales/Acme
для John/Marketing/Omega.
Позволяет только John/Marketing/Omega иметь доступ только к серверу SERVER1/Sales/Acme. Если в Acme
появится сервер с именем SERVER4/Sales/Acme, John/Marketing/Omega не будет иметь к нему доступа.
· Omega: от имени John/Marketing/Omega для /Sales/Acme.
Acme: от имени /Sales/Acme
для John/Marketing/Omega.
Позволяет только John/Marketing/Omega иметь доступ только к серверу SERVER1/Sales/Acme. Если в Acme
появится сервер с именем SERVER4/Sales/Acme, John/Marketing/Omega тоже будет иметь к нему доступ.
· Omega: от имени /Marketing/Omega для /Sales/Acme.
Acme: от имени /Sales/Acme
для /Marketing/Omega.
Позволяет только John/Marketing/Omega и Mary/Marketing/Omega иметь доступ только к серверу SERVER1/Sales/Acme. Если в Acme
появится сервер с именем SERVER4/Sales/Acme, John и Mary
тоже будет иметь к нему доступ. Если в Omega появится сервер с именем SERVER5/Marketing/Omega, он будет иметь доступ к серверу SERVER1/Sales/Acme. С другой стороны Alice, Bob и SERVER1 тоже будут иметь доступ к SERVER5/Marketing/Omega.
· Omega: от имени /Omega для /Acme.
Acme: от имени /Acme
для /Omega.
Все пользователи и серверы одной компании имеют доступ ко всем серверам в другой компании. Все новые пользователи и серверы так же автоматически обладают таким доступом.
Список управления доступом к базе (ACL)
Каждая база Notes имеет список управления доступом (Access Control List, ACL), определяющий, какие пользователи, группы пользователей, и серверы могут иметь к ней доступ и какие задачи в этой базе они могут исполнять.
ACL включает две компоненты:
· список элементов ACL, каждый из которых содержит имя субъекта (пользователя, сервера или группы), его уровень доступа к базе и дополнительные свойства;
· список ролей вместе с назначением субъектов на роли.
Список управления доступом создается при создании базы и далее ведется менеджером базы данных в диалоговом окне, получаемом из меню File - Database - Access control....
Если имя пользователя или сервера не внесено в ACL базы данных явно или как члена группы, считается, что он - -Default-.
В Notes используется семь уровней доступа.
(Менеджер) может выполнять все возможные действия в базе данных - чтение, запись, редактирование документов, создание, модификация и удаление элементов дизайна (форм, видов, агентов…). Менеджер, в отличие от более низких уровней доступа, может также изменять ACL, настройки репликаций, установки локального шифрования базы и удалять базу данных. База данных всегда имеет по крайней мере одного менеджера.
Рис. 9.6. Список управления доступом - закладка Basics
(Дизайнер), в отличие от более низких уровней доступа, может создавать, модифицировать и удалять элементы дизайна (поля, формы, виды, общих агентов…), модифицировать репликационные формулы базы, создавать индекс полнотекстового поиска. И, конечно, выполнять те же самые действия, что и субъекты с более низким уровнем доступа
(Редактор) может читать, создавать и редактировать все документы в базе данных (в том числе и созданные другими пользователями), но не может изменить элементы дизайна, ACL и прочие атрибуты, присущие более высоким уровням доступа.
(Автор) может читать существующие документы и создать новые, но может редактировать только созданные им документы (но не другими).
(Читатель) может читать документы, но не может добавлять новые или редактировать существующие.
(Депозитор) может добавлять новые документы, но не может читать существующие, потому что попросту "не видит" их в видах базы.
No Access (Нет доступа). Пользователь не может открыть базу данных.
Кроме того, для каждого уровня доступа имеется свой собственный набор дополнительных флагов, уточняющих возможности на уровне. Ниже приведены все возможные флаги, но без учета уровня доступа, для которого они имеют смысл:
· Create documents - может создавать документы;
· Delete documents - может удалять документы;
· Create personal agents - может создавать личных агентов;
· Create personal folders/views - может создавать личные виды и папки;
· Create shared folders/views - может создавать общие виды и папки;
· Create LotusScript Agents - может создавать агентов на LotusScript;
· Read public documents - может читать общедоступные документы;
· Write public documents - может создавать общедоступные документы.
Из большого количества связанных с доступом комбинаций обратим ваше внимание на два момента. Во-первых, менеджер может "разрешить" читателю создавать личных агентов. А читатель может создать агента, который удаляет все документы в базе. Читатель может даже запустить этого агента. Но агент не сможет удалить документы в базе, поскольку "его читательского доступа" недостаточно для выполнения этой операции. Во-вторых, начиная с версии 4.5 даже пользователь с уровнем доступа No Access может быть "наделен возможностью" читать и (или) создавать в базе данных т.н. общедоступные документы. Чтобы эта возможность функционировала, разработчик базы должен создать в ней одну или несколько форм со свойством Available to Public Access users и полем (обычно, "невидимым") с предопределенным именем $PublicAccess типа Text и значением "1". Кроме того, обычно создаются и виды или папки, имеющие свойство Available to Public Access users, и содержащие общедоступные документы.
Группы - списки пользователей, серверов или других групп, создаваемые администратором в общей адресной книге. При использовании групп действуют следующие соглашения:
· если пользователь фигурирует в ACL и как член группы, и как физическое лицо, он получает права доступа физического лица, даже если права группы предоставляют ему больший уровень доступа;
· если пользователь - член двух групп в ACL - он получает права доступа группы с большим уровнем доступа.
Роли доступа используются для управления доступом пользователей или групп к определенным формам, видам или агентам в базе данных.
Рис. 9.7. Список управления доступом - закладка Roles
Дизайнер может предусмотреть при создании некоторых форм, видов или агентов, что доступ к ним должны иметь только те лица, которых впоследствии менеджер базы назначит на эту роль, а не все имеющие необходимый уровень доступа в ACL. Дизайнер (обычно при разработке базы он имеет и права менеджера) добавляет названия ролей в ACL базы. Например, [FormReadAccess] (к сожалению, название роли не "длиннее" 15 символов). Затем он использует эти названия ролей при определении доступа к некоторым формам или видам. При разработке агентов на LotusScript соответствующая проверка, назначен или нет запустивший агента пользователь на роль, выполняется в самом агенте. Если пользователь не назначен на роль, агент попросту не выполняет своего действия.
Менеджер базы впоследствии назначает (на закладке Basics щелчком мыши по названию роли при "выбранном" субъекте) на эту роль пользователей базы из числа имеющихся в ACL. Выполняемые менеджером изменения в списках назначенных на роль не требуют изменения доступа в использующих эту роль формах, видах и агентах. Только назначенные на роль смогут воспользоваться использующими роли формами, видами и агентами - простого присутствия в ACL недостаточно.
На закладке Log содержится информация о том, кто, когда и что изменял в ACL базы.
Рис. 9.8 Список управления доступом - закладка Log
На последней закладке, во-первых, можно задать для базы сервер администрирования и уточнить, должна ли серверная задача Administration Process вносить изменения в поля типа Readers и Authors при операциях изменения имен или удаления пользователей. Однако это уже рассматривалось в 3.2.14.
Во-вторых, менеджер базы данных может обеспечить, чтобы список управления доступа (ACL) оставался тем же самым во всех репликах базы. Для этого менеджер на закладке Advanced выбирает опцию Enforce a consistent Access Control List across all replica copies of this database ("предписать непротиворечивый список управления доступом во всех репликах этой базы данных"). Выбор этой опции не только гарантирует, что ACL будет оставаться одинаковой во всех репликах базы на серверах, но и то, что ACL будет оставаться одинаковой и будет функционировать в репликах на станциях пользователей. Если же эта опция не выбрана, пользователи имеют доступ менеджера к своим локальным репликам, а следовательно, могут менять их ACL, даже если в реплике на сервере они не имеют такого уровня доступа, хотя такие локальные изменения в ACL не поступают в реплику на сервере.
Рис. 9.9 Список управления доступом - закладка Advanced
Поддержка ACL в репликах на станциях тем не менее не является настоящим средством защиты, если вы физически не гарантируете безопасность станции или не применяете локального шифрования. Во-первых, зная имя группы, использованное в ACL, всегда можно создать группу с таким именем и включить в ее состав пользователя, которому необходим доступ. Во-вторых, зная полное имя пользователя, фигурирующего в ACL, можно создать новый ID-файл с таким именем (но, конечно, другими ключами) и получить "под ним" доступ к базе. Кроме того, серверные add-in - программы могут "обходить" список управления доступа, предписанный для локальных реплик.
Чтобы обеспечить распространение репликационных установок во все реплики базы на других серверах, следует выбрать данную опцию в реплике на том сервере, который имеет доступ менеджера во всех других серверных репликах, иначе репликация будет неудачной - сервер не сможет изменить ACL в репликах базы на других серверах. В сообщениях о неудаче репликации по этой причине вы встретите слова "inconsistent ACL".
В-третьих, в Notes версий 4. 5 появилась возможность указать максимальный уровень доступа к этой базе с использованием Web-броузера. На сервере Notes такой доступ поддерживает серверная задача HTTP, рассматриваемая в 10.2.
В-четвертых, кнопка Look Up User Types for "Unspecified" Users обеспечивает проверку фигурирующих в ACL имен по адресной книге и конкретизацию их типа: Person, Server, Person Group, Server Group, Mixed Group. Нажмите кнопку и вернитесь на первую закладку - в типах имен могут произойти изменения. Для чего это необходимо? Например, администратор сервера может запустить на сервере станцию Notes и работать под ID сервера с базой, если в ACL для имени сервера задан тип Unspecified. Но он не сможет этого сделать, если в ACL для имени сервера задан тип Server.
Как выяснить, чем определяется доступ пользователя к базе данных
Чтобы выяснить, что именно (например, какая группа) определяет уровень доступа пользователя к базе данных, "нажмите мышью" пиктограмму уровня доступа в строке состояния в нижней части окна рабочей области.
Рис. 9.10 К этой базе пользователь Nikolay N. Iontsev/InterTrustCorp/SU получает доступ менеджера как член группы Administrators
В появившемся диалоговом окне содержатся:
· все группы из адресной книги, членом которых является пользователь;
· шаблоны имен, которым удовлетворяет имя пользователя;
· роли, на которые пользователь назначен (они заключены в скобки []).
Галочкой отмечены те имена, на основании которых станция "принимает решение" о предоставлении пользователю его уровня доступа.
Такая возможность работает для баз на серверах и локальных баз, для которых выбрана опция Enforce a consistent Access Control List across all replicas of this database.
Список управления выполнением (ECL)
У этой возможности, окончательно оформившейся в только версии 4.5, длительная и любопытная предыстория.
Начнем с того, что при использовании любой почтовой системы имеется риск получить в письме присоединенный файл, содержащий выполняемую программу или интерпретируемый приложением компьютера получателя код. "Поспешное" выполнение этого файла на компьютере получателя может привести к "заражению компьютера вирусом" (исполняемая программа-вирусоноситель или интерпретируемый код-вирусоноситель, наподобие макровирусов в Microsoft Word или Microsoft Exel) или прямому причинению ущерба (исполняемая программа или интерпретируемый код типа "троянский конь").
Аналогичная ситуация наблюдается в большинстве систем "клиент-сервер", когда на компьютере клиента запускается полученный с сервера интерпретируемый код или исполняемая программа. Разница лишь в "степени доверия" к их разработчику (обычно она выше, чем при использовании почты) и "степени легкости запуска" (часто запуск выполняется даже без уведомления об этом пользователя).
Lotus Notes этих вопросах не является исключением, причем создание "троянских коней" возможно средствами самого Notes. В простейшем случае это кнопка или "горячая площадка" в любом поле типа Rich Text любого документа, например, в поле Body ("тело сообщения") стандартной почтовой формы. Нажатие такой кнопки или "щелчок мышью по горячей площадке" запускают связанные с этим объектом @-формулы или подпрограмму на LotusScript. Нет сомнений, что это очень полезная для разработки ряда приложений или просто документов возможность. Но эта же возможность может использоваться и для выполнения "совсем не ожидаемых" пользователем действий. Например, даже с использованием @-функций несложно написать @-формулу, которая получит из почтового ящика пользователя-получателя список всех его корреспондентов, и каждому из них, уже от имени "неосторожного" получателя, отправит письмо с точно такой же кнопкой. А классифицировать такую @-формулу приходится как почтовый вирус, ибо признаки размножения, хотя и требующие участия человека, у него имеются. Другим вариантом создания подобных "троянских коней" является форма, встроенная в документ. В ней содержится множество мест, в которые могут быть встроены @-формулы или подпрограммы на LotusScript
(скрипты), автоматически запускаемые в момент открытия пользователем такого документа. Третий вариант, доступный однако лишь разработчикам используемых в организации баз, не требует поиска "тонких мест" продукта - это обычные элементы дизайна базы: формы, агенты...
Разработчики Lotus Notes всегда знали о существовании подобных эффектов и по мере возможности занимались созданием средств борьбы с ними. В Notes версий 3.х при анализе различных типов @-формул прослеживается политика запретов на потенциально опасные действия. Факты создания пользователями "троянских коней", основанных на встроенных в поле типа Rich Text кнопках, отмечены в базе знаний по Notes (Lotus Notes Knowledge Base) еще в 1993-1994 годах. Возможность создания "троянских коней" на базе встроенной в документ формы также была известна разработчикам Lotus Notes, хотя об этом и не упоминалось в базе знаний по продукту. Но с появлением в Notes версии 4.0 языка LotusScript
придерживаться политики запретов стало невозможно, поскольку иначе была бы потеряна вся мощь языка и его встроенных классов. Требовался механизм доверия, основанный на "личной электронной подписи" создателя содержащего скрипты и @-формулы элемента дизайна или документа и позволяющий перед любым выполнением скриптов или @-формул этого элемента дизайна или документа проверять потенциальные способности его кода и априорный уровень доверия к его создателю. Однако, можно предположить, что из-за недостатка времени, версия Notes 4.0 появляется на рынок с применением такого механизма только при запуске агентов на сервере. В версии Notes 4.1 в свойства базы добавляется опция, разрешающая или запрещающая сохранять в ней документы с формой, встроенной в документ. При попытке открыть документ с встроенной формой пользователь предупреждается о потенциальной опасности, может отказаться от открытия и в меру возможностей исследовать вызывающий подозрение документ, в том числе и в пошаговом отладчике. Наконец, в Notes версии 4.5 вводится список управления выполнением (Execution Control List, ECL) на станции Notes.
Окно списка управления выполнением может быть получено выбором в меню File-Tools-User Preferences с последующим нажатием кнопки Seсurity
Options на закладке Basics.
Рис. 9.14 Окно списка управления выполнением станции
В левой части окна присутствует список тех, кем может быть "подписан" элемент дизайна или документ (When signed by:). В этот список могут быть добавлены полные имена разработчиков дизайна или шаблоны их имен, например, */InterTrustCorp/SU. Все элементы дизайна шаблонов баз, созданных самими разработчиками Lotus Notes, "подписываются" именем Lotus Notes Template Development/Lotus Notes. Предопределенное имя -No Signature- применяется для обозначения "неподписанных" элементов дизайна или документов. Наконец, предопределенное имя -Default- используется для обозначения "подписанных" элементов дизайна или документов, когда "подписавшее" его лицо не входит в заданный список.
В правой части окна (Allow:) для каждого имени или шаблона имен из списка перечисляются возможности, которые "разрешены" для скриптов и @-формул, имеющихся в элементах дизайна и документах, "подписанных этим именем":
· Access to the file system - возможность присоединять и отсоединять файлы в/из полей типа Rich Text, возможность читать и записывать файлы в каталогах компьютера станции;
· Access to current database - возможность читать или модифицировать информацию в текущей базе;
· Access to environment variables - возможность читать или модифицировать значения переменных из файла NOTES.INI станции функциями @SetEnvironment и @GetEnvironment или аналогичными методами LotusScript;
· Access to non-Notes databases - возможность читать информацию из баз данных "не Notes" форматов функциями @DBLookup, @DBColumn и @DBCommand;
· Access to external code - возможность вызывать методы классов и функции из библиотек динамической компоновки, не входящих в поставку Notes;
· Access to external programs - возможность запуска и работы с другими приложениями, включая активизацию любых OLE-объектов;
· Ability to send mail
- способность отправлять почту @-функциями, например, @MailSend, и методами встроенных классов;
· Ability to read other databases - способность читать информацию из других баз данных, но не из текущей базы;
· Ability to modify other databases - способность изменять информацию в других базах данных, но не в текущей базе;
· Ability to export data - способность выводить на принтер, копировать в буфер обмена, экспортировать и импортировать данные;
· Access to Workstation Security ECL - возможность изменять список управления выполнением (ECL) станции.
В принципе право ведения списка управления выполнением предоставлено пользователю станции. По умолчанию установки в ECL станции таковы, что всем предоставлены все возможности, а это потенциально опасно.
Однако администратор домена может осуществлять централизованное управление списками управления выполнением станций. Для этого администратор из общей адресной книги выбирает в меню Action - Edit Administration ECL и получает окно (Рис. 9.15), лишь немногим отличающееся от аналогичного окна на станции. Выполненные администратором в этом окне и сохраненные в общей адресной книге установки ECL для краткости будем называть "ECL домена". Отличие же окон состоит в возможности разрешить или не разрешить пользователям изменять скопированную на станцию ECL домена.
В процессе установки рабочих станций пользователей ECL домена автоматически копируется в ECL станции. После того, как администратор внесет очередные изменения в ECL домена, чтобы эти изменения поступили в ECL уже установленных станций, администратору необходимо отправить пользователям домена письмо с кнопкой, имеющей формулу @RefreshECL("";"").
Рис. 9.15 Окно списка управления выполнением для домена
Рис. 9.16 Средство для "массового подписывания" элементов дизайна баз
Остается отметить, что в руководстве администратора Notes версий 4.5 упоминается об утилите SIGNNSF.EXE, предназначенной для того, чтобы "в массовом порядке подписывать" элементы дизайна баз и шаблонов, используемых в организации. Такой утилиты в Notes версий 4.5 и 4.51 нет.
Однако в Notes версии 4.51 возложенные на утилиту функции включены в окно Tools to Manage Notes Databases, "вызываемое" из окна Server Administration кнопкой Database Tools. Средство применяется для расположенных локально баз данных или шаблонов. Для шаблонов приходится ввести имя файла шаблона. Для баз данных, находящихся на сервере, следует пользоваться этим средством из программы станции, запущенной на компьютере сервера. В качестве ID-файла, "именем которого подписываются" базы и шаблоны, используется текущий ID-файл станции. Могут быть "подписаны" все элементы дизайна (если поле NoteID пусто) или только избранные (в поле NoteID задается идентификатор местоположения элемента дизайна, наподобие NT0000011A). Определить идентификатор местоположения можно в окне свойств элемента дизайна - это последняя компонента в "полном" идентификаторе элемента дизайна. Если выбрана опция Update existing signatures only, "подписываются" только ранее "подписанные" элементы дизайна.
Сравнение схем Pull-Push и Pull-Pull
В широко распространенной конфигурации "hub-spoke" имеется один или несколько серверов, которые являются "поставщиками данных" (hub-серверы), и много серверов, которые занимаются в основном приемом "заказанных ими" данных с hub-серверов, хотя могут также передавать данные на hub-серверы (это spoke-серверы).
Преимущества схемы Pull-Push по сравнению с Pull-Pull
При использовании репликаций по схеме Pull-Push существенно упрощается администрирование hub-серверов:
· администратор hub-сервера не планирует связь с каждым spoke-сервером;
· репликатор hub-сервера не вовлечен в репликационные события, инициированные spoke-серверами, тогда как многие spoke-серверы могут одновременно реплицировать данные с hub-сервера.
Схема Pull-Push обычно позволяет более быстро завершить репликационный цикл, т.е. выполнить репликации между hub-сервером и каждым из его серверов-"собеседников" (spoke). При репликациях по схеме Pull-Pull "собеседник" принимает изменения с hub-сервера, а затем репликатор hub-сервера принимает изменения от spoke-сервера. Но в этом случае hub-сервер каждым своим репликатором одновременно может принимать изменения только от одного из "собеседников". При использовании схемы Pull-Push многие spoke-серверы могут одновременно принимать изменения с hub-сервера и "заталкивать" их на hub-сервер.
Недостатки схемы Pull-Push по сравнению с Pull-Pull
Документы Connection будут находиться на разных spoke-серверах. Если таких серверов много и они из разных доменов, может оказаться организационно трудно составить "равномерное" расписание, если только на hub-сервере не имеются реплики адресных книг всех участвующих в репликациях доменов.
Hub-сервер не будет иметь информации о репликационных событиях в своем протоколе работы (LOG.NSF) - с "его точки зрения" имеет место лишь доступ к находящимся на нем базам. Для анализа возможных проблем в конфигурации "hub-spoke" администратор hub-сервера будет вынужден просмотреть большее количество протоколов работы spoke-серверов, чем в случае репликаций по схеме Pull-Pull.
Средства мониторинга серверов Notes
Средства мониторинга позволяют собирать информацию о работе сервера или группы серверов (в пределах одного или нескольких доменов), чтобы помочь администратору в управлении, обнаружении неисправностей и обоснованном планировании расширения всей системы.
Логически они включают 3 компоненты:
· Statistics/Alarm Reporter - система сбора статистики и генерации тревог
· Еvent Logger
- система протоколирования событий
· Database Monitor
- система наблюдения за базами данных.
Конструктивно эти средства представлены двумя серверными задачами и двумя базами данных:
· Report - Reporter - задача сбора с заданным интервалом статистики о работе сервера, создания по ней сводных отчетов и доставки статистики и отчетов в базу сбора статистики;
· Event - задача отбора из стандартной очереди событий заданного типа и степени серьезности и протоколирования их заданным способом;
·
- база для управления функционированием всей системы мониторинга серверов (реплика на каждом сервере);
·
Установка средств мониторинга серверов трудностей не вызывает: достаточно с консоли сервера командами Load Report и Load Event запустить обе задачи. Задача Report при первом запуске:
· создает базу STATREP.NSF, если она еще не существует
(по шаблону STATREP.NTF или STATRP45.NTF
с версии 4.5);
· создает базу EVENTS4.NSF, если она еще не существует;
· создает документ Mail-in Database в общей адресной книге.
Задача Event при первом запуске:
· создает базу STATREP.NSF, если она еще не существует;
· создает базу EVENTS4.NSF, если она еще не существует;
· копирует в базу EVENTS4.NSF из общей адресной книги документы ACL Monitor, Replication Monitor, Event и Statistics Monitoring, а также связанные с ними виды (эти документы могли иметься в общей адресной книге, если на сервере, ранее функционировавшем под Notes версий 3.х, были установлены средства мониторинга);
· копирует в базу EVENTS4.NSF из общей адресной книги документ Server данного сервера и преобразует его в документ Servers to Monitor.
Однако настройка и использование средств мониторинга сложнее, чем их установка.
Statistics/Alarm Reporter - система сбора статистики и генерации тревог
Когда на сервере запускается задача Report, она проверяет в базе Statistics & Events наличие документа Server To Monitor и далее использует в своей работе информацию из этого документа. Первоначально документ Server To Monitor создается при первом запуске задачи Event - посредством копирования документа Server из общей адресной книги с добавлением в него некоторых полей со значениями по умолчанию. Впоследствии администратор может модифицировать этот документ или создать вместо него новый.
Рис. 11.1 Пример документа Server To Monitor
В документе задается интервал сбора статистики - поле с меткой Collection interval... - по умолчанию 60 минут, но может варьироваться от 15 до 1440 минут. Кроме того, задается интервал, с которым по документам, содержащим "разовую статистику", создается сводный отчет - поле с меткой Analysis interval:. Поле с меткой Server name: содержит имя сервера, с которого задача Report "снимает статистику". Поле с меткой Report method: определяет способ, которым задача Report должна доставлять статистику в базу сбора (обычно STATREP.NSF). Возможны два варианта:
· Log to Database - протоколирование в базу - задача записывает документ, содержащий статистику, непосредственно в базу сбора;
· Mail-In Database - задача отправляет документ почтой Notes по адресу почтовой базы сбора статистики.
В случае Log to Database, если база сбора статистики находится на сервере получения статистики, в поле с меткой Enter server name: следует выбрать Local - тогда задача будет записывать информацию непосредственно в базу, имя файла которой указано в поле с меткой Database to receive reports:. Если же база сбора статистики находится на другом сервере, но в той же поименованной сети Notes, что и сервер получения статистики, следует указать имя этого сервера. В случае разных поименованных сетей такой способ невозможен - приходится отправлять статистику почтой
по адресу, содержащемуся в вычисляемом поле с меткой Mail- in database address to receive reports:.
При первом запуске задачи Report в общей адресной книге создается документ Mail-In Database, "провозглашающий" созданную этой же задачей базу STATREP.NSF как базу, имеющую собственный почтовый адрес и способную принимать почту. Формат адреса: имя_сервера Statistics/имя_организации. Однако, поскольку база сбора первоначально находится на сервере получения статистики, по умолчанию статистика доставляется в нее способом протоколирования в локальную базу.
Обратите внимание, что все серверы домена, с которых собирается статистика, "несут" реплику базы EVENTS4.NSF. В то же время база STATREP.NSF не обязательно должна присутствовать на каждом из серверов домена - обычно она присутствует только на сервере сбора статистики. Если статистика должна собираться для группы серверов, включая данный, в базе сбора, расположенной на другом сервере, администратору следует удалить STATREP.NSF на данном сервере. Далее, следует оставить в адресной книге только те документы Mail-In Database, которые относятся к серверам, находящимся в разных поименованных сетях с сервером сбора статистики, согласовав в них местонахождение базы сбора статистики. Позвольте напомнить, что понятие "поименованная сеть" определено в пределах одного домена, и, следовательно, в случае разных доменов приходится использовать доставку почтой. Наконец, нужно обеспечить в документах Server to Monitor или правильный почтовый адрес базы STATREP.NSF, или правильный способ протоколирования в эту базу.
В результате задача Report начинает с заданным интервалом создавать в базе сбора статистики документы формы Statistics Report, содержащие весьма подробную информацию о состоянии сервера на момент сбора статистики. Эти документы представлены в группе видов 1. Statistics Reports... базы STATREP.NSF.
Рис. 11.2 Вид в базе STATREP.NSF, содержащий статистику о работе сервера
Ниже приведен пример одного из таких документов. Обратите внимание, что на самом деле там представлена не вся информация из документа Statistics Report. Как видно из Рис. 11.2, в базе имеется пять видов, в каждом из которых один и тот же документ Statistics Report "отображается" по разной форме, с представлением информации из тех или иных групп полей.
Data file path: f:\notes400\data
Swap file path: Not Applicable
Number of processors: 1
Processor type: Intel Pentium
Server Load Statistics:
Transactions in last minute: 8
Peak transactions per minute: 1 413
Time of last peak transactions per minute: 30.01.97 11:37:13
Total transactions processed: 15 118
Number of current users: 12
Peak number of users: 13
Time of last peak number of users: 30.01.97 13:22:26
Number of sessions dropped in mid-transaction: 0
Number of server tasks: 19
Server Tasks:
Database Server: Perform console commands
Database Server: Listen for connect requests on TCPIP
Database Server: Listen for connect requests on LAN4
Database Server: NetBIOS name server for LAN4
Database Server: Cluster Manager is idle
Database Server: Perform housekeeping chores
Database Server: Idle task
Database Server: Server for Andre A. Linev/InterTrustCorp/SU on LAN4
Database Server: Server for InterTrust/InterTrustCorp/SU on TCPIP
Database Server: Server for Vladimir A. Panov/InterTrustCorp/SU on TCPIP
Database Server: Server for Oleg G. Taranchenko/InterTrustCorp/SU on LAN
Database Server: Server for session B87000E on TCPIP
Database Server: Server for Nikolay N. Iontsev/InterTrustCorp/SU on TCPI
Database Server: Server for Oleg G. Taranchenko/InterTrustCorp/SU on LAN
Database Server: Server for InterTrust/InterTrustCorp/SU on TCPIP
Database Server: Server for Vladimir A. Panov/InterTrustCorp/SU on LAN4
Database Server: Server for NotesSrv400/InterTrustCorp/SU on TCPIP
Database Server: Server for Pavel A. Puchkov/InterTrustCorp/SU on LAN4
Database Server: Server for Alexander M. Savelyev/InterTrustCorp/SU on T
HTTP Web Server: Ready
Indexer: Updating views in mail\ALinev.nsf
SMTPMTA oseshlr0: Idle
WEB Retriever: Process(3): Idle
WEB Retriever: Process(2): Idle
SMTPMTA iseshlr0: Idle
SMTPMTA drt: Idle
SMTPMTA isesctl: Listening on SMTP port 25
SMTPMTA imsgcnv: Idle
SMTPMTA osesctl: Idle
Cluster Replicator: Idle
SMTPMTA omsgcnv: Idle
Event: Idle
Cluster Directory: Idle
Query/Set Handler: Idle
Reflector Agent: Idle
SMTPMTA: Idle
Cluster Directory: Idle
Cluster Replicator: Idle
WEB Retriever: Process(1): Idle
Reporter: Idle
Calendar Connector: Idle
Schedule Manager: Idle
Admin Process: Idle
Agent Manager: Executive '1': Idle
Agent Manager: Idle
Indexer: Updating cldbdir.nsf view '($Pathname)'
Router: Idle
Replicator: Idle
Replicator: Idle
Event Interceptor: Idle
Replication Statistics:
Number of successful replications: 278
Number of replication failures: 133
Number of documents deleted: 357
Number of documents added: 1 065
Number of documents updated: 870
Database Statistics (in bytes):
Buffer control pool used: 91 204
Buffer control pool peak size: 196 218
Buffer pool maximum: 6 291 456
Buffer pool used: 6 264 804
Buffer pool peak: 6 336 000
Extension manager pool used:
Extension manager pool peak:
NSF pool used: 176 468
NSF pool Peak: 327 030
Stats Package Statistics:
Time started: 30.01.97 09:36:37
Agent Statistics:
Hourly agent scheduled runs: 0
Hourly agent triggered runs: 1
Hourly agent unsuccessful runs:
Hourly agent used run time: 13 Seconds
Hourly agent access denials: 0
Daily agent scheduled runs:
Daily agent triggered runs:
Daily agent unsuccessful runs:
Daily agent used run time:
Daily agent access denials:
Хотя в базе STATREP.NSF имеются и другие виды, в том числе "пытающиеся" представить все получаемое "море" информации в псевдографическом виде, всю информацию проанализировать трудно, да и это попросту ненужно.
Вы можете предварительно описать только ситуации, которые действительно достойны вашего внимания - "ситуации, вызывающие тревогу". Для этого в базе Statistics & Events создаются документы Statistic Monitor.
Рис. 11.3 Пример документа Statistics Monitor для контроля свободного пространства на диске
В документе Statistic Monitor содержится следующее.
· Enabled/Disabled:
-
задаче Report разрешено/запрещено "интерпретировать" этот документ.
· Server name:
- имя сервера или список имен серверов, на которые распространяется действие документа.
· Statistic name: - название параметра, значение которого рассматривается при решении вопроса о возникновении тревоги. Эти названия выбираются из списка ключевых слов, который строится по формуле @DbColumn(""; ""; "($Statistics)"; 1) из скрытого вида ($Statistics). Для понимания смысла параметров лучше просмотреть виды 5. Names & Messages\Thresholds и 5. Names & Messages\Statistics Names и, для заинтересовавших вас параметров, соответствующие документы из этих видов.
· Threshold operator: - операция, выполняемая при проверке значения параметра - Less that - меньше чем, Greater that - больше чем, Multiple of - кратно.
· Threshold value: - значение, с которым сравнивается значение параметра.
· Event severity:
- степень серьезности события типа Statistics, возникающего при выполнении условия.
· Comments:
и Description: комментарии и описание - вычисляемые поля. Они пересчитываются по нажатию клавиши F9 или при сохранении документа.
Рис. 11.4 Пример документа Statistics Monitor для контроля наличия "мертвой" почты
Рис. 11.5 В виде представлены все ситуации, "вызывающие тревогу"
Например, согласно документу Statistic Monitor на Рис. 11.3 ситуация, "вызывающая тревогу", возникает, если на диске F
заданного сервера стало меньше 40 Мб свободного пространства. Согласно документу на Рис. 11.4 ситуация, "вызывающая тревогу", возникает, когда на одном из серверов в базе MAIL.BOX появилась "мертвая" почта.
Все, что вы определили, как ситуации, "вызывающие тревогу", будет представлено в виде 3. Statistic\Monitors базы Statistics & Events (Рис. 11.5).
В соответствии с выполненными настройками задача Report при обнаружении "тревожных ситуаций" будет генерировать события типа Statistics заданной степени серьезности. Эти события будут поступать в стандартную очередь событий сервера. Что происходит далее? Задача Event анализирует стандартную очередь событий, отбирает те из них, на которые "ей предписано реагировать", и соответствующим образом протоколирует их. События типа Statistics
обычно протоколируются в базу сбора статистики. В итоге в виде Alarms
базы STATREP.NSF (Рис. 11.6) при возникновении "тревожных ситуаций" станут появляться документы
Alarm (Рис. 11.7).
Рис. 11.6 Вид Alarms содержит документы, описывающие события, "вызвавшие тревогу"
Рис. 11.7 Пример документа Alarm - в MAIL.BOX появилась "мертвая" почта
В результате количество информации, которое вам действительно необходимо просмотреть в базе STATREP.NSF, существенно сократится.
Кроме того, открыв документ Alarm, вы можете кнопкой Create Trouble Ticket создать связанный с ним новый документ - Alarm Trouble Ticket - "карточку аварийной ситуации". По смыслу документ Alarm Trouble Ticket является заданием администратору сервера, на котором возникла неисправность, на ее устранение. Документ Trouble Ticket может быть как сохранен в базе STATREP.NSF, так и направлен письмом (кнопкой Mail Trouble Ticket) тому администратору, которому надлежит устранить возникшую неисправность. Сохраненные документы Trouble Ticket содержатся в базе STATREP.NSF в виде 6. Trouble Tickets\1. Alarm.
Рис. 11.8 Пример "карточки аварийной ситуации"
Стоимость соединения и стоимость маршрута
Стоимость соединения (длина дуги графа) - относительная величина затрат на пересылку данных по данному соединению. Стоимость соединения задается целым числом в диапазоне от 1 до 10, причем 1 трактуется как "самое дешевое", а 10 как "самое дорогое". Например, соединение типа Local Area Network имеет по умолчанию стоимость 1, а соединение типа Dialup Modem имеет по умолчанию стоимость 5, т.е. почта "равноценно" может быть передана через до 5 соединений по локальной сети вместо передачи через одно модемное соединение.
Администратор Notes может изменить стоимость соединения в поле с меткой Routing cost: документа Connection из адресной книги. Однако задавать значения, существенно отличающиеся от значений по умолчанию, следует обдуманно и с осторожностью.
Стоимость маршрута (длина пути на графе) определяется как сумма стоимостей каждого соединения в маршруте. Если, например, маршрут содержит два соединения, одно со стоимостью 10 и другое со стоимостью 1, общая стоимость маршрута - 11.
Платформа
| Платформа | AIX | HP-UX | NetWare | OS/2 | |
| Сертифицированная версия операционной системы | AIX 4.1.4 AIX 4.1.3 | HP-UX 10.01 | NetWare 3.12, NetWare 4.1 | OS/2 Warp, Warp Connect, OS/2 2.11 SMP | |
| Поддерживаемые процессоры | PowerPC Power2 | PA-RISC | Intel x86, Pentium | Intel 486, Pentium | |
| Поддержка SMP | Да | Да | Нет | Да | |
| Требования к компьютеру | RAM | 64 Mb минимум 96 Mb или больше рекомендуется | 64 Mb минимум 96 Mb или больше рекомендуется | 64 Mb минимум 96 Mb или больше рекомендуется | 32 Mb минимум 48 Mb или больше рекомендуется |
| Disk space | 300 Mb минимум 500 Mb или больше рекомендуется | 300 Mb минимум 500 Mb или больше рекомендуется | 300 Mb минимум 500 Mb или больше рекомендуется | 300 Mb минимум 500 Mb или больше рекомендуется | |
| Платформа | AIX | HP-UX | NetWare | OS/2 | |
| Disk swap space | 128 Mb | 128 Mb | Не используется OS | 16 Mb | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Да | Да |
| SPX | Да | Да | Да | Да | |
| SPX II | Нет | Да | Да | Нет | |
| NetBIOS/NetBEUI | Нет | Нет | Нет | Да | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Нет | Нет | Да | |
| X.PC | Да | Да | Да | Да | |
| X.25* | Нет | Нет | Нет | Да | |
| SNA* | Нет | Нет | Нет | Да |
| Платформа | Solaris | Windows 95 | Windows NT | |
| Сертифицированная версия операционной системы | Solaris 2.5 Solaris 2.4 | Windows 95 | Windows NT Server 3.51 | |
| Поддерживаемые процессоры | Intel x86, Pentium SPARC | Intel 486, Pentium | Intel 486, Pentium DEC Alpha | |
| Поддержка SMP | Да | Нет | Да | |
| Требования к компьютеру | RAM | 64 Mb минимум 96 Mb или больше рекомендуется | 16 Mb минимум 24 Mb или больше рекомендуется | 48 Mb минимум 64 Mb или больше рекомендуется |
| Disk space | 300 Mb минимум 500 Mb или больше рекомендуется | 150 Mb минимум 300 Mb или больше рекомендуется | 300 Mb минимум 500 Mb или больше рекомендуется | |
| Disk swap space | 128 Mb | 16 Mb | 64 Mb | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Да |
| SPX | Да | Да | Да | |
| SPX II | Да | Нет | Да | |
| NetBIOS/NetBEUI | Нет | Да | Да | |
| TCP/IP | Да | Да | Да | |
| VINES | Нет | Нет | Да | |
| X.PC | Да | Да | Да | |
| X.25* | Нет | Нет | Да | |
| SNA* | Нет | Нет | Да |
Требования для серверов версии (Domino)
| Платформа | AIX | HP-UX | NetWare | OS/2 | |||||||
| Сертифицированная версия операционной системы | AIX 4.1.4
AIX 4.2 | HP-UX 10.01 | NetWare 3.12, NetWare 4.1 | OS/2 Warp Server 4 (Entry, Advanced, и с поддержкой SMP), Warp Connect | |||||||
| Поддерживаемые процессоры | PowerPC, POWER,
POWER2 | PA-RISC | Intel x86,
Pentium | Intel 486, Pentium | |||||||
| Поддержка SMP | Да | Да | Нет | Да | |||||||
| Требования к компьютеру | RAM | 64 Mb минимум; 128 Mb или более рекомендуется | 64 Mb минимум; 128 Mb или более рекомендуется | 48 Mb минимум (64 польз.); 56 Mb минимум (128 польз.); 96 Mb или более рекомендуется | 32 Mb минимум; 48 Mb или более рекомендуется | ||||||
| Платформа | AIX | HP-UX | NetWare | OS/2 | |||||||
| Disk space | 300 Mb минимум; 500 Mb или более рекомендуется | 300 Mb минимум; 500 Mb или более рекомендуется | 300 Mb минимум; 500 Mb или более рекомендуется | 300 Mb минимум; 500 Mb или более рекомендуется | |||||||
| Disk swap space | 128 Mb | 128 Mb | Не используется OS | 16 Mb | |||||||
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Да | Да (Нет для SMP) | ||||||
| SPX * | Да | Да | Да | Да (Только для Warp Connect)** | |||||||
| SPX II | Да | Нет | Да | Нет | |||||||
| NetBIOS/NetBEUI | Нет | Нет | Нет | Да (Novell NetBIOS только для Warp Connect)** | |||||||
| TCP/IP | Да | Да | Да | Да | |||||||
| VINES | Нет | Нет | Нет | Да (Нет для SMP) | |||||||
| X.PC | Да | Да | Да | Да | |||||||
| X.25 | Нет | Нет | Нет | Да | |||||||
| SNA | Нет | Нет | Нет | Да |
| Платформа | Solaris | Windows 95 | Windows NT | ||||||
| Сертифицированная версия операционной системы | Solaris 2.5,
Solaris 2.5.1 (SPARC, Ultra SPARC) | Windows 95 | Windows NT Server 3.51, 4.0, Windows NT Workstation 3.51, 4.0 *** | ||||||
| Поддерживаемые процессоры | Intel x86,
Pentium (Intel Edition), SPARC, Ultra SPARC | Intel 486, Pentium | Intel 486, Pentium,
Digital Alpha | ||||||
| Поддержка SMP | Да | Нет | Да | ||||||
| Требования к компьютеру | RAM | 64 Mb минимум;
128 Mb или более рекомендуется | 16 Mb минимум;
24 Mb или более рекомендуется | 32 Mb минимум;
48 Mb или более рекомендуется | |||||
| Disk space | 300 Mb минимум;
500 Mb или более рекомендуется | 150 Mb минимум;
300 Mb или более рекомендуется | 300 Mb минимум;
500 Mb или более рекомендуется | ||||||
| Disk swap space | 128 Mb | 16 Mb | 64 MB | ||||||
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Да (Нет для 4.0) | |||||
| SPX | Да | Да | Да | ||||||
| SPX II | Да | Нет | Да | ||||||
| NetBIOS/NetBEUI | Нет | Да | Да | ||||||
| TCP/IP | Да | Да | Да | ||||||
| Платформа | Solaris | Windows 95 | Windows NT | ||||||
| VINES | Нет | Нет | Да (Нет для Digital Alpha или SMP) | ||||||
| X.PC | Да | Да | Да | ||||||
| X.25 | Нет | Нет | Да | ||||||
| SNA | Нет | Нет | Да |
*) Возможности Domino Advanced Services (кластеры и partitioned-серверы) в версии 4.5 не поддерживают протокол IPX/SPX. В настоящее время фирма Lotus не планирует обеспечивать поддержку IPX/SPX для будущих версий Domino Advanced Services.
**) Протоколы SPX и Novell NetBIOS не поддерживаются на платформе Warp Server, поскольку фирма Novell пока не сертифицировала эту платформу.
***) Для платформы Windows NT версии 3.51 необходим Service pack 5, версии 4.0 - Service pack 1 или старше.
Учтите, что рассмотренные требования изменяются каждые 2-3 месяца.
Сертифицированная версия операционной системы
| Платформа | AIX | HP-UX | OS/2 | Macintosh | |
| Сертифицированная версия операционной системы | AIX 4.1.4 AIX 4.1.3 | HP-UX 10.01 | OS/2 Warp, Warp Connect | Mac System 7.5, System 7.1 (680x0 только) | |
| Поддерживаемые процессоры | PowerPC Power2 | PA-RISC | Intel 486, Pentium | Motorola 68030, 68040 PowerPC | |
| Требования к компьютеру | RAM | 24 Mb минимум 32 Mb или больше рекомендуется | 24 Mb минимум 32 Mb или больше рекомендуется | 8 Mb минимум 12 Mb или больше рекомендуется | 12 Mb минимум для 680x0, 16 Mb минимум для PowerPC, 20 Mb или больше рекомендуется для обоих |
| Disk space | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Нет | Да |
| SPX | Да | Да | Да | Нет | |
| SPX II | Нет | Да | Нет | Нет | |
| NetBIOS/NetBEUI | Нет | Нет | Да | Нет | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Нет | Да | Нет | |
| X.PC | Да | Да | Да | Да | |
| X.25* | Нет | Нет | Нет | Нет | |
| SNA* | Нет | Нет | Нет | Нет |
| Платформа | Solaris | Windows 3.1 | Windows 95 | Windows NT | |
| Сертифицированная версия операционной системы | Solaris 2.5 Solaris 2.4 | Windows 3.1 | Windows 95 | Windows NT Workstation 3.51 | |
| Поддерживаемые процессоры | Intel x86, Pentium SPARC | Intel 386 или старше | Intel 386 или старше | Intel x86, Pentium DEC Alpha | |
| Требования к компьютеру | RAM | 24 Mb минимум 32 Mb или больше рекомендуется | 6 Mb минимум 8 Mb или больше рекомендуется | 8 Mb минимум 12 Mb или больше рекомендуется | 16 Mb минимум, 20 Mb или больше рекомендуется |
| Disk space | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | 30 Mb минимум, 40 или больше рекомендуется | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Нет | Нет |
| SPX | Да | Да | Да | Да | |
| SPX II | Да | Нет | Нет | Да | |
| NetBIOS/NetBEUI | Нет | Да | Да | Да | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Да | Да | Да | |
| X.PC | Да | Да | Да | Да | |
| X.25* | Нет | Нет | Нет | Нет | |
| SNA* | Нет | Нет | Нет | Нет |
Disk space
| Платформа | AIX | HP-UX | OS/2 | Macintosh | |
| Сертифицированная версия операционной системы | AIX 4.1.4 AIX 4.2 | HP-UX 10.01 | OS/ 2 Warp 3, Warp 4, Warp Connect | System 7.5 | |
| Поддерживаемые процессоры | PowerPC, POWERTM, POWER2TM | PA-RISC | Intel 486, Pentium | Motorola 68030, 68040, PowerPC | |
| Требования к компьютеру | RAM | 32 Mb минимум; 64 Mb или более рекомендуется | 32 Mb минимум; 64 Mb или более рекомендуется | 16 Mb минимум; 32 Mb или более рекомендуется | 12 Mb минимум для 680x0, 16 Mb минимум для PowerPC; 20 Mb или более рекомендуется для обоих |
| Disk space | 100 Mb минимум; 110 Mb или более рекомендуется | 100 Mb минимум; 110 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Нет | Yes |
| SPX | Да | Да | Да | Нет | |
| SPX II | Да | Нет | Нет | Нет | |
| NetBIOS/NetBEUI | Нет | Нет | Да | Нет | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Нет | Да | Нет | |
| X.PC | Да | Да | Да | Да | |
| X.25 | Нет | Нет | Нет | Нет | |
| SNA® | Нет | Нет | Нет | Нет | |
| MacTCP | Нет | Нет | Нет | Да |
| Платформа | Solaris | Windows 3.1 | Windows 95 | Windows NT | |
| Сертифицированная версия операционной системы | Solaris 2.5, Solaris 2.5.1 (SPARC, Ultra SPARC) | Windows 3.1 | Windows 95 | Windows NT Workstation 3.51, 4.0 | |
| Поддерживаемые процессоры | Intel 486, Pentium (on Intel Edition platform); SPARC, UltraSPARC | Intel x86, Pentium | Intel x86, Pentium | Intel x86, Pentium, Digital Alpha | |
| Требования к компьютеру | RAM | 32 Mb минимум; 64 Mb или более рекомендуется | 8 Mb минимум; 12 Mb или более рекомендуется | 8 Mb минимум; 12 Mb или более рекомендуется | 16 Mb минимум; 20 Mb или более рекомендуется |
| Disk space | 100 Mb минимум; 110 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | 30 Mb минимум; 40 Mb или более рекомендуется | |
| Поддерживаемые протоколы | AppleTalk | Нет | Нет | Нет | Нет |
| SPX | Нет | Да | Да | Да | |
| SPX II | Да | Нет | Нет | Да | |
| NetBIOS/NetBEUI | Нет | Да | Да | Да | |
| TCP/IP | Да | Да | Да | Да | |
| VINES | Нет | Да | Да | Да | |
| X.PC | Да | Да | Да | Да | |
| X.25 | Нет | Нет | Нет | Нет | |
| SNA | Нет | Нет | Нет | Нет |
Удаление пользователя
Если задача Administration Process полностью настроена, следует открыть в общей адресной книге вид People и, выбрав документ Person удаляемого пользователя, нажать кнопку Delеte Person, а в появившихся трех диалоговых окнах выбрать соответственно Yes, вариант удаления почтового ящика и Ok, No. Обычно задача Administration Process выполняет удаление хотя и медленнее, но (только не обижайтесь) корректнее вас.
Рис. 8.20 Диалоговые окна при удалении пользователя с применением задачи Administration Process
При удалении "вручную" можно поступить так.
· Удалите документ Person этого пользователя из общей адресной книги и почтовый ящик пользователя с сервера.
· Запретите этому пользователю доступ ко всем серверам. Лучше заранее "заготовить" группу Terminations и включить ее в списки управления доступом на всех серверах.
· Реплицируйте адресную книгу на все серверы командой Replicate
<имя сервера> NAMES.NSF.
Удаление "повисших ссылок" из ПЯ пользователей
В случае сбоев в СПЯ могут быть потеряны некоторые документы - тела сообщений. Если это произойдет, ПЯ пользователей еще будут содержать заголовки сообщений, ссылающиеся на "потерянные" тела сообщений в СПЯ. Пользователи не смогут эти "тела" прочитать - их уже нет в СПЯ. Чтобы удалить из ПЯ пользователя такие "ссылки в никуда", используют команду консоли
Load Object Collect USERMAIL.NSF ,
где USERMAIL.NSF - имя файла почты пользователя.
Если сообщение найдено в ПЯ и ссылается на СПЯ, но соответствующее тело сообщения в СПЯ не найдено, такое сообщение удаляется из ПЯ. Если реплика ПЯ на другом сервере содержит удаленное сообщение, сообщение может быть восстановлено в этом ПЯ при последующей репликации с тем сервером.
Удаление сообщений из СПЯ
В конце концов все получатели удаляют сообщение, и в СПЯ не требуется больше хранить его тело. Функция Collect, выполняющаяся по умолчанию в 2 часа ночи, удаляет тела ставших ненужными сообщений из СПЯ.
Чтобы запустить функцию Collect вручную, введите на консоли команду
Load Object Collect SHARED.NSF .
Если имеется несколько СПЯ, вам потребуется настроить запуск функции Collect для каждого из них по расписанию.
Чтобы удалить из СПЯ ненужные тела сообщений после того, как вы, не учтя сказанного ранее, удалили ПЯ пользователя, используйте команду консоли
Load Object Collect -Force SHARED.NSF .
Когда вы вводите опцию -Force, а функция Collect не может найти и открыть ПЯ (ибо вы его удалили), Collect ведет себя так, как будто все сообщения в ПЯ были удалены. В результате из СПЯ будут удалены все тела сообщений, которые использовались отсутствующим ПЯ, но никакими другими ПЯ.
Будьте осторожны. Использовать эту опцию следует только тогда, когда ПЯ был удален и никакой его резервной копии нет, так что вам остается только возможность освободить дисковое пространство в СПЯ, используемое телами сообщений из удаленного ПЯ. Когда вы используете опцию -Force, вы рискуете "заодно" удалить и тела сообщений, связанных с ПЯ, которые в данный момент оказались только временно недоступными. Поэтому убедитесь, что все другие ПЯ, имеющие тела сообщений в СПЯ, являются доступными.
Удаление СПЯ
Прежде, чем удалять СПЯ, необходимо отсоединить все ПЯ от него - только это позволит сохранить "полные сообщения" во всех ПЯ. Для отсоединения используется команда
Load Object Unlink SHARED.NSF ,
где SHARED.NSF - имя СПЯ. Для отсоединения одного ПЯ используется команда
Load Object Unlink USERMAIL.NSF ,
где USERMAIL.NSF
- имя ПЯ.
Установка и обслуживание Shared Mail
Установка на сервере Shared Mail - "совместно используемого почтового ящика" (СПЯ) - позволяет экономить дисковую память. Предположим, нескольким получателям, почтовые ящики которых находятся на этом сервере, приходит одно и то же сообщение. Вместо того чтобы помещать копию всего сообщения в почтовый ящик каждого получателя, в почтовые ящики получателей добавляется только заголовок сообщения со ссылкой на тело сообщения, а тело сообщения (содержимое поля Body типа Rich Text, включая имеющиеся в нем присоединенные файлы и объекты) помещается в совместно используемый почтовый ящик. Например, если тело сообщения имеет размер 1 Мб, а сообщение адресовано 10 получателям на этом сервере, будет сэкономлено около 9 Мб памяти. В то же время для пользователя такое хранение его сообщения остается "полностью прозрачным". Когда пользователь открывает сообщение, заголовок активизирует связь с телом сообщения, сохраненным в СПЯ. Notes "показывает" получателю сообщение точно так же, как если бы все сообщение было целиком в почтовом ящике пользователя. Если пользователь удаляет такое сообщение, Notes удаляет только заголовок из почтового ящика пользователя, а тело сообщения остается в СПЯ, но связанный с телом сообщения счетчик ссылок уменьшается на единицу. После того, как все получатели на этом сервере удалили это сообщение из своих почтовых ящиков, счетчик ссылок на тело сообщения становится равным нулю, серверная задача Object, которая по умолчанию запускается с параметром Collect в 2 часа ночи, удаляет уже более никому не нужное тело сообщения из СПЯ.
Но при очевидном преимуществе Shared Mail администратору следует помнить, что ее применение сопряжено с регулярным резервным копированием СПЯ, а на время копирования придется останавливать сервер. Без регулярного копирования может случиться серьезная "беда" - ведь потеря СПЯ равнозначна потере сразу всех пользовательских почтовых ящиков этого сервера.
Первичная установка Shared Mail
происходит при передаче задаче Mail Router соответствующей команды. Все последующие работы по сопровождению и настройке совместно используемой почты администратор выполняет с использованием серверной задачи Object store manager - Object.
Установка программного обеспечения станций
Для минимизации усилий администратора по установке программного обеспечения станций рекомендуется попросту скопировать соответствующий дистрибутив с дистрибутивного лазерного диска на файл-сервер.
Тогда администратор на компьютере пользователя "входит в сеть" и из сетевого каталога запускает программу INSTALL.EXE, выполняющую копирование файлов и создание группы с пиктограммой программы станции. По завершении работы INSTALL.EXE следует выполнить выбор соответствующих стране и используемому языку таблиц перекодировки и сортировки, как это описано в 2.2.4. Затем запускают программу станции. Обнаружив, что файл NOTES.INI "почти пуст", программа станции "задает ряд вопросов".
В первом диалоговом окне выбирается тип соединения станции с сервером: по локальной сети, с использованием модема, по локальной сети и с использованием модема, нет соединения. Если ID пользователя имеется в файле, выбирают опцию Your Notes user ID has been supplied to you in file. Если эта опция не выбрана, предполагается, что ID пользователя хранится в адресной книге сервера или, если станция вообще не имеет соединения с сервером, отсутствует.
Рис. 2.33 Четыре варианта установки станции
Если ID пользователя был предоставлен в файле, потребуется "указать" этот файл. Тогда имя пользователя будет определено из ID-файла, так что поле Your user name: во втором диалоговом окне будет "серым". Если же ID пользователя хранится в адресной книге сервера, придется ввести имя пользователя. Тогда по этому имени в адресной книге будет найден документ Person, а из него, после ввода соответствующего пароля, извлечен ID-файл.
Рис. 2.34 Если сервер доступен по локальной сети
Если сервер доступен станции только по локальной сети, потребуется ввести имя сервера и выбрать сетевой протокол, используемый для доступа станции к нему. Учтите, что при этом предполагается, что на компьютере, на котором устанавливается станция Notes, предварительно была обеспечена поддержка и выполнена проверка функционирования этого сетевого протокола.
Рис. 2.36 Переключение текущего местоположения на панели состояния станции
Рис. 2.37 Пример документа Location из адресной книги пользователя (фрагмент)
Поле с меткой Passthru server: может содержать имя сервера, по умолчанию предоставляющего станции пользователя в данном местоположении посреднические услуги для доступа к другому серверу, по каким-то причинам не доступному станции для прямого соединения. Обратите внимание, что сервер-посредник по умолчанию в одном местоположении может быть только один. Если же пользователю необходимо получать доступ к разным серверам через разные серверы-посредники, придется поработать "вручную" над пользовательской адресной книгой - в ней для каждого вызываемого сервера нужно создать документ Connection типа Passthru Server через соответствующий сервер-посредник на необходимый сервер. Альтернатива - создать несколько документов Location, но каждый с одним сервером-посредником по умолчанию.
Имейте в виду, что "от станции пользователя до сервера назначения" принципиально может быть не более 10 hop's ("прыжков" или "перегонов"). "Перегон" соответствует одной дуге в графе, начальной вершиной которого является станция, а конечной вершиной - сервер назначения. А рекомендуется использовать не более 4-х "перегонов", поскольку ретрансляция требует выделения каждым сервером определенных ресурсов.
Вторым видом документов из персональной адресной книги, в создании которых администратор может оказать помощь пользователю, является документ Connection ("Соединение"). Документ содержит информацию о способе установления соединения станции с сервером. Мы не станем здесь подробно рассматривать этот документ. Его рассмотрению, но применительно к общей адресной книге, уделяется много места в 4.1.1. Различия же между документами Connection из персональной и общей адресных книг весьма незначительны. Отметим только, что документы Connection в персональной адресной книге приходится создавать, если станция соединяется с сервером по протоколу TCP/IP (должен быть указан IP-сервера), по модему (должен быть задан телефонный номер модема на сервере), с использованием сервиса удаленного доступа к локальной сети и в некоторых других "нетрадиционных" случаях.
Установка сервера
Процесс установки в большей или меньшей степени зависит от операционной системы (Windows 95, Windows NT, OS/2, NetWare, Unix), для которой предназначен и под которой устанавливается сервер Lotus Notes. Менее всего различий встречается при установке серверов Notes на платформах Windows 95/NT и OS/2. Наибольшее количество особенностей присуще установке сервера Notes на платформе Novell NetWare.
Мы рассмотрим установку сервера Lotus Notes для Windows 95 - Windows NT (32-x разрядный), стремясь при этом обращать основное внимание на присущие всем платформам общие моменты, а не на конкретные особенности.
Установка начинается запуском с дистрибутива программы INSTALL.EXE (INSTPM.EXE для OS/2), которая выполняет по сути, только копирование необходимых файлов с дистрибутива в соответствующие каталоги на винчестере и создание группы с двумя (Windows NT 4.0) или тремя (Windows NT 3.51) пиктограммами (Рис. 2.1 - Рис. 2.4).
Рис. 2.1 Выбраны "ручная установка" и каталоги программ и данных Notes
В окне Install Options выбирают установку сервера (Server Install или Manual Install) и задают два каталога: Notes Program Folder - каталог программ Notes (в него будут скопированы выполняемые файлы, библиотеки динамической компоновки и файлы с расширением .cls) и Notes Data Folder - каталог данных Notes (в него будут скопированы базы, шаблоны баз, файлы с расширением .mdm и т.п.).
В окне Customize (если было выбрано Manual Install) можно более подробно отобрать копируемые компоненты.
Рис. 2.2 Выбран "минимальный набор" для установки сервера; обычно документация тоже устанавливается на сервер, чтобы не хранить ее на станциях
При установке сервера должны быть выбраны опции:
· Notes Workstation - станция администратора, устанавливаемая на компьютере сервера
· Lotus Domino Server - собственно сервер Notes
· Personal Data Files
и Additional Templates - файлы данных и дополнительные шаблоны для создания баз
· Documentation Databases, Notes Release 4 Help и Notes Help Lite - обычно вся документация, чтобы не устанавливать ее на станциях пользователей
· Attachments Viewer - программное обеспечение для просмотра присоединенных файлов на станции, выбирается по желанию администратора.
Далее следуют опции, присущие Notes версий от 4.5 и зависящие от платформы:
· Java support files - программное обеспечение для запуска Java-апплетов на станции в базе данных Web Navigator
· Domino Action Templates - шаблоны, необходимые для работы Domino.Action - программного обеспечения для управления Web-сервером Domino
· Single Password Login - программное обеспечение (сервис), позволяющее на компьютере под Windows NT "автоматически вводить" пароль для Windows NT в качестве пароля для Notes
· Notes Service Install - программное обеспечение для установки сервера Notes как сервиса Windows NT
· Notes Performance Monitor - программное обеспечение для добавления объекта Domino Server в приложение Performance Monitor (в Windows NT)
· User Synchronization - библиотеки динамической компоновки, "добавляющие" в приложение User Manager for Domains (Windows NT) дополнительный пункт меню Notes и позволяющие при регистрации пользователя Windows NT одновременно зарегистрировать его и как пользователя Notes, обычно с таким же паролем, как для Windows NT.
Рис. 2.3 Закладка Advanced Services
На закладке Advanced Services выбираются дополнительные возможности, поддерживаемые в Notes только с версии 4.5. Формально для использования этих возможностей должны приобретаться лицензии Lotus Domino Advanced Services.
Программное обеспечение Domino Partitioned Server
позволяет одновременно выполнять несколько серверов Notes на одном физическом компьютере. Эта возможность может быть полезна для провайдеров услуг Notes, поскольку позволяет сократить число компьютеров, необходимых для функционирования большого количества серверов Notes, которые занимаются в основном операциями, не требующими больших вычислительных ресурсов, например, только передачей почты.
Несколько серверов Notes (до 6) может быть "объединено" в кластер. Репликации баз данных между серверами кластера происходят "почти" в реальном времени, имеется возможность осуществлять балансировку загрузки серверов кластера (load balancing) и "на лету" переключать обращения пользователей к реплике базы на нефункционирующем или "сильно загруженном" сервере кластера на ее реплику на другом сервере кластера (failover).
Возможности по составлению счетов (billing features) позволяют создавать собственные приложения для составления всевозможных отчетов, например, о величине почтового трафика пользователей, организаций, доменов;
об использовании баз данных или даже определенных документов в базах; о затратах времени на выполнение агентов.
Для установки программного обеспечения поддержки кластеров и составления счетов выберите "Advanced Services" и "Advanced Services Data". При установке первого partitioned-сервера на компьютере необходимо выбрать все три возможности.
Рис. 2.4 После копирования файлов программа инсталляции создает группу с двумя пиктограммами (Windows NT 4.0)
По завершении работы программы INSTALL.EXE "самое подходящее время" выполнить выбор соответствующих стране и используемому языку таблиц перекодировки и сортировки, как это описано в 2.2.4. Затем запускают программу станции - пиктограмма с названием Lotus Notes Client (а не Lotus Domino Server). Обнаружив, что файл NOTES.INI "почти пуст", программа станции "задает ряд вопросов". Именно в диалоговых окнах этой программы при ее первом запуске и выполняется дальнейшая настройка сервера.
Наиболее часто встречаются следующие 3 варианта установки сервера:
· первый сервер в организации - создается адресная книга нового домена и ID-файлы сертификатора организации, сервера и его администратора
· очередной сервер в том же домене той же организации - адресная книга реплицируется с существующего сервера этого домена, ID-файлы сервера и его администратора должны быть подготовлены предварительно
· первый сервер в новом домене той же организации - создается адресная книга нового домена, ID-файлы сервера и его администратора должны быть подготовлены предварительно.
Рис. 2.5 Первый или очередной сервер в домене
В первом диалоговом окне при установке возможны только два выбора:
· The first Lotus Notes Server in your organization (Первый сервер в вашей организации)
влечет создание нового домена и установку первого сервера в этом домене. При последующих выборах следует дополнительно уточнить, устанавливается ли первый сервер в организации (тогда происходит создание ID-файла сертификатора организации CERT.ID) или устанавливается первый сервер в новом домене той же организации (при этом не создается ID-файл сертификатора организации).
· An additional Lotus Notes Server in your organization (Дополнительный сервер в вашей организации) влечет добавление нового сервера к существующему домену.
Установка Shared Mail - создание
Для установки Shared Mail
на сервере - создания совместно используемого почтового ящика и "разрешения" его использования сервером - во-первых, убедитесь, что запущена задача Mail Router и, во-вторых, передайте ей команду Use SHARED.NSF, набрав на консоли:
Tell Router Use SHARED.NSF ,
где SHARED.NSF - полное имя файла СПЯ, включая каталог, если это необходимо, например, MAIL/Shared.nsf. В ответ на эту команду задача Mail Router создает соответствующую базу и добавляет в файл NOTES.INI переменную Shared_Mail=2, что и является разрешением использовать СПЯ при доставке и передаче почты на этом сервере. Дополнительно при этом на сервере в каталоге данных Notes автоматически создается "база" MAILOBJ.NSF, являющаяся файлом-ссылкой, всегда указывающей на файл текущего СПЯ.
Если Shared_Mail=2, то задача Mail Router помещает в СПЯ тела всех сообщений, которые адресованы пользователям этого сервера (даже если сообщение было адресовано только одному пользователю). Кроме того, сообщения из MAIL.BOX этого сервера, предназначенные для передачи на другой сервер, так же хранятся "раздельно": заголовки в MAIL.BOX, а тела в СПЯ.
Если Shared_Mail=1, задача Mail Router помещает в СПЯ только тела тех сообщений, которые адресованные двум или более пользователям этого сервера. По мнению автора, это наиболее рациональный полезный вариант.
Наконец, если Shared_Mail=0, то возможность вообще не используются.
Установление подлинности (процедура аутентификации)
Процесс установления подлинности (процедура аутентификации) включает четыре этапа:
· установление сервером доверия к публичному ключу клиента (станции, другого сервера);
· проверка, знает ли клиент свой личный ключ;
· установление клиентом доверия к публичному ключу сервера;
· проверка, знает ли сервер свой личный ключ;
Приступим к рассмотрению первого этапа. Когда клиент пытается установить связь с сервером, содержащиеся в ID-файле клиента имя и публичный ключ посылаются на сервер. Клиент по запросу сервера также присылает список сертификатов, которые будут использоваться, чтобы подтвердить ассоциацию между именем клиента и его публичным ключом. Однако присланные клиентом сертификаты еще необходимо проверить, а для выполнения этой проверки нужен публичный ключ выдавшего "присланный" сертификат сертификатора. Но получить этот ключ следует из более заслуживающего доверия источника, чем "присланный" клиентом сертификат или "своя" общая адресная книга.
Установление сервером доверия
При применении иерархических и взаимных сертификатов используются следующие правила доверия публичным ключам.
1. Доверять любому публичному ключу, полученному из сертификатов-компонент иерархического сертификата, имеющегося в своем ID-файле.
2. Доверять любому публичному ключу, полученному из имеющего силу (т.е. уже прошедшего проверку) сертификата-компоненты.
Проиллюстрируем использование этих правил в процессе установления подлинности клиента, принадлежащего тому же дереву имен, что и сервер (Рис. 8.5).
Рис. 8.5 Установление подлинности с применением иерархических сертификатов: дерево имен компании Acme
· Клиент Alice/Sales/Acme пытается получить доступ к серверу SERVER1/Development/Acme. Клиент сообщает серверу свое полное имя и публичный ключ. Сервер начинает процесс установления подлинности публичного ключа клиента.
· Сравнением своего имени с именем клиента сервер выявляет наличие общего предка. Общий предок всегда существует, когда клиент и сервер из одного дерева имен. Очевидно, этот общий предок - /Acme. Сервер читает публичный ключ /Acme из сертификата-компоненты в своем ID-файле. Согласно правилу 1 сервер "уверенно знает" публичный ключ /Acme.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Acme создал для /Sales/Acme. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Acme. Если сертификат имеет силу, согласно правилу 2 сервер "уверенно знает" публичный ключ /Sales/Acme.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Sales/Acme
создал для Alice/Sales/Acme. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Sales/Acme. Если сертификат имеет силу, согласно правилу 2 сервер "уверенно знает" публичный ключ Alice/Sales/Acme.
· Проиллюстрируем использование правил доверия публичным ключам в процессе установления подлинности клиента, когда клиент и сервер принадлежат разным деревьям имен (Рис. 8.6).
Рис. 8.6 Установление подлинности с применением иерархических и взаимных сертификатов: деревья имен компаний Acme и Omega
В этом случае приходится использовать как иерархические сертификаты из ID-файлов, так взаимный сертификат из адресной книги. Предполагаем, что сертификатор /Acme создал взаимный сертификат для сертификатора /Omega. Этот взаимный сертификат хранится в локальной адресной книге сервера SERVER1/ Development /Acme.
· Клиент Jon/Marketing/Omega пытается получить доступ к серверу SERVER1/Development/Acme. Клиент сообщает серверу свое полное имя и публичный ключ. Сервер начинает процесс установления подлинности публичного ключа клиента.
· Поскольку общих предков у John/Marketing/Omega и SERVER1/Development/Acme нет, сервер вынужден обратиться к своей адресной книге в поисках взаимного сертификата. Этот взаимный сертификат должен быть выпущен от имени сервера SERVER1/Development/Acme или одного из его предков для пользователя John/Marketing/Omega или одного из его предков. По условию /Acme, предок SERVER1/Development/Acme, создал взаимный сертификат для /Omega, предка John/Marketing/Omega. Сервер извлекает из локальной адресной книги этот взаимный сертификат.
· Сервер читает публичный ключ создателя взаимного сертификата - /Acme - из сертификата-компоненты в своем ID-файле. Согласно правилу 1 сервер "уверенно знает" публичный ключ /Acme.
· Сервер проверяет взаимный сертификат, используя публичный ключ /Acme. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ /Omega.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Omega создал для /Marketing/Omega. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Omega. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ /Marketing/Omega.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Marketing/Omega создал для John/Marketing/Omega. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Marketing/Omega. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ John/Marketing/Omega.
Отметим, что в этой процедуре происходила даже проверка взаимного сертификата, извлеченного "из собственной локальной" адресной книги. Следовательно, взаимный сертификат, как и всякий сертификат, "подписан" создавшим его сертификатором. Однако, изучив механизм "электронной подписи" (рассматривается в 9.5), любознательный читатель не обнаружит в документе Cross Certificate никаких следов ее применения. Все дело в "тонком" различии собственно публичного ключа и информации, которая хранится в поле с меткой Certified Public Key: некоторых документов, в том числе и документа Cross Certificate, из адресной книги - "сертифицированного публичного ключа". Обратим внимание, что "в дизайне" это поле имеет имя Certificate. Сертифицированный публичный ключ сам является сертификатом - в нем содержится вся та информация, которая входит в состав сертификата, в том числе и публичный ключ. Косвенным подтверждением этого является следующий факт. При продлении срока действия сертификата в ID-файле пользователя изменяется сертифицированный публичный ключ в документе Person. Однако при этом в ID-файле не происходит смены публичного ключа и связанного с ним личного ключа - пользователь сохраняет возможность читать шифрованную почту в своем почтовом ящике и работать с базами данных, для которых применено локальное шифрование.
Установление сервером доверия к публичному ключу клиента с применением простых сертификатов
При применении простых сертификатов используются следующие правила доверия публичным ключам.
1. Доверять любому публичному ключу, полученному из сертификата, сохраненного в своем ID-файле.
2. Доверять любому публичному ключу, полученному из имеющего силу (т.е. уже прошедшего проверку) сертификата.
Использование этих правил в ходе установления подлинности клиента можно проиллюстрировать на следующем примере.
· Клиент Doe сообщает свое имя и публичный ключ серверу SALES. SALES пока не доверяет публичному ключу Doe.
· SALES сообщает Doe имя сертификатора, создавшего простой сертификат, имеющийся в его ID-файле.
· Doe просматривает простые сертификаты в своем ID-файле. Находит среди них сертификат, созданный сертификатором, имя которого сообщил ему SALES. Посылает этот сертификат SALES.
· SALES читает публичный ключ своего сертификатора из сертификата в своем ID-файле. Согласно правилу 1 SALES доверяет этому публичному ключу.
· SALES проверяет сертификат, полученный от Doe, используя при этом публичный ключ своего сертификатора. Эта проверка включает вычисление "контрольной суммы" по информации из сертификата и сравнение её с "контрольной суммой", хранящейся в самом сертификате. Однако хранящаяся в сертификате "контрольная сумма" зашифрована личным ключом сертификатора, и для того, чтобы её расшифровать, как раз и необходим публичный ключ этого сертификатора. Если проверка успешна ("контрольные суммы" совпали), полученный от Doe сертификат имеет силу. Тогда согласно правилу 2 SALES доверяет публичному ключу Doe.
Введение в Lotus Notes и уточнение терминов
Lotus Notes - многоплатформная (функционирует под многими операционными системами) многопротокольная (может работать по многим сетевым протоколам) программная система для групповой работы с документами.
Программное обеспечение Notes состоит из клиентской части - станции Notes - и серверной части - сервера Notes.
Сервер Notes
отвечает за:
· предоставление в совместное использование расположенных на нем баз данных разным пользователям (как сервер баз данных)
· хранение пользовательских почтовых ящиков и передачу почты между серверами по расписанию (как почтовый сервер)
· выполнение репликаций баз данных между серверами по расписанию (поддержка распределенных баз данных)
· взаимодействие с пользователями и серверами, имеющими доступ к серверу только по модему непосредственно (как DialUp-сервер) или с использованием сервиса удаленного доступа к локальной сети
· предоставление пользователям и серверам доступа через данный сервер к другим серверам (как Passthry-сервер)
· обеспечение безопасности.
Администратор Notes
устанавливает, контролирует и управляет работой сервера Notes и обеспечивает его безопасность. Управление сервером может выполняться администратором как непосредственно с сервера, так и дистанционно, со станции администратора.
Программное обеспечение станции Notes (клиента) реализует графический интерфейс для пользователя. Со своих станций пользователи имеют доступ к почтовым услугам, предоставляемым сервером Notes, и расположенным на серверах Notes базам данных. Пользователи могут также сохранять персональные базы данных локально, т.е. на своих компьютерах.
Станция Notes (клиент) имеет соединение с сервером(ами) Notes по локальной сети (LAN) или с использованием модема. DialUp-станция Notes имеет доступ к серверу Notes только посредством модема. Станции Notes не могут соединяться между собой. Сервер Notes тоже не может "по своей инициативе" соединиться со станцией - соединение с сервером всегда инициирует станция. Сервер может соединяться с другими серверами для выполнения репликаций баз, передачи почты или предоставления "посреднических услуг" станциям или другим серверам.
WAN - глобальная сеть, объединяющая многие локальные сети с использованием мостов, маршрутизаторов, выделенных линий, стандартных телефонных линий или иного специального оборудования для соединения компьютеров, обычно на больших расстояниях.
Для обслуживания Notes формально существуют четыре стандартных должности:
· Администратор системы - обслуживает серверы, занимается поддержкой пользователей, загружает и останавливает серверы, регистрирует серверы и сертификаторов верхних уровней, составляет и отлаживает расписание репликаций и передачи почты, распределяет дисковое пространство на сервере, следит за происходящими в системе событиями по протоколу работы серверов, выполняет регламентные работы.
· Инженер поддержки
- устанавливает и проверяет Notes, обеспечивает поиск ошибок. В большинстве случаев может поддерживать Notes в дополнение к поддержке других систем.
· Сертификатор
(Certifier) - имеет и хранит от несанкционированного использования ID сертификатора, создает и сертифицирует ID пользователей, используя при этом ID сертификатора, а также предпринимает прочие меры безопасности.
· Администратор базы данных - управляет доступом пользователей к конкретной базе данных, размещенной на сервере.
Выпуск взаимных сертификатов без передачи безопасных копий
Когда станция Notes версий 4.х обращается к серверу Notes версий 4.х, с которым у пользователя этой станции нет взаимного сертификата, однако у сервера или имеется взаимный сертификат для пользователя или его предка, а потому часть процедуры аутентификации на стороне сервера завершается успехом, или к серверу разрешен анонимный доступ, станция получает от сервера от сервера иерархический сертификат, содержащийся в его ID-файле, и предлагает пользователю выпустить взаимный сертификат.
Рис. 8.33 Диалоговое окно Cross Certify на станции
При этом пользователь получает диалоговое окно Cross Certify. Нажатие кнопки Yes влечет создание в локальной адресной книге станции взаимного сертификата от имени пользователя станции для сертификатора организации, которой принадлежит вызванный сервер. Нажатие кнопки No, очевидно, запрещает создавать взаимный сертификат. Наибольший интерес представляет кнопка Advanced Options. Нажав ее, вы получите уже знакомое диалоговое окно Cross Certify ID.
Рис. 8.34 Диалоговое окно Cross Certify ID на станции
Кнопкой Certifier администратор или сертификатор сможет выбрать тот ID-файл сертификатора, от имени которого считает нужным выпустить взаимный сертификат. Кнопкой Server можно выбрать сервер, в адресную книгу которого (естественно, при наличии доступа) этот сертификат будет помещен. В поле Subject name: можно выбрать имя, для которого выпускается взаимный сертификат - от имени сервера до имени его сертификатора организации. Можно и изменить срок действия сертификата...
Администратор сервера может пользоваться этой возможностью, запуская на компьютере сервера станцию, работающую под ID-файлом сервера, затем вызывая другой сервер, в адресной книге которого уже имеется взаимный сертификат для вызывающего сервера или его предка, и "на лету" выпуская взаимный сертификат на своей стороне.
Завершая главу, ответим на два вопроса.
· Что следует делать, если взаимный сертификат более не нужен? Его просто следует удалить из адресной книги.
· Могут ли в адресной книге одного домена одновременно присутствовать два или более дерева имен? Могут, и это типичная ситуация в только начинающих развиваться доменах, когда первое дерево имен было выбрано неудачно и происходит постепенный переход к более удачному дереву имен. Чтобы деревья имен "мирно уживались" в одной адресной книге, обычно выпускают взаимный сертификат от имени сертификатора первого дерева имен для сертификатора второго дерева имен, а затем взаимный сертификат от имени сертификатора второго дерева имен для сертификатора первого дерева имен. В этом случае оба "зеркально симметричных" взаимных сертификата находятся в одной адресной книге. Однако пользователям из одного дерева имен приходится скопировать из общей адресной книги в свою персональную взаимный сертификат для сертификатора другого дерева имен. Только по этой причине и рекомендуется иметь в одном домене или организации одно дерево имен. Но рекомендация не означает запрета...
Взаимная сертификация пользователя или сертификатора с сервером в другой организации
Предположим, что ваше имя Joe User/Sales/Company_A, и вы хотите связаться с сервером из другой компании, имя которого Server/Company_B. Поскольку вы и сервер не имеете общего предка, необходимы взаимные сертификаты.
Пусть в вашей компании уже имеется сервер Server/Sales/Company_A, который "умеет" связываться с сервером Server/Company_B. Тогда вы можете обнаружить в общей адресной книге вашей компании документ Cross Сertificate такого содержания
Issued By (Кто выпустил): /Sales/Company_A или /Company_A
Issued To (Для кого): Server/Company_B
Вы можете скопировать этот документ в вашу персональную адресную книгу. Когда вы затем попробуете связаться с сервером Server/Company_B, начнется процедура аутентификации. Ваша станция успешно выполнит свою часть процедуры: в локальной адресной книге имеется взаимный сертификат, который один из ваших предков (/Sales/Company_A или /Company_A) выпустил для сервера Server/Company_B. Успех части процедуры аутентификации, выполняемой сервером Server/Company_B, зависит от того, какой взаимный сертификат имеется в его локальной адресной книге. Если вид этого таков:
Issued By (Кто выпустил): Server/Company_B или /Company_B
Issued To (Для кого): /Sales/Company_A или /Company_A
вас ожидает успех - Server/Company_B или его предок /Company_B выпустил взаимный сертификат для вашего предка /Sales/Company_A или /Company_A.
Если вид этого документа в их адресной книге:
Issued By (Кто выпустил): Server/Company_B или /Company_B
Issued To (Для кого): Server/Sales/Company_A
часть процедуры аутентификации, выполняемой сервером Server/Company_B, кончается неуспехом, поскольку сервер Server/Sales/Company_A не ваш предок, а на одном уровне с вами (Joe User/Sales/Company_A).
Тогда вы имеете две возможности.
1) Можно послать безопасную копию вашего ID-файла (Joe User/Sales/Company_A) администратору другой компании и попросить его выпустить на нее взаимный сертификат. Администратор может выпустить этот взаимный сертификат как на имя Joe User/Sales/Company_A, так и на /Sales/Company_A или /Company_A. Процесс выпуска взаимного сертификата будет напоминать рассмотренный выше при взаимной сертификации двух серверов.
2) Можно попросить вашего сертификатора, чтобы он послал безопасную копию одного из ID-файлов сертификаторов вашей организации (или /Sales/Company_A или /Company_A) администратору другой компании с просьбой выпустить на нее взаимный сертификат. Администратор другой компании может выпустить этот взаимный сертификат на имя /Sales/Company_A или /Company_A, если ему прислана безопасная копия /Sales/Company_A, или только на /Company_A, если ему прислана безопасная копия /Company_A.
Если администратор другой компании не откажется это сделать, документ Cross Certificate в общей адресной книге компании Acme примет следующий вид
Issued By (Кто выпустил): /Server/Company_B или /Company_B
Issued To (Для кого): Joe User/Sales/Company_A или /Sales/Company_A или /Company_A
и вы получите доступ на Server/Company_B.
Таким образом, взаимный сертификат для пользователя или сервера позволяет только одному ID-файлу проходить процедуру аутентификации. Но если одна из сторон выпускает взаимный сертификат на имя сертификатора другой, эта сторона позволяет любому, кто имеет этого сертификатора своим предком, проходить процедуру аутентификации.
Получается очень мощная и гибкая система. Если администратор компании Company_B хочет предоставить доступ большому количеству пользователей из Company_A на сервер Server/Company_B, ему не имеет смысла индивидуально кросс-сертифицировать каждого из этих пользователей. Вместо этого администратор может выпустить взаимный сертификат сертификатору /Sales/Company_A. Любой пользователь, имеющий этого точного предка в компании Company_A, будет проходить процедуру аутентификации. Однако пользователь из Company_A с именем Sam User/Marketing/Company_A не будет аутентифицирован, поскольку Sam User/Marketing/Company_A не предок /Sales/Company_A.
Если же имеются некоторые пользователи из Company_A с именами, заканчивающимися на /Sales/Company_A, которых администратор Company_B ни при каких условиях не хочет "пускать" на сервер Server/Company_B, администратор будет должен использовать в документе Server поля-списки Access server:
("имеют доступ к серверу") или Not access server:
("не имеют доступа к серверу") для уточнения доступа.
Взаимная сертификация сервера с сервером в другой организации
Предположим, что сервер с именем Server/Company_A из компании А должен иметь доступ к серверу с именем Server/Company_В
в компании B (для репликации баз или передачи почты). Рассмотрим те действия, которые нужно выполнить, чтобы оба сервера могли устанавливать подлинность друг друга.
1. Администратор сервера из компании A должен сделать безопасную копию ID-файла Server/Company_A и передать ее сертификатору (обычно он же и администратор сервера) в компании B. Для создания безопасной копии выполняется такая последовательность действий: меню File - Tools - User ID - закладка More Options - кнопка Create Safe Copy. Чтобы случайно не перепутать ID-файл, с которого создается безопасная копия, администраторы предпочитают последовательность действий: меню File - Tools - Server Administration - Administration - ID File… - выбор нужного ID-файла
- закладка More Options -
кнопка Create Safe Copy. Для сокращения риска повреждения ID-файла сервера желательно делать это, когда сервер остановлен. Если имеется другая копия ID-файла сервера, можно создать безопасную копию с нее. А еще лучше сделать безопасную копию ID-файла сервера один раз и многократно использовать в последующем.
2. Сертификатор или администратор сервера в компании B получает безопасную копию и должен создать взаимный сертификат для Server/Company_A. Для этого он должен выполнить последовательность действий:
в меню File - Tools - Server Administration - кнопка Certify - в ее меню Cross Certify ID File.
Будет получено диалоговое окно Choose Certifier ID для выбора ID-файла субъекта, от имени которого будет создаваться взаимный сертификат. В качестве него может быть выбран ID-файл сервера Server/Company_B или ID-файл сертификатора /Company_B. Если бы имя сервера из компании B было Server/Sales/Company_В, тогда в качестве него мог быть выбран ID-файл сервера Server/Sales/Company_В или ID-файлы сертификаторов /Sales/Company_В или /Company_В. Предположим, администратор выбрал ID-файл сертификатора /Company_B. Последует запрос пароля для выбранного ID-файла.
Затем появится диалоговое окно Choose ID to Certify для выбора ID-файла, для которого выпускается взаимный сертификат. Здесь должна быть выбрана безопасная копия, полученная из компании A.
После этого появляется диалоговое окно Cross Certify ID.
Рис. 8.30 Администратор из компании В, используя ID сертификатора /Company_B, выпускает взаимный сертификат для сервера Server/Company_A
В нем в поле Subject name: администратор может конкретизировать имя, для которого выпускается взаимный сертификат. В данном случае сертификат может быть выпущен как для Server/Company_B, так и для его предка /Company_B. Предположим, администратор выбрал Server/Company_B.
Кнопка Server используется для выбора сервера, в адресной книге которого будет создан взаимный сертификат - документ Cross Certificate. Кнопка Certifier позволяет при необходимости сменить ID-файл субъекта, от имени которого выпускается взаимный сертификат. Наконец нажимается кнопка Cross-certify...
В результате в адресную книгу сервера Server/Company_B будет добавлен документ формы Cross Certificate, выпущенный от имени /Company_B для Server/Company_A.
Рис. 8.31 Взаимный сертификат в адресной книге сервера Server/Company_B от имени /Company_B для Server/Company_A
Мы "прошли" только половину пути по процессу взаимной сертификации! Если Server/Company_A на этом этапе попробует получить доступ к Server/Company_B, на его консоли появится сообщение об ошибке "Your Address Book does not contain any cross certificates capable of authenticating the server"
- "ваша адресная книга не содержит взаимных сертификатов, способных подтвердить сервер".
3. Теперь администратору из компании В следует сделать "безопасную копию" ID-файла Server/Company_B и передать этот файл администратору сервера или сертификатору из компании А.
4. Администратор компании A, получив безопасную копию из компании В, может использовать ID-файл сервера Server/Company_A
или ID-файл сертификатора /Company_A, чтобы создать взаимный сертификат для Server/Company_B
или /Company_B. Он повторяет действия, рассмотренные в шаге 2, но с другими ID-файлами. Предположим, он выбрал ID-файл сертификатора /Company_A и выпускает сертификат для имени Server/Company_B. В результате в адресной книге на сервере в компании А появится документ формы Cross Certificate, выпущенный от имени /Company_A
для Server/Company_B.
Рис. 8.32 Взаимный сертификат в адресной книге сервера Server/Company_A от имени /Company_A для Server/Company_B
Процесс взаимной сертификации завершен. Server/Company_A и Server/Company_B теперь могут устанавливать подлинность друг друга.
При этом никакие другие серверы из компании A, например, Server2/Company_A, не смогут получать доступ к Server/Company_B. Так будет происходить потому, что в адресной книге компании В имеется взаимный сертификат только для Server/Company_A. И наоборот, никакие другие серверы из компании B
не смогут получать доступ к Server/Company_A.
Взаимные сертификаты
Взаимный сертификат - иерархический сертификат, создаваемый сертификатором с иерархическим именем для пользователя, сервера или сертификатора с иерархическим именем в случае, когда между сертификатором и сертифицируемым отсутствуют иерархические отношения (т.е. сертификатор и сертифицируемый принадлежат разным деревьям имен). Взаимные сертификаты часто используются, когда две независимых организации должны связываться между собой с применением Notes. Хранятся взаимные сертификаты не в ID-файлах, а в адресных книгах (документ Cross Certificate), общих или личных, смотря по тому, для кого создавался и кем будет использоваться взаимный сертификат. Интерпретировать документ Cross Certificate следует подобно Рис. 8.4.
Например, сервер компании Alpha Inc. имеет имя SERVER1/Support/Development/Alpha Inc./US. К этому серверу должен иметь доступ сервер RETAIL2/Retail/Sales/Omega/US
отделения розничной продажи компании Omega.
Безопасная копия ID-файла сервера RETAIL2/Retail/Sales/Omega/US посылается сертификатору /Support/Development/Alpha Inc./US. Сертификатор создает взаимный сертификат для присланного ему ID-файла. В результате взаимный сертификат "за подписью" /Support/Development/Alpha Inc./US, содержащий имя сервера RETAIL2/Retail/Sales/Omega/US и его публичный ключ, будет добавлен в адресную книгу на сервере SERVER1/Support/Development/Alpha Inc./US.
Процесс "зеркально" повторяется. Безопасная копия ID-файла сервера SERVER1/Support/Development/Alpha Inc./US посылается сертификатору /Retail/Sales/Omega/US. Сертификатор создает взаимный сертификат для присланного ему ID-файла. В результате взаимный сертификат "за подписью" /Retail/Sales/Omega/US, содержащий имя SERVER1/Support/Development/Alpha Inc./US и его публичный ключ, будет добавлен в адресную книгу на RETAIL2/Retail/Sales/Omega/US.
Могут использоваться и взаимные сертификаты между организационными единицами или организациями - это взаимный сертификат для ID-файла сертификатора. Тогда любой пользователь, сертифицированный этим сертификатором и желающий получить доступ к "чужому" серверу, должен лишь скопировать в буфер документ Cross Certificate из общей адресной книги и вставить его из буфера в свою личную адресную книгу.
Задачи системы учета свободного времени
SCHED и CALCONN Система учета свободного времени (Free Time system) состоит из двух серверных задач: Schedule Manager (SCHED) и Calendar Connector (CALCONN). Запуск этих задач автоматически "прописывается" в переменной ServerTasks в файле NOTES.INI сервера, когда вы устанавливаете сервер Notes версии 4.5.
Schedule Manager
Пользователь разрешает использование информации о его свободном времени, создавая документ Calendar Profile в своем почтовом ящике. Поле с меткой Only the following users can read my Freetime Schedule ("Только следующие пользователи могут читать информацию о моем свободном времени") позволяет задать список тех, кто может получать информацию о свободном времени пользователя. Если это поле пусто, все пользователи могут получать эту информацию.
При первом запуске задача Schedule Manager создает на "своем" сервере базу данных BUSYTIME.NSF и в этой базе создает "входы" для каждого пользователя, для которого этот сервер является почтовым сервером (поле MailServer в документе Person). Schedule Manager функционирует на сервере постоянно и каждый раз, когда пользователи вносят изменения в свои календари, он немедленно заносит эти изменения в базу BUSYTIME.NSF, находящуюся на этом сервере. Это гарантирует, что база BUSYTIME.NSF на каждом почтовом сервере постоянно находится в синхронном состоянии с календарями пользователей.
Даже если вы удалите базу данных BUSYTIME.NSF, при следующем запуске сервера Schedule Manager вновь создаст ее и заполнит соответствующей информацией из почтовых ящиков пользователей этого сервера. Обратите внимание, что только Schedule Manager имеет доступ к базе данных BUSYTIME.NSF.
Когда пользователь хочет пригласить одного или несколько человек на встречу и выбирает поиск свободного времени приглашаемых, к работе подключается Schedule Manager. В первую очередь он находит по общей адресной книге местоположения почтовых серверов и почтовых ящиков приглашаемых лиц. Затем Schedule Manager ищет информацию о свободном времени каждого приглашаемого лица в базе BUSYTIME.NSF на почтовом сервере приглашаемого лица. Schedule Manager возвращает список дат и времен возможных встреч и количество "доступных" лиц.
Calendar Connector
Всякий раз, когда пользователь, почтовый ящик которого находится на одном сервере, запрашивает информацию о свободном времени пользователя, почтовый ящик которого находится на другом сервере, к работе подключается задача Calendar Connector. Задача использует информацию из общей адресной книги, чтобы найти путь между почтовым сервером запрашивающего информацию пользователя и почтовым сервером пользователя, информацию о свободном времени которого запрашивается. Обратите внимание, что эти серверы могут находиться и в разных доменах Notes.
Пример: как выполняется запрос о свободном времени
Предположим, что пользователь Иван Иванович, почтовый ящик которой находится на сервере A, хочет узнать, когда свободен пользователь Иван Никифорович, чтобы договориться с ним о встрече. При этом происходит следующее.
· Иван Иванович в своем почтовом ящике создает приглашение на встречу с Иваном Никифоровичем и нажимает кнопку поиска свободного времени.
· Станция Ивана Ивановича посылает запрос о свободном времени на его почтовый сервер (сервер A).
· Система учета свободного времени ищет документ Person
для Ивана Никифоровича в общей адресной книге сервера A.
· Если находит, то определяет из его поля MailServer имя почтового сервера Ивана Никифоровича, и затем выполняет одно из следующего.
· Если почтовый сервер Ивана Никифоровича тот же сервер A, система учета свободного времени ищет свободное время Ивана Никифоровича непосредственно в базе BUSYTIME.NSF на этом сервере и затем отображает полученную информацию Ивану Ивановичу.
· Если почтовым сервером Ивана Никифоровича является сервер B из того же домена, что и сервер A, система учета свободного времени на сервере А передает запрос на cервер B. Система учета свободного времени на cервере B находит необходимую информацию в базе BUSYTIME.NSF на сервере B, возвращает ее системе учета свободного времени на сервере A, и полученная информация отображается у Ивана Ивановича.
· Но если поле CalendarDomain в документе Person
Ивана Никифоровича не пусто и содержит имя домена, отличающееся от имени его почтового домена, это означает, что Иван Никифорович пользуется другим приложением для планирования времени, например, Organizer 2.x или OfficeVision. Тогда система учета свободного времени направляет запрос о свободном времени Ивана Никифоровича в этот домен.
· Если система учета свободного времени не находит документ Person для Ивана Никифоровича в общей адресной книге сервера A, это означает, что почтовый ящик Ивана Никифоровича находится в другом домене. Если имя домена явно содержится в адресе Ивана Никифоровича или если иерархическое имя Ивана Никифоровича дает достаточно информации для определения имени его домена, система учета свободного времени ищет в общей адресной книге документ формы Domain для домена Ивана Никифоровича и затем выполняет одно из следующего.
· Если был найден документ формы Domain
типа Adjacent Domain ("Соседний домен"), система учета свободного времени обращается к информации из поля CalendarServer этого документа. Это поле может содержать имя сервера из домена Ивана Никифоровича, который "умеет" принимать запросы о свободном времени. Если поле не пусто, система учета свободного времени выполняет запрос на этот сервер. Если поле CalendarServer пусто, информация о свободном времени Ивана Никифоровича недоступна.
· Если система учета свободного времени находит документ формы Domain
типа Foreign Domain ("Чужой домен"), это знает, что Иван Никифорович пользуется другим приложением для планирования времени, например, Organizer 2.x или OfficeVision. Поле CalendarServer в документе Foreign Domain должно содержать имя сервера, который "умеет" принимать запросы о свободном времени, а поле CalendarSystem должно содержать тип используемого приложения для планирования времени. Система учета свободного времени выполняет запрос о свободном времени Ивана Никифоровича на указанный в поле CalendarServer сервер.
· Если система учета свободного времени не находит в общей адресной книге никаких документов формы Domain для домена Ивана Никифоровича, информация о свободном времени Ивана Никифоровича недоступна.
Запрос о свободном времени будет также терпеть неудачу, если сервер Ивана Никифоровича или один из серверов "в цепочке" не функционирует.
Заглянем в файл NOTES.INI
Пока мы рассмотрим только те переменные из NOTES.INI, на которые обычно обращают внимание при установке сервера и станции. Учтите, что для того, чтобы выполненные "вручную" исправления в NOTES.INI "вступили в силу", потребуется перезапустить станцию или сервер. Способы модификации NOTES.INI, не требующие перезапуска сервера, будут рассмотрены позже.
KitType=<1 или 2>
1 - станция, 2 - сервер. Начальное значение получает при установке Notes.
Domain=<имя домена>
На сервере задает имя домена, которому принадлежит этот сервер; на станции задает имя домена, которому принадлежит "домашний" сервер пользователя. По умолчанию: имя, заданное при установке Notes.
KeyFilename=<путь и имя ID-файла пользователя>
Путь для ID-файла пользователя. См. также ServerKeyFileName.
ServerKeyFileName=<путь и имя ID-файла сервера>
Путь для ID-файла сервера. Используется сервером и API-программами, выполняющимися на сервере.
CertificateExpChecked=<дата>
Дата последней проверки времени истечения сертификата в ID-файле пользователя. Например, CertificateExpChecked=D:\NOTES33\NIONTSEV.ID 21.09.95
CertiferIDFile=<путь и имя ID-файла сертификатора>
Путь для ID-файла сертификатора. Имеется только в NOTES.INI на первом сервере в организации и в NOTES.INI на станциях администраторов и сертификаторов.
Описание портов и их настройки
Следующий фрагмент из файла NOTES.INI содержит информацию о выполненных из диалогового окна User Preferens (см. Рис. 2.18) настройках портов сервера.
; Список активных портов на сервере или станции
Ports=TCPIP,SPX,LAN0,COM2
; Список неиспользуемых портов на сервере или станции
DisabledPorts=VINES,COM1,COM3,COM4,COM5
; Параметры порта TCPIP
TCPIP=TCP, 0, 15, 0
TCPIP_TcpConnectTimeout=0,5
; Параметры порта SPX
SPX=NWSPX,0,15,0,,12288,
NetWareSpxSettings=0,0,0,0,1,1
; Параметры порта LAN0
LAN0=NETBIOS,0,15,0,,12288,
VINES=VINES, 0, 15, 0
COM1=XPC,1,15,0,
; Параметры порта COM2, MT9614.MDM - файл команд модема
COM2=XPC,2,15,0,,12302,19200,33,mt9614.mdm,150,15
COM3=XPC,3,15,0,
DialTimer=150
IdleHangupTimer=10
Names=<список имен файлов адресных книг>
Имена файлов (без расширения .NSF) адресных книг для поиска при проверке имен получателей почтовых сообщений. Список через запятую. Первое имя в списке должно быть names. Адресные книги просматриваются в указанном в списке порядке. Notes завершает поиск, когда он нашел вхождение имени получателя в одной из адресных книг. При посылке почты станция использует эту возможность для поиска имен пользователей или групп. Сервер не использует эту возможность при просмотре документов Connection, Domain и Server - такие документы выбираются только из первой адресной книги. Общее число символов в списке имен не должно превышать 256. Применяется переменная как для сервера, так и для станции.
По умолчанию переменная отсутствует в NOTES.INI, и Notes использует только одну адресную книгу с именем NAMES.NSF.
Замечания об использовании кластера
Состояния сервера-члена кластера
Сервер кластера может находиться в следующих состояниях: AVAILABLE ("доступен"), BUSY ("занят"), RESTRICTED ("использование ограничено"), MAXUSERS ("превышен порог пользователей"), UNREACHABLE
("не функционирует") и INVALID. Состояние INVALID - переходное состояние, которое можно наблюдать в течение очень короткого отрезка времени, когда "отрабатывается" процесс вывода сервера из состава кластера.
Следующая таблица показывает, что будет происходить с запросом на доступ к базе данных на сервере кластера для клиентов Notes версий 3.х, 4.х и серверных задач Notes Replicator ("обычный" репликатор), Cluster
Replicator (внутрикластерный репликатор) и Mail Router (маршрутизатор почты). В таблице использованы следующие обозначения:
· Access granted - сервер выполняет запрос,
· Load balance - сервер генерирует событие load balance, а обратившиеся к нему станция или сервер предпринимают попытку перенаправить запрос,
· Failover - сервер генерирует событие failover, а обратившиеся к нему станция или сервер предпринимают попытку перенаправить запрос,
· No access - сервер отвергает запрос.
| Состояние | сервера | ||||||||||||
| Запрос от | Available | Busy | Restricted | MaxUsers | Unreachable | Invalid | |||||||
| Клиент R3 | Access granted | Access granted | Access denied | Access denied | No access | Access granted | |||||||
| Клиент R4 | Access granted | Load balance | Failover | Failover | Failover | Access granted | |||||||
| Клиент R4 (репликации) | Access granted | Access granted | Access granted | Access granted | Failover | Access granted | |||||||
| Notes Replicator | Access granted | Access granted | Access granted | Access granted | No access | Access granted | |||||||
| Cluster Replicator | Access granted | Access granted | Access granted | Access granted | No access | Access granted | |||||||
| Mail Router | Access granted | Access granted | Failover | Failover | Failover | Access granted |
Особенности внутрикластерного репликатора
Серверная задача Cluster Replicator осуществляет репликации "по событиям" изменения документов в базах текущего сервера, а не по расписанию. Эти события хранится в очереди событий в виртуальной памяти сервера. Если другой сервер-член кластера, на который должны быть переданы эти изменения, не функционирует, события "накапливаются" в очереди "исходного" сервера. При перезапуске "исходного" сервера "накопившиеся" в его очереди события будут утеряны. Так что не следует думать, что внутрикластерный репликатор всегда гарантирует "полную синхронность" реплик. Кроме того, выполняемые внутрикластерным репликатором изменения не протоколируются в истории репликаций баз. Поэтому, если синхронность реплик на серверах-членах кластера нарушилась, следует воспользоваться "обычным" репликатором. А чтобы вообще не задумываться о возможной несинхронности баз в кластере из-за рассмотренного свойства внутрикластерного репликатора, можно поддерживать внутри кластера и обычные репликации по расписанию. Конечно, такой подход несколько "груб", но зато надежен.
Кроме того, на сервере кластера может запускаться несколько внутрикластерных репликаторов. Если ресурсы компьютеров позволяют, в кластере из n серверов на каждом сервере-члене можно запускать до n-1 внутрикластерных репликаторов. При этом передача изменений с одного сервера-члена на остальные серверы будет происходить псевдо-одновременно, а не последовательно. В результате изменения должны передаваться в целом быстрее, чем при использовании одного внутрикластерного репликатора. Но практика богаче теории - в условиях недостатка оперативной памяти на серверах из-за усилившегося свопинга вы можете получить и обратный эффект.
Состояния баз Out of service и Pending delete
В документах базы данных CLDBDIR.NSF присутствуют поля, информация их которых отображается в колонках видов Out of service ("выводится из обслуживания")
и Pending delete ("ожидает удаления"). Не пытайтесь изменять значения этих полей в базе CLDBDIR.NSF - поля лишь отображают текущее состояние базы, но не могут его изменить.
Администратор выводит базу из обслуживания, когда ему необходимо получить к базе монопольный доступ, например, чтобы выполнить уплотнение базы. Все последующие обращения пользователей к базе, находящейся в состоянии Out of service, будут отвергаться и при возможности перенаправляться в реплику на других серверах кластера. В результате через некоторое время база будет "освобождена" пользователями. По своему смыслу это аналогично действию команды консоли Set Config "Server_Restricted=1", но не для всех баз на сервере, а только для конкретной базы. После того, как администратор проделает с базой необходимую работу, он обычно снова "вводит базу в обслуживание".
Администратор переводит базу в состояние Pending delete, когда ему необходимо убрать реплику этой базы с конкретного сервера-члена кластера. При этом обычно предполагается, что реплика этой базы имеется на других серверах кластера. Однако подлежащая удалению реплика может использоваться пользователями. Все последующие обращения пользователей к базе, находящейся в состоянии Pending delete, будут отвергаться и перенаправляться в реплику на других серверах кластера. В результате через некоторое время база будет "освобождена" пользователями. И только после того, как внутрикластерный репликатор "передаст" последние изменения из этой реплики в реплики на других серверах, данная реплика будет удалена.
Перевод баз данных в рассмотренные выше состояния осуществляется из окна Server Administration кнопкой Database Tools с последующим выбором "инструмента" Cluster Management.
Рис. 10.12 Перевод баз в состояния Out of service, In service и Pending delete
Репликации с кластером
В командах консоли сервера для выполнения репликаций, а также в документах Connection для репликаций вместо имени сервера назначения может указываться имя кластера. При этом в репликации принимают участие не только реплики баз данных вызывавшего сервера и соответствующие реплики на том сервере-члене кластера, с которым было установлено соединение, но и соответствующие реплики на других серверах-членах кластера. Вызывающий сервер должен быть версии 4.5, наличие лицензии Lotus Domino Advanced Services для него не требуется. Аналогично можно поступать при репликациях между станцией и кластером.
Внутрикластерный обмен по отдельному сегменту локальной сети
Для того, чтобы внутрикластерный обмен серверов происходил по отдельному сегменту локальной сети, на компьютерах серверов должны быть установлены как минимум две сетевые карты с поддержкой необходимых стеков протоколов, а в файлах NOTES.INI
серверов должна присутствовать переменная Server_Cluster_Default_Port=<имя порта>. Здесь <имя порта>
- имя порта сервера Notes, связанного с протоколом и сетевой картой, подключенной к сегменту локальной сети, по которому должен происходить внутрикластерный обмен.
Запуск посредством документа Program в общей адресной книге
В общей адресной книге создается документ Program (а уже созданные документы находятся в виде Server\Programs).
Рис. 3.34 Документ обеспечивает запуск задачи COMPACT ежедневно в 4 часа ночи
Поле Program name: (имя программы) содержит только имя программы из каталога сервера или каталога в поисковом пути операционной системы. Поле Command line: содержит командную строку для этой программы. В поле Server to run on:
(сервер для запуска) выбирают полное название сервера, на компьютере которого должна быть запущена программа. В группе полей Schedule задается разрешение на автоматический запуск по расписанию Enabled/Disabled и время запуска Run at times:. Если интервал повторения Repeat interval of: нулевой, программа запускается один раз. Иначе несколько раз в день через заданный интервал. Days of week: - по каким дням недели. Кроме того, в поле Enabled/Disabled: возможен выбор Startup Only, означающий, что данная программа должна автоматически запускаться при старте сервера.
Запуск посредством переменных в файле NOTES.INI сервера
Время запуска и списки запускаемых серверных задач задается в файле NOTES.INI сервера.
· ServerTasks=<имена задач> Список задач, автоматически запускаемых при старте сервера и работающих до его останова. По умолчанию на сервере версии 4.5, не являющемся членом кластера: Replica, Router, Update, Stats, Amgr, Adminp, Sched, CalConn.
ServerTasks=Replica,Router,Update,Stats,AMgr,Adminp,Sched,CalConn
Дополнительно можно запускать задачи Compact, Fixup, Event, Report, Collect, Billing, Web, HTTP, POP3, SMTPMTA, X400MTA
и др.
· ServerTasksAt<time>=<имена задач> Список задач, запускаемых сервером в час <time>. По умолчанию задачи Database Catalog и Designer
выполняются в 1 час ночи. Все индексы во всех базах обновляются в 2 часа ночи задачей UpdAll. В это же время происходит удаление неиспользуемых тел сообщений из совместно используемого почтового ящика - Object Collect <файл СПЯ>. Статистика об использовании баз данных собирается в 5 часов утра.
ServerTasksAt1 = Catalog,Design
ServerTasksAt2 = UpdAll,Object Collect mailobj.nsf
ServerTasksAt5 = Statlog
Время запуска <time> определяется числом от 0 до 23, например:
ServerTasksAt3 = Catalog
ServerTasksAt7 = UpdAll
ServerTasksAt16 = Statlog
Задачу COMPACT, которая в предыдущем подразделе запускалась согласно документа Program, можно было бы добавить в NOTES.INI в качестве значения переменной ServerTasksAt2, с "командной строкой" -S 5.
ServerTasks = Replica,Router,Update,Stats,AMgr
ServerTasksAt1 = Catalog,Design
ServerTasksAt2 = UpdAll,Object Collect mailobj.nsf
ServerTasksAt4 = Compact -S 5
ServerTasksAt5 = Statlog
Учтите только, что если вы внесли изменения в переменные ServerTasks…, то для того, чтобы эти изменения начали действовать, необходимо перезапустить сервер.
