Создание документа Holiday
Документы Holiday праздников, заполняются для Вашей организации, чтобы определить намеченные отпуска, праздники и нерабочие дней. Пользователи выбирают тип документов Holiday, чтобы импортировать и добавить эту информацию к их персональным календарям. Domino позволяет иметь набор документов Holiday, которые Вы можете изменять или удалять. Вы можете также добавлять документы Holiday, в Вашей организации. Документы Holiday расположены в Domino Directory.
Вы категоризируете документы Holiday согласно имени группы.
Например, Вы можете иметь группу с именем Полная рабочая неделя, которая содержит информацию об отпуске для служащих c полной рабочей неделей Вашей компании. По умолчанию Domino имеет набор документов Holiday, и имеют названия групп, связанные со странами. Например, Соединенные Штаты или Италия, и имеет группы содержащие документы, определяющие праздничные дни в каждой стране.
Как администратор, Вы можете изменять или удалять эти документы, чтобы приспособить список нерабочих дней, для Вашей организации. После чего Вы можете уведомить пользователей о группах нерабочих дней, что они имели современную информацию.
Вы можете добавлять документы в существующие группы, выбирая эту группу при создании нового документа. Вы можете также создавать новые группы, вводя новое название группы в документах Holiday. Помните, что Ваши пользователи импортируют документы праздников согласно имени группы, а не названия документа, так что Вы можете планировать, как организовать документы в группах.
Создание документов Holiday.
* Из клиента Domino Administrator, выбирайте закладку Настройка.
* Выбирайте нужный Domino Directory сервер.
* Выбирайте представление Miscellaneous/Holidays
* Выбирайте – Add Holiday.
* Выбирайте значение поля Group. Выберите существующую группу, чтобы связывать ее с праздником (отпуском), или создайте новую группу, введя новое название для группы.
* Введите данные в поля и затем выбирайте – Save And Close.
Обратите внимание, что некоторые поля в этой таблице зависит от предыдущего выбора поля.
|
Поле |
Значение |
|
Title |
Имя праздника (отпуска), например Рождество |
|
Detailed description (Optional) |
Описание праздника, кому он посвящен и так далее |
|
Repeat |
Выбирайте, как часто праздник должен повторяется: * Ежегодно * Ежемесячно по дате * Ежемесячно по дню * Выборочно |
|
Start Date |
Дата начала праздника. Эта дата может быть фактическая дата праздника (Новый год), или это может быть дата, начала отпуска. Например, если Ваша организация дает служащим каждую пятницу, с июня по август, Вы ввели бы 1 июня, как дату начала и выбрали бы конечную дату - 31 августа. Это поле доступно для всех опций повторения кроме опции – Выборочно. |
|
Repeat Dates |
Дата или даты периодических праздников, например, 01/01/99, 01/02/2003. Это поле доступно только, если Вы выбрали - Выборочно, для поля повторения. |
|
Continuing |
Как долго Вы хотите, чтобы праздник повторился: * For - Праздник повторяется числом месяцев или лет * Until – повторения Праздника до определенной даты, это поле доступно для всех наборов повторения кроме – Выборочно. |
|
Repeat for/until |
Если Вы вводите For в поле Continuing, выберите число лет, или месяцев (в зависимости от Вашего выбора в поле Repeat). Если Вы вводите Until в поле, выберите дату, до которой Вы не хотите повторять праздник. Это поле доступно для всех наборов поля Repeat кроме – Выборочно |
|
Repeat Interval |
Выбирайте, как часто повторяется праздник, месяц, день. Это поле доступно только, если Вы выбрали - Ежемесячно днем или Ежемесячно по времени в поле Repeat. |
|
Start from the end of month |
Проверьте это поле, если Вы хотите создать отношения между датой начала и полями интервала повторения. Это поле полезно в течение отпуска или случаев, когда праздники, попадают на последние дни месяца. |
|
If the date falls on a weekend |
Выбирают, куда праздник должен передвинуться, праздник, если он выпадает на выходные. Это поле доступно для всех выбора повторения, кроме Ежемесячно, Днем и Выборочно. |
|
Mark time as |
Выбирает Занятый или Свободный. Определяет, делает ли календарь пользователя запись этого праздника как занятое или свободное время. |
Создание документа Non-Adjacent Domain
Вы создаете документ Non-Adjacent Domain, чтобы указать путь между серверами, которые расположены в Notes доменах, которые подключаются друг к другу только с использованием домена посредника, известного как Adjacent Domain. Вы также используете документы Adjacent Domain, чтобы подключиться к домену посреднику. Если применяется предположение, что все серверы в домене используют тот же самый Domino Directory, Вы нуждаетесь только в одном документе Non-Adjacent Domain, для каждого Non-Adjacent Domain.
Ограничения, которые Вы устанавливаете для документа Non-Adjacent Domain, применяются только к предыдущему домену. Эти ограничения работают вместе с теми, которые вы найдете в документе Configuration Settings.
Создания документа Non-Adjacent Domain.
* Из клиента Domino Administrator, выбирайте закладку Настройка, затем откройте секцию Почта.
* Выбирайте – Домены.
* Выбирайте – Add Domain.
* На закладке Basics заполните нужные поля:
| Поля | Значения | ||
| Domain type | Выбирайте Non-Adjacent Domain | ||
| Mail sent to domain | Имя Notes домена назначения | ||
| Route through domain | Имя домена посредника | ||
| Domain description | Описание домена |
* Выбирайте закладку Restrictions, заполните, если нужно любые поля и сохраните документ.
Создание документа подключения для двух серверов, через интернет, с использованием Proxy сервера
* Из клиента Domino Administrator, выбирайте закладку Настройка.
* Выбирайте Ваш сервер в поле Справочник из, для открытия нужного Domino Directory.
* Выбирайте Сервер и затем выбирайте – Все документы сервера.
* Открывайте Server документ сервера, которым Вы хотите соединиться через интернет через Proxy и щелкайте – Редактировать Сервер.
* Выбирайте – Ports – Proxies и затем сделайте одно из следующего:
· Если Вы соединяетесь через HTTP Proxy, введите полное имя хоста, домена или IP адрес HTTP Proxy и номер порта. Например, ведите в это поле proxy.company.com:8080 или 192.168.77.34:8080.
· Если Вы соединяетесь через SOCKS Proxy, введите полное имя хоста, домена или IP адрес SOCKS Proxy и номер порта. Например, ведите в поле proxy.company.com:1080 или 192.168.77.34:1080.
Обратите внимание, если Вы ввели данные для обоих полей, Domino использует HTTP Tunnel proxy.
* Сохраните документ.
* Если Вы соединяетесь через Domino Passthru сервер, создаете Passthru документ подключения для Passthru сервера.
Обратите внимание, если Вы имеете конфигурацию Proxy, сервер использует Proxy для всех соединений. Для связей, которые не требуют, Proxy сервера, введите в имени сервера в No Proxy для этих хостов, или в секции domains на вкладке Ports – Proxies в Server документе сервера.
Создание документа подключения для сервера Domino, сервисом NNTP
Вы нуждаетесь в документе подключения для любого сервера, с которого Вы принимаете группы новостей. Если Вы только получаете группы новостей, Вы будете нуждаться только в этом типе документа подключения для каждого сервера, с которым Вы соединяете для обновления групп новостей.
Если вы планируете принимать и отсылать группы новостей, то Вам понадобиться два типа документов. Вы нуждаетесь в документе подключения для любого сервера, на который Вы будете выталкивать группы новостей, а также в документе подключения для любого сервера, с которого Вы будете забирать группы новостей. В основном это будет связь по сети LAN, поэтому вы будете создавать документы подключения для LAN связи.
Если топология Вашей сети основана на типе связи Dial-Up для любого сервера, к которому Вы имеете доступ только через MS RAS. В этом случае, Вы будете также нуждаться в документах подключения для каждого сервера, с которого Вы будете забирать группы новостей, и документы подключений для каждого сервера, которому Вы будете передавать группы новостей.
Создание документа подключения сервера для соединения с сервером групп новостей.
*
Из клиента Domino Administrator, выбирайте закладку Настройка.
* Выбирает вид Сервер – Подключения
* Делайте одно из двух:
· Чтобы создавать документ подключения, выбирайте – Add Connection.
· Чтобы редактировать документ подключения, выберите сервер, для которого Вы хотите редактировать документ подключения и выбирайте – Edit Connection.
* На закладке – Basics, заполните эти поля:
| Поле | Значение | ||
| Connection type | Выбирайте тип – News/NNTP Feed | ||
| Source Server | Domino сервер, на котором запущен NNTP сервис.
Пример: Server1/Acme Или IP сервера 192.168.220.123 | ||
| Connect via | Выбирайте тип соединения – Direct connection | ||
| Destination server | Полное имя интернет хоста сервера.
Пример: news.provider.com Или IP адрес удаленного Domino сервера с сервисом NNTP |
* Выбирайте закладку NNTP и заполняйте эти поля:
|
Поле |
Значение |
|
News feed type |
Выбирает один из этих типов подключений: * Accept- чтобы разрешить удаленным серверам NNTP соединятся с Domino сервером с сервисом NNTP, и передавать новые статьи. * Pull - чтобы соединиться с удаленным сервером NNTP и запрашивать новые статьи с этого сервера * Push - чтобы соединиться с удаленным сервером NNTP и посылать новые статьи на этот сервер * Pull-Push - чтобы соединиться с удаленным сервером NNTP и обмениваться с ним новыми статьями в обоих направлениях |
|
Authentication |
Выбирайте одно из двух: * None - (по умолчанию) * Password - требовать имя пользователя и пароль для соединения |
|
Username |
Имя регистрации для сервера, с которого Вы будете принимать, или на который Вы будете отсылать статьи. |
|
Password |
Пароль для сервера, с которого Вы будете принимать, или на который Вы будете отсылать статьи. |
|
Channel encryption |
Выбирайте одно из двух: * None - (по умолчанию) * SSL - удаленный сервер со службой NNTP требует, чтобы Domino сервер с NNTP использовал протокол – SSL. Протокол нужно разрешить в Server документе на закладке Ports – Internet Ports – News, в поле SSL port status |
|
Create newsgroups |
Выбирайте одно из двух: * Automatic - (по умолчанию) новые группы создаются автоматически. * Manual - ручное создание групп на сервере |
|
Newsgroup subdirectory |
Имя подкаталога для хранения новостей По умолчанию – NNTP |
|
Connection timeout |
Максимальное время в минутах для завершения процесса обмена группами новостей По умолчанию - 0 минут |
|
Newsgroups |
Имена групп новостей (newsgroups) которые Вы хотите принимать к себе на сервер, или отсылать на другие сервера. |
* Заполняйте остающиеся поля так, как Вы заполняете их для любого документа подключения, затем сохраните документ.
Создание документа подключения для типа соединения Network Dial-Up connection.
* Из клиента Domino Administrator, выбирайте закладку Настройка.
* Выбирает вид Сервер – Подключения
* Делайте одно из двух:
· Чтобы создавать документ подключения, выбирайте – Add Connection.
· Чтобы редактировать документ подключения, выберите сервер, для которого Вы хотите редактировать документ подключения и выбирайте – Edit Connection.
* На закладке Basics, в поле Connection type:, выбирайте – Network Dial-Up.
* Заполните оставшиеся поля на закладке Basics, как обычно для документа подключения.
* Щелкает на закладке – Network Dial-Up.
* В поле Choose a service type, выберите – Microsoft Dial-Up Networking.
* Заполните остающиеся поля, как обычно, затем сохраните документ.
Соединение с удаленным сервером с сервисом NNTP.
Вы можете использовать программное обеспечение службы удаленного доступа к сети LAN, чтобы соединиться с промежуточным сервером, который в свою очередь может, соединяется с удаленным сервером, на котором имеется служба NNTP.
Обратите внимание, если Вы установили Domino сервер со службой NNTP на платформу другую, чем WindowsNT или Windows95, Вы не можете конфигурировать, сервер для звонка на сервер с NNTP, через Domino сервер.
* Устанавливайте программное обеспечение для удаленного доступа к сети. Запустите программное обеспечение для удаленного соединения сети.
* Сконфигурируйте модем.
* Создайте документ подключения, для соединения с сервером с применением MS RAS.
Обратите внимание, что Вы должны создать в общем количестве три документа подключения.
Создание документа подключения для соединения серверов через интернет
Вы создаете Server документ подключения, чтобы наметить репликации и маршрутизации почты для серверов по интернету.
* Из клиента Domino Administrator, выбирайте закладку – Настройка.
* Выбирайте Ваш сервер в поле Справочник из, для открытия нужного Domino Directory.
* Выбирайте – Сервер и затем выбирайте – Подключения.
* Выбирайте – Add Connection.
* Выбрать Local Area Network, в поле Connection type. Вы можете также использовать Dial-Up тип связи.
* Заполните поля:
| Поля | Значения | ||
| Source server | Имя сервера источника | ||
| Source domain | Имя домена сервера источника | ||
| Use the Port(s) | TCPIP - порт и протокол, который будет использоваться при соединении через интернет | ||
| Usage priority | Normal или Low.
По умолчанию – Normal. | ||
| Destination server | Имя сервера назначения | ||
| Destination domain | Имя домена сервера назначения | ||
| Optional network address | HR-E.Acme.com или 192.22.256.36. |
* Выбирайте - Routing/Replication - Schedule, для назначения расписания для Вашего документа связи.
* Сохраните документ.
* Если соединение использует Proxy сервер, измените Server документ для использования Proxy сервера.
Создание документа SMTP Connection
Документ SMTP Connection определяет, как сообщения направляются с сервера, который не может посылать сообщения SMTP, на сервер который это умеет. Документ SMTP Connection определяет подключение между Notes доменом и серверами SMTP.
Создания документа SMTP Connection.
* Из клиента Domino Administrator, выбирайте закладку Настройка и затем откройте секцию Почта.
* Выбирайте – Подключения и выбирайте – Add Connection.
* На закладке Basics, заполните нужные поля и затем сохраните документ:
| Поля | Значения | ||
| Connection type | SMTP | ||
| Source server | Имя non-SMTP сервера | ||
| Source domain | Имя non-SMTP домена серверов | ||
| Connect via | Direct connection | ||
| Destination server | Имя виртуального сервера, например – All_Internet_hosts | ||
| Destination domain | Имя виртуального домена, указанного в поле интернет Domain name, документа Foreign SMTP domain. |
Создание документов Site Profile и Resource документы в базе планирования ресурсов
Документ Site Profile определяет местоположение, где ресурс располагается. Вы должны создать, по крайней мере, один документ Site Profile прежде, чем Вы сможете создавать документы Resource.
Когда Вы создаете документы Resource, Вы определяете название ресурса, тип и готовность его. Вы определяете, кто может резервировать ресурс. После того, как Вы указали все ресурсы, пользователи могут вести поиск свободного времени для ресурса и резервировать ресурс для встреч при поиске свободного времени и приглашения пользователей на встречу.
Для каждого документа Resource, которого Вы создали, процесс администрирования создает документ Resource в Domino Directory.
Когда Вы создаете Site Profile или документ Resource, новый ресурс не доступен для пользователей, пока процесс администрирования не добавляет ресурс в Domino Directory, а задача Replicator не реплицирует изменения на все доступные реплики Domino Directory.
Создание документа Site Profile.
* Убедитесь, что Вам назначена роль CreateResource в ACL базы данных Resource Reservations.
* Из клиента Domino Administrator, выбирайте закладку Файлы.
* Из панели серверов, выбирайте сервер, с которым Вы хотите работать.
* Откройте базу данных Resource Reservations и выбирайте любое представление, кроме Calendar, My Reservations или Reservations Waiting for Approval.
* Выбирайте кнопку New Site.
* Заполните все поля и затем выбирайте – Сохранить и закрыть:
|
Поле |
Значение |
|
Site name |
Имя местоположения, где расположен ресурс |
|
Domain name |
Имя домена, в котором расположена база данных Resource Reservations |
* Убедитесь, что Вам назначена роль CreateResource в ACL базы данных Resource Reservations.
* Из клиента Domino Administrator, выбирайте закладку Файлы.
* Из панели серверов, выбирайте сервер, с которым Вы хотите работать.
* Откройте базу данных Resource Reservations
* Выбирайте кнопку New Resource
* На закладке Type, выберите тип ресурса - Room или Other
* Выбирайте закладку Resource Information и заполните поля:
|
Поле |
Значение |
|
Name |
Уникальное название ресурса, например номер комнаты |
|
Site |
Позволяет просматривать список доступных участков хранения ресурсов и выбирать один из них |
|
Category (появится, когда вы выбираете Other из Resource Type) |
Название категорий для ресурса, например электроника или видео. Это поле также показывает имена всех предварительно введенных категорий, из которых Вы можете выбирать нужные. |
|
Capacity (появится, когда вы выбираете Room из Resource Type) |
Вместимость ресурса, способность вместить определенное количество человек |
|
Description |
Описание ресурса, например большой зал заседаний с видео |
|
Other comments |
Дополнительное описание, определенное этому ресурсу - например, зал заседаний хорош для планирования небольших по количеству участников встреч |
* Выбирайте закладку Owner Options, заполните поля владельца ресурсов:
|
Поле опций |
Значение |
|
None |
Никто не был назначен владельцем ресурса и любой может резервировать ресурс |
|
Only owner can book resource |
Владелец Resource. Только владелец может обрабатывать запросы Resource. Введите имя владельца ресурса в поле. |
|
Only select list of people can book resource |
Позволить только некоторым пользователям иметь доступ к ресурсу. Введите имена пользователей, чтобы разрешить резервировать этот ресурс, из списка имен. Любые пользователи, не указанные здесь не могут резервировать этот ресурс. |
|
Only select list of people can book resource via autoprocessing - all others require owner approval |
Позволить только некоторым пользователям доступ к ресурсу и назначить владельца ресурса. Введите имя владельца ресурса в поле имени Владельца. Владелец – человек, которому адресуются запросы от других пользователей. Введите имена пользователей, которым позволяется резервировать этот ресурс в списке имен. |
|
Temporarily disable reservations |
Щелкайте, чтобы временно запретить резервирование ресурса с использованием почтовых файлов. Если это поле отмечено, пользователи могут все еще резервировать ресурс вручную в базе данных Resource Reservations. |
* Сохраните и закройте документ.
Создание ECL для рабочей станции
* Из клиента Domino Administrator, выбирайте закладку – Файлы.
* Из панели Сервера, выбирайте сервер, с которым хотите работать.
* Открывайте Domino Directory (NAMES.NSF).
* Выбирайте из меню Действия – Edit Administration ECL.
* Выбирайте – Default - и затем выбирает опции доступа.
* Выбирайте – No Signature - и затем выбирайте опции доступа.
* Выбирайте – Добавить, введите имя пользователя или сервера и затем - OK.
* Введите звездочку (*), чтобы позволить доступ всем пользователям, даже тем которые не внесенные в “Domino Directory”. Введите звездочку (*) сопровождаемую именем сертификатора - например, */Acme - чтобы позволить только пользователям сертифицированным иметь доступ.
* Позволяйте пользователям изменять ECL на их рабочий станциях, или позволяют Java applets от доверенных отправителей. Выбор Позволяет пользователям изменять и выбирать соответствующий выбор.
* Выбирайте - OK.
Запрещение опций безопасности для рабочей станции.
Если Вы работаете в хорошо защищенной среде, Вы можете запретить акция безопасности данных на рабочей станции. Однако, знайте, что после того, как Вы запретите ECL на рабочей станции, данные окажутся уязвимы для вмешательства из вне.
Чтобы запретить опцию безопасности на рабочей станции. Нужно изменить администраторские настройки ECL. Разрешите в ECL все опции, для типа подписей -Default-, -No Signature-, Lotus Notes Template Development/Lotus Notes и других имен подписей внесенных в список.
Обновление ECL для рабочей станции.
Если Вы изменяете, административные настройки ECL после пользовательской установки, которая автоматически копирует ECL на их рабочие станции, Вы можете заменить ECL.
* Удостоверитесь, что Domino Directory, с изменениями ECL реплицировалась по домену.
* Напишите записку пользователям, чьи ECL Вы изменили.
* Добавьте кнопку в записку, которая выполнит формулу при нажатии.
RefreshEcl (" "; " ")
* Опишите цель записки и инструктируйте пользователей, что делает эта кнопка.
* Отправьте записку пользователю.
Создание файла Key Ring и сертификата СА
Вы используете сертификат CA, чтобы подписать сертификаты для сервера и клиентов и добавлять цифровую подпись CA к сертификатам клиента и сервера. Сертификат CA хранится в файле Key Ring, который является двоичным файлом, который защищен паролем.
Когда Вы используете клиента Domino Administrator, чтобы создать файл Key Ring, он по умолчанию сохраняется в каталоге данных клиента. Если Вы будете использовать других клиентов, чтобы одобрять и подписывать запросы клиентов, рассмотрите перемещение файла Key Ring на сетевой диск или дискету. Это гарантирует, что он будет доступен для других клиентов.
Удостоверитесь, однако, что Вы держите файл Key Ring в безопасном месте. Чтобы предотвратить неправомочный доступ. Только администраторы, которых Вы определяете, должны иметь доступ файлу Key Ring и его паролю.
Создание файла Key Ring и сертификата СА.
* Удостоверьтесь, что Вы установили Domino Application Authority Certificate.
* Из клиента Domino Adminstrator, выбирайте закладку Файлы, откройте базу данных Domino Application Authority Certificate.
* Выбирайте опцию – Create Certificate Authority Key Ring & Certificate.
* Заполните эти поля:
| Поля | Значения | ||
| Key ring file name | Имя файла.
По умолчанию - CAKEY.KYR сохраняется в каталоге данных клиента Domino Administrator. | ||
| Key ring password | Пароль - 12 символов рекомендуется. | ||
| Password verify | Повторный ввод пароля, для проверки. | ||
| Key Size | Размер пары публичного и личного ключа. Чем больше размер, тем более сильное шифрование. Если Вы используете международную версию Domino, только размер - 512 бит доступен. | ||
| Common name | Наглядное имя, которое идентифицирует сертификат CA
Пример, Acme SSLCA. | ||
| Organization | Имя Организации владельца сертификата.
Используйте имя компании. | ||
| Organizational Unit | (Выборочно) Имя отдела владельца сертификата. | ||
| City or Locality | (Выборочно) Город. | ||
| State or Province | Штат, край, область. | ||
| Country | Страна. |
Обратите внимание, на общее имя организации, орг. единицы, город, государство или область и страну, при составлении CA сертификата. Выбирайте имя CA тщательно. Это - дорогостоящий процесс, чтобы переиздавать сертификаты, если Вы изменяете имя.
* Нажмите на кнопку – Create Certificate Authority Key Ring.
* После того, как Вы прочитаете, информация относительно файла Key Ring и имени CA, выбирайте – OK.
* Сделайте резервную копию файла Key Ring и храните его в безопасном месте.
Примечание, чтобы управлять приложением Domino Application Authority Certificate с рабочей станции, создайте копию файла Key Ring, и распределите его по рабочим станциям. Рассмотрите вопрос размещения файла Key Ring на сетевом диске, на который могут получить доступ только администраторы. Вы должны определить местоположение файла Key Ring в Domino профиле Application Authority Certificate по умолчанию.
Изменение пароля для файла Key Ring.
Чтобы использовать длительное время сертификат из соображений безопасности файла Key Ring, периодически изменяйте для него пароль.
* Из клиента Domino Adminstrator, выбирайте закладку Файлы и откройте базу данных Domino Application Authority Certificate.
* Выбирайте представление - View Certificate Authority Key Ring, потом нажимайте – Change CA Key Ring Password
* Введите старый пароль, и затем выбирайте – OK.
* Введите новый пароль, по крайней мере, 12 символьный, и затем – OK.
Создание файла сервера Key Ring
Прежде, чем Вы запросите сертификат от CA, Вы должны создать файл сервера Key Ring, чтобы хранить сертификат. Key Ring файл - двоичный файл, который защищен паролем. Он сохраняется на жестком диске сервера. Когда Вы создаете файл сервера Key Ring, Domino производит сертификат сервера, без отметки сертификатора. Сертификат сервера без отметки сертификатора не имеет силу, пока CA не подпишет его.
Каждый сертификат сервера SSL имеет уникальное имя, оно используется для SSL связей. Когда Вы создаете файл сервера Key Ring, Вы определяете это имя. Хотя некоторые компоненты имени необязательные, чем большее количество компонентов Вы включаете в него, тем меньшее вероятность, что Вы столкнетесь с идентичным именем в другом месте в интернете.
* Удостоверится, что Вы создали базу данных Server Certificate Admin.
* Из клиента Domino Administrator, выбирайте закладку Файлы, откройте базу данных Server Certificate Admin.
* Выбирайте – Create Key Ring.
* Заполните эти поля:
| Поле | Значение | ||
| Key Ring File Name | Имя файла
По умолчанию KEYFILE.KYR. Примечание. Название Key Ring файла появится на закладке Ports – Internet Ports, Server документа. Если вы изменяете имя по умолчанию, Вы должны редактировать Server документ. | ||
| Key Ring Password | Пароль - 12 символов | ||
| Key Size | Размер 512-бит | ||
| Common name | Полное имя TCP/IP хоста, включая домен
Пример: www.lotus.com | ||
| Organization | Название Организации - Acme. | ||
| Organizational Unit | (Optional) Отдел в организации. | ||
| City or Locality | (Optional) Город | ||
| State or Province | Штат, провинция | ||
| Country | Страна |
* Выбирайте – Create Key Ring.
* После того, как Вы прочитаете, информация относительно файла Key Ring и увидите его имя, выбирайте – OK. Notes создает файл Key Ring и разместит, его в каталоге данных Notes на локальном компьютере клиента.
* Скопируйте файл Key Ring в каталог данных на сервер.
Создание групп новостей
Группы новостей могут быть созданы автоматически на Вашем Domino сервере с запущенной службой NNTP. Вы можете также использовать этот метод, чтобы создать вручную группы новостей. При назначении имени групп новостей, Вы не можете использовать пробелы, ?, !, [], или *. Для частных групп новостей, Вы не можете использовать категории USENET.
USENET использует иерархию, чтобы организовать группы с главной темой. Каждая группа новостей имеет собственное имя, в которое включено одно или большее количество частей, отделенное точкой. Имя группы новостей всегда начинается с имени иерархии. Например, группы новостей для вопросов пользователей о системе USENET, может называться news.newusers.questions, где news - иерархия, newusers - первая категория, questions - подкатегория.
USENET иерархии - comp, misc, news, rec, sci, soc, chat, alt ...
Создание групп новостей.
Прежде, чем Вы создаете группу новостей, Вы определяете документ профиля для базы данных. В этом документе, Вы определяете, является ли группа новостей публичная или частная. Вы определяете права доступа для частных групп новостей.
Вы должны сохранить документ профиля базы данных прежде, чем Вы исполняете шаги по созданию групп новостей. Сохраните документа профиля базы данных, позволяет показать группу новостей, NNTP клиентам, клиентам Notes 4.6 и выше и Web пользователям.
В документе профиля базы данных, заполните эти поля и сохраните документ.
| Поле | Значение | ||
| Database Profile editors | Имена пользователей, кому позволяют изменить профиль Базы данных.
По умолчанию - имя создателя групп новостей. Пользователи, чьи имена Вы вводите - получают доступ менеджер к базе данных. | ||
| Private | Выбирайте одно из двух:
* Private – частная группа новостей Если опция не отмечена – публичная группа новостей | ||
| List of users who can access the database | Выбирайте одно из двух:
Введите имена пользователей, которые могут получить доступ к Вашей базе данных. Эти пользователи будут иметь доступ автора к базе данных. | ||
| Moderated | Выберите пользователя – модератора для частных групп новостей и затем заполните эти поля:
Name of Moderator: - имя пользователя, который отправляет по почте и удаляет статьи новостей. Этот пользователь – назначается редактором в ACL базы данных. E-mail of Moderator: - чтобы использовать адрес для рассылки статей и вопросов к модератору групп новостей. Если Вы оставляете поле незаполненным, Domino создает группу Moderated NewsGroup. |
Вы можете разрешить отображение списка баз данных в каталогах:
Откройте окно свойств базы данных.
Выбирайте закладку - Design и выбирайте свойство - Включить в каталог баз данных.
Настройки ACL для групп новостей.
Вы можете использовать ACL баз данных, чтобы определить уровень доступа пользователей. Например, если Вы даете доступ пользователям интернета к частной группе новостей, определите их доступ базе только на чтение, но дайте доступ автора всем внутренним пользователям. Тогда внутренние пользователи могут отправить по почте статьи в группы новостей, а пользователи интернета могут только читать статьи.
Анонимный доступ к группам новостей.
Для доступа к частным группам новостей или любым группам новостей, к которым не позволяется анонимный доступ, сконфигурируйте NNTP сервис на сервере запрашивать имена пользователей для доступа к серверу новостей.
Автоматическое создание и управление группами новостей, доступных только для чтения.
* От Вашего поставщика USENET, получите файл - аctive, который содержит список всех групп новостей на отдаленном сервере NNTP и указывает, являются ли группа новостей модерируемой, или позволяется ли отправлять статьи по почте.
* Скопируйте этот файл в каталог данных и дайте имя ему - active. Когда Domino сервер с запущенной службой NNTP автоматически создает группу, сервер читает этот файл, чтобы определить, создать ли новую группу новостей с доступом только на чтение, по умолчанию.
Создание и активация базы данных Shared Mail
Когда Вы разрешаете использование базы данных Shared Mail, Domino устанавливает переменную Shared_Mail, из файла NOTES.INI - в значение 2 (два). Определение этого значения разрешает доставку и передачу почты в базу Shared Mail. Domino также автоматически создает файл с именем MAILOBJ.NSF в каталоге данных. MAILOBJ.NSF - файл связи, который всегда указывает на активную базу данных Shared Mail. Router использует установки из нее, чтобы сохранять новые сообщения в базе данных Shared Mail.
* Удостоверитесь, что задача Router запущена.
* Введите в эту команду на консоли сервера:
Tell Router Use SHARED.NSF
Где SHARED.NSF - полное название базы данных Shared Mail, которую Вы будете использовать. Если база данных находится в подкаталоге, включите в эту командную строку путь к каталогу. Если файл, еще не существует, Domino используя это имя, создаст его.
Создание и модификация групп
Вы можете создавать и изменять группы из клиента Domino Administrator. Вы также можете использовать Web Administrator, чтобы создавать и изменить группы. Вы можете включать одну или большее групп в пределы существующей группы, то есть создать группу и затем добавить одну или большее количество существующих групп, как членов новой группы. Для маршрутизации почты, Вы можете включать до пяти уровней групп. Для всех других целей, Вы можете включать до шести уровней групп.
Для создания Группы.
* Удостоверитесь, что Вы имеете доступ Редактора или роль GroupCreator к Domino Directory на сервере.
* Из клиента Domino Administrator, выбирайте закладку – Пользователи и Группы.
* Из панели Серверов, выберите сервер, чтобы работать с ним.
* Выбрать Domino Directory и затем выберите – Группы.
* Выбирайте – Создать.
* Введите название группы в поле Названия группы. Используйте любые из этих знаков: А-Z, 0-9, (амперсант, черта, пробел, подчеркивание, апостроф) для Имени. Название Группы может быть максимум 64 символов по длине. Для более легкого администрирования, используйте Имя без пробелов. Не используйте Имена, которое уже используются как название Орг. Единиц в иерархической схеме имен.
* Выбирайте тип группы.
Тип групп определяет цель группы и определяет представление в Domino Directory, где название группы появляется.
|
Тип групп |
Описание |
|
Многоцелевая |
Универсальная группа для использования в mail, ACLs и т.д. |
|
Управление доступом |
Используется только для ACLs |
|
Почта |
Используется только для почты |
|
Только серверы |
Используется только для Групп Серверов |
|
Отказ в доступе |
Используется только для запрещения доступа. Administration Process не может удалить эту группу. |
* Выбирайте кнопку Члены, выбирайте пользователей, сервера или группы, выбирайте – Добавить и затем - OK.
* Выбирайте – Сохранить и Закрыть.
Создание и настройка сообщений Web сервера
*
Удостоверится, что Вы уже создали базу данных Domino Configuration.
* После того как Вы определяете, какая база данных будет хранить настроенные сообщения, откройте базу данных и создайте форму, которая содержит сообщение для показа.
* Если Вы настраиваете, сообщение для виртуального сервера, в свойствах формы для формы, выбирайте - Available to Public Access users, на закладке безопасности.
* Сохраните форму.
* Повторите описанные шаги для каждой документа ответа, на каждую ошибку, для которого Вы хотите настроить страницу сообщения.
* В базе данных Domino Configuration, выбирайте – Create – Mapping Error Message.
* Если Вы настраиваете, сообщение для виртуального сервера, выбирайте – Virtual Server Settings и введите IP адрес сервера.
* (Необязательно) Введите любые комментарии.
* Для каждого типа ошибки или ответа, введите имя базы данных, которая содержит форму, которую Вы хотите показать в поле Target Database file name.
* Для каждого типа ошибки или ответа, введите имя формы, которую Вы хотите показать в поле Target Form name.
* Сохраните документы Error Message и Response Mapping.
* В ACL базы данных, которая содержит формы, введите доступ автора на сервере, который хранит базу данных.
Создание и поддержка групп новостей
После того, как Вы создаете группы новостей, Вы должны регулярно архивировать и удалять статьи, также как и исполнять другие задачи обслуживания для баз данных.
Создание и разрешение использования дополнительной базы данных Shared Mail
Задача Object Collect, которая запускается ежедневно и производит чистку устаревших сообщений, ограничивая рост базы данных Shared Mail. Поэтому, Вы не должны создавать дополнительных баз данных Shared Mail пока имеются достаточно свободного места на диске.
Вы можете создать дополнительную базу данных Shared Mail на сервере, если размер базы данных Shared Mail становится слишком большим, или если Вы хотите связать определенные файлы почты с определенной базой данных Shared Mail. После того, как Вы создаете новую базу данных Shared Mail, она будет, хранит все новые сообщения. Старые, существующие сообщения будут находится в старой базе данных.
* Введите эту команду на консоли сервера:
Load Object Create NEWOBJ.NSF
Где NEWOBJ.NSF - имя новой базы данных Shared Mail. Если необходимо, Вы можете также определить полный путь ней. Для простоты управления, держите все базы данных Shared Mail в одном каталоге.
* Используйте команду Link, для связи почтовых файлов с новой базой Shared Mail.
Создание ID сертификатора для Орг единицы
Когда Вы создаете ID сертификатора для орг. единицы, Вы должны иметь под рукой иерархическую схему имен для Вашей компании. Схема имен помогает Вам определить какой ID сертификатора использовать, чтобы создать дополнительный ID сертификатора. Также, Вам понадобится ID сертификатора, который хотите использовать. В большинстве случаев Вы используете ID первого сервера, созданный при установке сервера.
* Из клиента Domino Administrator, выбирайте закладку – Настройка.
* Из панели инструментов – Сервис – Регистрировать – Подразделение.
* Вводят пароль для ID сертификатора и ОК. Пароль для ID сертификатора, который вы используете, чтобы создать ID сертификатора для орг. единицы.
* Для изменения ID сертификатора, из окна Регистрация заверителя подразделения, нажмите кнопку Заверитель. Выбирайте нужный ID сертификатора, вводите пароль и ОК
Рис. 18 Диалоговое окно регистрации орг. единицы сертификатора.
* Изменяют сервер регистрации (если необходимо).
* Заполните поля окна Регистрация заверителя подразделения, выбирайте – Регистрировать.
* В целом процедура очень похожа на процедуру регистрации ID для организации, но есть и отличие. При регистрации Вы можете изменить сертификат, которым будете сертифицировать создаваемый ID.
Создание ID сертификатора для Организации
Программа Domino Setup создает ID сертификатор для организации, когда первый сервер в домене установлен и сконфигурирован. Вы можете создать другой ID сертификатор, чтобы далее дифференцировать имена или более легко администрировать сервера и пользователей.
* Из клиента Domino Administrator, выбирайте закладку Настройка.
* Из панели инструментов Сервис – Регистрировать – Организация.
(Необязательно) Изменить регистрационный сервер (сервер, который будет хранить документ Сертификата в Domino Directory), выбирайте – Регистрационный Сервер, выбирайте нужный сервер и затем – ОК. Если Вы не определили регистрационный сервер, это будет сервер – по умолчанию:
* Локальный сервер, если он содержит Domino Directory
* Сервер, указанный в переменной NewUserRegServer в NOTES.INI
* Сервер Администрирования
* (Необязательно) Щелкайте на кнопке Файла учетной записи, если Вы хотите изменить местоположение ID файла. Убедитесь, что сохраняете ID в безопасном месте. по умолчанию ID сохраняется в каталоге c:\.
* Заполните эти поля:
Рис. 17 Диалоговое окно регистрации сертификатора.
| Поле | Содержание | ||
| Организация | Имя Организации. Введите Имя Организации из ID сертификатора созданного при создании первого сервера. | ||
| Код страны | Код страны. | ||
| Пароль | Пароль для ID. | ||
| Минимальное значение пароля в знаках | Минимальное количество знаков в пароле, по умолчанию 10 знаков. | ||
| Тип защиты | Выбирайте тип лицензии:
* Универсальная (по умолчанию). * Для Северной Америки. Обратите внимание, начиная с версии 5.0.4, используется тип лицензии Global, которая приравнивается к Северо-Американскому типу лицензии. | ||
| Направлять запросы на заверение (Имя администратора) | Имя администратора, который обращается с запросом на сертификацию. Имя указанное здесь, появляется в документе Сертификатор в Domino Directory. Если Вы создаете ID сертификатора для администратора, введите имя этого администратора в это поле. | ||
| Комментарии | Комментарий. | ||
| Размещение | Необязательный текст, который появляется в поле Location документа Certifier. |
* Щелкайте – Регистрация.
Создание кластера серверов Domino
Прежде, чем Вы создаете кластер, выполняете следующие задачи:
* Определите сервера, которые будут входить в кластер и их названия.
* Установите или модернизируйте программное обеспечение до Domino R5, с лицензией Enterprise Server на каждом сервере. Эта лицензия позволяет Вам установить сервера Domino R5 в кластер.
Примечание. Вы можете включать сервера в кластер и версии Domino R4.5, R4.6 с лицензией Advanced Services и Domino 4.62 с лицензией Enterprise Server. Однако эти сервера не будет иметь доступа к новым функциям кластера, которые появились в Domino R5.
* Убедитесь, что Вы рассмотрели требования для кластера и что все сервера отвечают этим требованиям.
* Распределите базы данных и реплики на серверах, которые Вы планируете включать в кластер.
* Наметьте репликации между серверами кластера
Чтобы создавать кластер, Вы должны иметь, по крайней мере, доступ автора, с правом удаления документов в Domino Directory и, по крайней мере, доступ автора в базе данных Administration Requests. Если возможно, использование сервер администрирования при создании кластера. Это заставит быстрее обрабатывать запросы администрирования. Сервер администрирования не должен быть частью кластера.
Обратите внимание. Если сервера принадлежат различным кластерам, Вы не должны удалить их из этих кластеров. Cluster Administration Process сначала удалит сервер из первоначального кластера, а затем добавит его к новому кластеру.
* Из клиента Domino Administrator удостоверитесь, что сервер администрирования или другой сервер является текущим.
* Выбирайте закладку Настройка.
* Выбирайте сервер, который Вы хотите добавить к кластеру.
* Нажмите кнопку Add to Cluster.
* На запрос выбора кластера, выбирайте – Create New Cluster, затем – OK.
* Введите имя нового кластера и нажмите – OK.
* Выбирайте - Да, чтобы добавить серверу к кластеру немедленно, или выбирайте – Нет, чтобы предоставить процессу администрирования, добавить сервер к кластеру.
Создание конфигурации Cross-Domain и необходимых для этого документов
Чтобы использовать Cross-Domain запросы администрирования, Вы должны создать эти документы в дополнение к Server документу:
* Документы Cross-Сertificate для доменов.
* Документ подключения, позволяющий серверу соединяться с другим указанным сервером, в этом случае, другим сервером домена.
* Один или большее количество Cross-Domain документов конфигурации для каждого домена, из которого Вы импортируете запросы администрирования и в который Вы экспортируете запросы администрирования.
* Вы также должны добавить имя Anyone, чтобы создать документ конфигурации Cross-Domain, в поле List of administrators who are allowed to create Cross Domain configuration documents in the Administration Process Requests database, в документе профиля для Domino Directory. Если администратор пытается обрабатывать запрос между доменами, и имя администратора не будет внесено в список документа профиля, для Domino Directory, запрос администрирования будет терпеть неудачу.
База данных Administration Requests содержит документы конфигурации Cross-Domain, которые определяют, как обмениваются домены информацией, и обрабатывает запросы администрирования. Когда Вы конфигурируете документ конфигурации Cross-Domain, Вы определяете доверенные объекты. Доверенное лицо может быть человек, сервер или сертификатор. Все запросы, полученные из домена, должны быть подписаны одним из доверенных объектов. Запросы переименования - исключение; они подписаны сертификатором, так что их законность определена в соответствии с сертификатом и документами Cross-Domain при получении Domino Directory домена.
Для запросов переименования, на сервере получателе в другом домене, должны иметься соответствующие взаимные сертификаты между иерархией доменов. Дополнительно Domino Directory назначения домена должен иметь документы Certifier, с публичным ключом сертификатора, для орг. структуры, представленной в запросе изменения имени.
* Выбирайте из меню Действие – Edit Directory Profile.
* В поле List of administrators who are allowed to create Cross Domain Configuration documents in the Administration Process Requests database введите имена любых людей, которым позволяется создавать документы конфигурации Cross-Domain.
* Сохраните и закройте документ.
Создание Cross-Domain документа конфигурации.
* Удостоверитесь, что Вы уже создали необходимый документ подключения, чтобы позволить связь между серверами.
* Из клиента Domino Administrator, выберите Файл – База данных – Открыть.
* Выбрать сервер, затем выберите Administration Requests (ADMIN4.NSF) и щелкайте - OK.
* Выбирайте – Add Configuration.
* На закладке Configuration выберите одно из двух:
· Outbound, чтобы создать outbound конфигурацию.
· Inbound, чтобы создать inbound конфигурацию.
Если Вы выбрали - Outbound, заполните эти поля и затем сохраните документ:
|
Поля |
Значение |
|
Domain to submit AdminP requests to |
Имя домена или нескольких доменов, которым этот сервер пошлет запросы |
|
List of AdminP requests to submit |
Выберите тип запросов, которые этот server пошлет |
|
List of approved signers |
Имена подписывающих лиц - то есть доверенное лицо для типа запроса из домена создающего запрос. Подписывающее лицо должно быть менеджером Domino Directory и должно быть внесено в список в документ профиля, на наличие разрешения создавать взаимные документы конфигурации домена. Запрос на Create Replica требует, чтобы автор запроса на сервере источнике имел право на создание реплики на сервере назначения. Запрос Delete Requests, должен быть подписан, администратором домена источника. Запросы на Create Replica, должны быть подписаны сервером источником. |
|
Only submit Create Replica requests to the domains listed above if the destination server is one of the following |
Имя сервера, которому Вы пошлете запросы на создание реплики. Имя сервера должно быть в этом поле, и поле Domain to submit AdminP requests to. Эти поля показывают, что выбран запрос на Создание реплики. |
|
Поля |
Значения |
|
Receive AdminP requests from domains |
Введите имя одного или нескольких доменов, от которых этот сервер будет получать запросы |
|
List of AdminP requests allowed from other domains |
Выберите типы запросов, которые этот сервер примет от других доменов |
|
List of approved signers |
Имена подписывающих лиц - то есть доверенное подписывающее лицо для типов запроса домена назначения. Подписывающее лицо должно быть менеджером в Domino Directory и должно быть внесено в поле документа профиля, для разрешения создать взаимные документы конфигурации домена. Запросы на Create Replica требуют, чтобы автор запроса имел на сервере источнике, доступ создания реплик на сервере назначения. Запросы Delete Requests, должен быть подписан администратором домена источника. Запросы на Create Replica, должен быть подписан, сервером источником. |
|
Only allow Create Replica requests if intended for one of the following servers |
Имя сервера в Вашем текущем домене, который примет, запросы на реплики от других доменов. Эти поля показывают, что выбран запрос Create Replica. |
Создание короткого имени Notes (Short Names) для пользователей WindowsNT
Вы можете генерировать короткие имена Notes, для импортированных пользователей, основываясь на их именах в WindowsNT. По умолчанию имя пользователя WindowsNT будет добавлено как в поле Short Names и документы Person пользователя, но Вы его можете изменить в окне параметров пользователя перед регистрацией.
Short Name - по умолчанию назначается как имя почтового файла и ID файла пользователя.
Если Вы не выбрали значение для Short Name, Notes назначает Short Name первую букву имени пользователя, плюс первые семь букв фамилии, например ssalani, для Пользователя Susan Salani.
Создание нового публичного ключа Notes и добавление его в Domino Directory
Создание и сертификация нового публичного ключа требует следующих процедур, которые описаны ниже:
* Пользователь создает новый публичный ключ и представляет его для сертификации.
* Администратор Сертификатор - сертифицирует публичный ключ пользователя и добавляет его в Domino Directory.
* Пользователь сливает новый сертификат в ID файл пользователя.
Создание нового публичного ключа Notes.
Владелец ID исполняет эти шаги.
* Выбирайте Файл – Сервис – Учетная запись.
* Ведите пароль (если требуется).
* Выбирайте – Дополнительно – Создать общий ключ.
* Когда Вы видите, предупреждение, что на создание ключа потребуется время, нажимайте – OK, чтобы продолжить.
* Выбирайте адрес администратора или сертификатора для сертификации или адресуйте записку напрямую сертификатору - например /East/Acme. Domino отправляет запрос человеку, обозначенному в секции администрирования, соответствующего документа сертификата в виде Сертификаты из Domino Directory.
* Выбирайте – Отправить.
Ресертификация ID и добавление публичного ключа в Domino Directory.
Администратор - Сертификатор исполняет эти шаги.
* Открывает почтовый запрос сертификации.
* Выбирайте – Действие – Заверить вложенную учетную запись.
* Выбирайте ID сертификатора для использования и нажимайте – OK.
* Введите пароль для ID и нажимайте – OK.
* Выбирайте – Заверить.
* (Необязательно) Выбирайте - Сервер, для выбора сервера и нажимайте – OK, чтобы изменить сервер регистрации. Регистрационный сервер - сервер, чей Domino Directory будет обновлен.
* (Необязательно) Измените дату истечения сертификата.
* (Необязательно) Определяйте минимальную длину пароля.
* Выбирайте – Заверить. Имя ID владельца появляется в поле Кому:, объяснительный текст появляется в поле Тема: окна сертификации, для отправки заверенной учетной записи.
* (Необязательно) Выбирайте – Подписать, чтобы доказать, что Вы - отправитель ID.
* Выбирайте – Отправить.
Принятие нового сертификата в ID файл.
ID владелец исполняет эти шаги.
* Открывает почтовый запрос сертификации.
* Выбирайте – Действие – Принять сертификат. В окне будет показана информация о новом ключе и сертификаторе, который заверил ID
Проверка публичного ключа Notes.
Проверка публичных ключей Notes сохраненных в Domino Directory помогает предотвращать неправомочного пользователя или сервер от вызова другого сервера.
* Из клиента Domino Administrator, выбирайте закладку Настройка, откройте Server документ для сервера.
* Выбирайте закладку Security.
* В секции Security Sittings, выбирайте – Yes, в поле Compare Notes public keys against those stored in Directory.
* Сохраните документ.
* Перезапустите сервер, чтобы изменения вступили в силу.
Создание Person документа, для клиентов интернет, с использованием SSL идентификации клиента
В Domino Directory на Вашем Domino сервере, создайте Person документы для клиентов интернета, использующих идентификацию SSL, чтобы соединиться с Domino сервером. Person документ для клиента хранит публичный ключ клиента, который используется, чтобы проверить идентичность клиента интернет. Person документ также содержит список имен, который Domino сервер может использовать, чтобы идентифицировать клиента интернета. Когда клиент интернета пробует соединяться с сервером, Domino ищет имя, интернет сертификат в поле Person документа клиента. Domino сравнивает публичный ключ, представленный ему, с сохраненным в Person документе. Сравнение публичного ключа позволяет Domino подтверждать подлинность пользователя, даже если имеются несколько пользователей с тем же самым именем, так как каждый публичный ключ уникален. Если Domino находит совпадение и публичный ключ имеет силу, то первое имя, внесенное в список имени пользователя, используется, чтобы проверить ACL баз данных и списки доступа к модулям.
Например. Если Person документ пользователь в поле имени, содержит эти имена: Alan Jones, Ajones, Alan, Al Jones, а клиент использует имя Al Jones для доступа на сервер, Domino идентифицирует пользователя, проверяет публичный ключ представленный ему, с использованием публичного ключа из Person документа. Domino использует имя Alan Jones, чтобы проверить ACL баз данных и списки доступа к модулям.
Настройка Person документа.
* Создайте новый Person документ в Domino Directory.
* Введите в Ф. И. О. в соответствующие поля.
* Введите в поле User Name имя пользователя, так как оно определено в сертификате.
* (Необязательно) Вводят дополнительную информацию относительно клиента на закладках Work/Home
* Сохраните документ.
Примечание, если клиент хочет использовать сертификат на Domino сервере в другом домене, Вы должны добавить Person документ в Domino Directory для этого домена. Убедитесь, что Вы создали и настроили базу данных Master Address Book (Directory Assistance), так что Domino может находить клиента в Domino Directory для этого домена.
Создание почтового файла для пользователя IMAP вручную
Каждый IMAP пользователь должен иметь почтовый файл на Domino сервере. Вы можете создавать почтовые файлы автоматически, в течение регистрации пользователя, или Вы можете вручную создавать почтовые файлы. Если пользователь, уже зарегистрирован как пользователь Notes, пользователь может использовать IMAP клиента для доступа к почтовому файлу.
Создание почтового файла вручную:
* Удостоверитесь, что Вы создали Person документ, для IMAP пользователя.
* Выбирайте из меню Файл – База данных – Новый.
* Определите настройки пользователя:
| Поле | Значения | ||
| Server | Имя почтового сервера. | ||
| Title | Описание почтового файла, например: Alan Jones's Mail. | ||
| File name | Путь к файлу пользователя (MAIL\AJONES.NSF). |
* Выбирайте почтовый шаблон MAIL50.NTF …
Создание почтового файла для пользователя POP
Каждый POP3 пользователь должен иметь почтовый файл на Domino сервере. Вы можете создавать почтовые файлы в течение регистрации пользователя, или Вы можете вручную создавать почтовые файлы. Если пользователь уже зарегистрированный пользователь Notes и имеет существующий почтовый файл Notes, чтобы использовать POP3 систему, пользователь может использовать POP3 клиента для доступу к файлу почты.
Вы можете иметь зарегистрированных пользователей Notes, которые не используют почту Notes. Поэтому Вы должны создать новый почтовый файл для этих пользователей.
Создание почтового файла - в ручную.
* Убедитесь, что Вы создали Person документ для пользователя POP3.
* Выбирайте из меню Файл – База данных – Новый.
* Определите настройки для почты пользователя:
| Поле | Значение | ||
| Server | Имя почтового сервера. | ||
| Title | Описание почтового файла.
Пример: Alan Jones' Mail. | ||
| File name | Путь к файлу пользователя.
Пример: MAIL\AJONES.NSF |
* Выбирайте шаблон для почтового файла - МAIL.NTF.
* После создания почтового файла отредактируйте ACL базы данных. Присвойте доступ менеджера с удалением документов будущему пользователю. Удалите свое имя из ACL, если это необходимо.
Создание представления $AdminP
По умолчанию, Administration Process просматривает все документы в базе данных, ищет значения полей Readers And Authors, когда Administration Request обрабатывает запрос, значения этих полей будут получены. Администраторы и менеджеры базы данных могут создавать представление в базе данных, с ограниченным доступом и отображением полей Readers And Authors. Представлению должно быть назначено имя – $AdminP.
Создание приложения Domino Certificate Authority
* Удостоверьтесь, что Вы уже установили сервер как Domino Web сервер.
* Используя клиента Domino Designer, создайте базу данных Domino Application Authority Certificate на сервере, с использованием шаблона Authority Certificate - CCA50.NTF. Чтобы найти файл шаблона, выбирайте опцию - Показать дополнительные шаблоны.
* Редактируйте ACL базы данных Domino R5 Authority Certificate, следующим образом:
· Добавьте в ACL имена администраторов, которые будут выпускать, и управлять сертификатами интернета. Назначите им доступ редактора с правом удаления документов и роль [CAPrivlegedUser].
· Установите доступ по умолчанию – автор, с созданием документов.
Примечание, чтобы скрыть базу Domino Application Authority Certificate, из окна просмотра баз данных, когда пользователи выбирают меню Файл – База данных – Открыть, или когда Web клиенты, просматривает список базы данных, отмените опцию - Отображать в окне Открытие баз данных, в свойствах Базы данных.
Создание схемы иерархических имен серверов и пользователей
Сервер, организация, организационная единица, и имя пользователя может состоять из знаков верхнего регистра и нижнего, алфавитных знаков (А-Z), чисел (0-9), амперсанта (&), черточки (-), точки (.), пробела ( ), подчеркивания (_).
Иерархические имена используют следующие компоненты:
| Компоненты | Описание | Требуется знаков | |||
| Common name (CN)
Имя | Сервер или имя пользователя. Используется полное имя и фамилия для имени пользователя – для примера, Julia Herlihy. | Не более 80 знаков | |||
| Organizational unit name (OU)
Орг. Единица | Департамент или местоположение – для примера, East/Acme.
Применяется по желанию. | 32 знака для орг. Единицы | |||
| Organization name (O)
Имя организации | Имя компании – для примера, Acme. | 3 – 64
Не включайте в название компании признак страны. | |||
| Country (C)
Признак страны | Аббревиатура для страны – для примера, US.
Применяется по желанию. | 0 – 2 |
Пример иерархического имени, которое использует все компоненты:
Julia Herlihy/Sales/East/Acme/US
Типично, имена показываются в сокращенном формате, но они сохранятся внутри в каноническом формате, который является форматом, который содержит имя и связанные компоненты:
CN=Julia Herlihy/OU=Sales/OU=East/O=Acme/C=US.
Прежде, чем Вы назначаете серверам или пользователям иерархические имена, Вы должны спланировать схему обозначения организации.
Планирование схемы имен в организации.
Чтобы применять иерархические имена, Вы должны создать схему Вашей компании. Используйте эту диаграмму, в качестве примера, для планирования схемы имен. Иерархическая схема имен может использовать структуру дерева, которая отражает фактическую структуру Вашей компании. Наверху дерева - название организации. Ниже приведена схема имен в организации и орг. единиц, которые Вы создаете, чтобы отобразить структуру компании; Вы можете организовывать структуру по географическим признакам, по департаментам, или по обоим признакам.
В предыдущей главе мы уже говорили, что компания Acme создала эту диаграмму для серверов и пользователей:
Рис. 15 Пример дерева сертификатов для организации Acme.
Просматривая рисунок, Вы можете видеть, где расположены сервера и пользователи в дереве имен. Acme решил базировать компанию по географическим признакам, на первом уровне, и создать ID сертификаты для орг. единиц – East и West. На следующем уровне Acme сделал разделение сертификаторов, согласно отделов.
Ваша организация - часть одного Domino домена. В некоторых случаях, Вы можете распределить организацию на два или более доменов. Например, если Ваша компания большая, и Вы хотите распределить ответственность за безопасность системы, между несколькими администраторами.
Создание ID Сертификаторов.
Чтобы размещать сервера и пользователей в правильном порядке, в пределах иерархической структуры, Вы создаете ID сертификаторов для каждого узла в дереве Вашей организацией. Сертификат – это штамп в ID пользователей и серверов, свидетельство о том, где они расположены в организации. Сервер и пользователи, которые принадлежат тому же самому дереву, могут связываться друг с другом. Сервера и пользователи, которые принадлежат различным деревьям сертификатов, нуждаются во взаимной сертификации, для связи друг с другом.
Имеются два типа ID Сертификаторов, сертификат организации и сертификат орг. единицы. Сертификат организации расположен наверху Вашего дерева и обычно называется именем Вашей компании - например, Acme. Сертификат орг. единицы во всех ветках дерева расположен по иерархии ниже сертификата организации. В имени пользователя или сервера, он находится левее имени организации - например, East/Acme или Sales/East/Acme.
Чтобы управлять структурой, компания Acme создала ID Сертификаторов для каждого узла в ее организационной диаграмме:
Рис. 16 Имена сертификаторов в организации Acme.
Чтобы регистрировать каждый сервер или пользователя, администратор Acme использует один из этих ID Сертификаторов, в зависимости от того, где этот сервер или пользователь находится в иерархии организации.
Например, чтобы регистрироваться Phyllis Spera, который работает в отделе маркетинга, расположенном на восточном побережье, администратор, использует сертификат Sales/East/Acme.Полное иерархическое имя Phyllis Spera тогда будет Phyllis Spera /Sales/East/Acme.
Точно так же администратор создает HR-E сервер, расположенный на восточном побережье, с использованием сертификата East/Acme. Полное иерархическое имя этого сервера HR-E/East/Acme.
Создание топологии Passthru серверов
Чтобы создавать топологию Passthru серверов, Вам необходимо проделать следующее:
* Составьте список всех рабочих станций и серверов, которые нуждаются в доступе на Passthru сервер. Также внесите в список протоколы для рабочих станций и серверов.
* Составьте список серверов назначений, к которым вы хотите получить доступ. Также внесите в список протоколы для серверов назначения.
* Определите, где в топологии расположить Passthru сервер. Passthru сервер должен иметь все протоколы, которые используют рабочие станции и сервера. Кроме того, Passthru сервер должен иметь достаточное количество модемов.
* Если Вы ожидаете, интенсивное движение через Passthru сервер, создаете Dedicated Passthru сервер. Dedicated Passthru сервер, не содержит ни каких баз данных. Он функционирует исключительно как посредник. Определите, хотите ли Вы использовать больше чем один Passthru сервер в Hunt группе. В Hunt группе, один телефонный номер принадлежит всем Passthru серверам в группе, а нагрузка автоматически распределяется среди Passthru серверами. Все Passthru сервера в Hunt группе, должны уметь соединятся с серверами назначения.
* Определите пользователей и сервера, которым Вы хотите ограничить доступ на Passthru или серверам назначения. Внесите в список всех пользователей и сервера, которым Вы хотите ограничить доступ на Passthru сервера, затем создайте список ограничений для каждого сервера назначения.
* Внесите в список рабочие станции, которые должны использовать Passthru сервер и определите для них Passthru сервер по умолчанию. Если Вы имеете много рабочих станций, равномерно распределяете по станциям Passthru сервера, чтобы гарантировать оптимальную нагрузку на сервер.
* Если Вы планируете использовать Hunt группу, создайте список всех рабочих станций соединяющихся с каждой Hunt группой. Сделайте записи имен и телефонных номеров Hunt групп и имен всех серверов назначения.
Создание взаимного сертификата для пользователя из Person документа
Вы можете создавать взаимные сертификаты Notes и или интернет, из сертификатов, сохраненных в документе Person пользователя.
* Делает одно из следующего:
· Из клиента Domino Administrator, выбирайте закладку - Пользователи и группы и откройте Person документ для пользователя, которому вы хотите создать взаимный сертификат.
· В персональной адресной книге, откройте документ – Контакт, для пользователя, которому хотите создать сертификат
* Выбирайте - Действия – Create Cross Certificate (Создать взаимный сертификат).
* Выбирает сертификат, для взаимного сертификата.
* Заполните эти поля и затем нажимайте – Заверить:
| Поле | Значение | ||
| Certifier | Имя сертификатора ID.
По умолчанию, Ваш сертификатор ID. Если Вы имеете доступ, Вы можете выбирать и другой ID выше Вашего в Вашей иерархии организации. | ||
| Server | Регистрационный сервер, который проводит взаимное сертифицирование.
По умолчанию, сертификат сохраняется локально, в Вашей персональной адресной книге. Вы можете выбирать другой сервер для сохранения взаимного сертификата. | ||
| Subject name | Имя, кто будет сертифицирован. | ||
| Subject alternate name list | Альтернативное имя | ||
| Public Key | Публичный ключ | ||
| Expiration date | Дата истечения взаимного сертификата |
* Повторите эти шаги для каждого пользователя, для которого Вы хотите создать взаимные сертификаты.
Создание взаимных сертификатов интернет для CA
Прежде чем клиент Notes может подтверждать подлинность серверов или посылать шифрованные сообщения S/MIME, клиент должен сначала создать взаимный сертификат для сервера CA и хранить его в персональной адресной книге. Это позволяет клиенту Notes доверять серверам, которые имеют сертификаты, выпущенные этими CA. SSL установление подлинности сервера для клиентов интернет, не требует взаимного сертификата.
Клиент Notes может также создавать взаимный сертификат для сервера, однако, это позволяет клиенту доверять только этому серверу. Если клиент Notes создает взаимный сертификат для сервера, клиент Notes не должен получать Trusted Root сертификат для CA.
Создание взаимного сертификата интернет.
* Удостоверитесь, что CA создал Trusted Root сертификат в Domino Directory.
* Из клиента Notes, откройте документ сертификата в Domino Directory и выберите – Действие – Create Cross Certificate.
* Выбирайте сертификат, для которого Вы собираетесь создать взаимный сертификат.
* Удостоверитесь, что выбрали Локальный компьютер, выбирайте – Заверить.
Просмотр взаимного сертификата интернет.
* Из клиента Notes, откройте персональную адресную книгу.
* Выбирайте представление Параметры – Сертификаты.
* Просмотрите категорию Перекрестные сертификаты интернета.
Создать несколько баз данных MAILBOX
Каждый Domino сервер, использует базу MAIL.BOX, для временного хранения сообщений. Пользователи и сервера используют SMTP или Notes протоколы, чтобы заносить сообщения в базу данных MAIL.BOX, для временного хранения. Router на сервере читает сообщения и доставляет их в почтовые файлы пользователей на этом сервере, или перемещает их в MAIL.BOX на другие сервера.
В предыдущих версиях Domino, Router использовал только одну базу данных MAIL.BOX. В R5 Вы можете продолжать использовать единственную базу данных MAIL.BOX. Вы можете заметно увеличить производительность, для этого создайте несколько баз данных MAIL.BOX. Любой процесс, пробующий записать данные в MAIL.BOX, включая сервер и Router, нуждается в монопольном доступе к этой базе данных. Кроме того, когда Router читает новые сообщения из MAIL.BOX, другие процессы должны ждать, пока база не освободится. Когда у Вас имеется большое количество почты, с тяжелым почтовым трафиком - много время уходит на этот процесс.
При использовании нескольких баз данных MAIL.BOX, Domino использует несколько параллельных процессов. При чтении одного MAIL.BOX, Router помечает эту базу данных признаком - В использовании, так что другие сервера, пробующие занести почту, переходят к следующей базе данных MAIL.BOX. Такой подход значительно улучшает производительность почтовой системы.
При многократной записи в базы данных нередко возникают проблемы с MAIL.BOX, поэтому Вы должны помещать базы MAIL.BOX и почтовые файлы пользователей на различных дисках.
Если Вы добавляете только одну дополнительную базу данных MAIL.BOX, Вы почувствуете увеличение производительности Вашей почтовой системы. Вы получаете дополнительную выгоду от применения каждой дополнительной базы данных MAIL.BOX, хотя общая производительность компьютера уменьшается с каждым дополнительным почтовым ящиком MAIL.BOX.
Примечание. Вы определяет число MAIL.BOX баз данных в документе Configuration Settings. Если Вы используете одну конфигурацию для нескольких серверов, Domino создает число почтовых ящиков установленное в этом документе на каждом сервере.
Для создания нескольких баз данных MAIL.BOX сделайте следующее:
* Удостоверитесь, что Вы уже имеете документ Configuration Settings для сервера(ов).
* Из клиента Domino Administrator, выбирайте закладку – Настройка, откройте секцию - Почта.
* Выбирайте представление – Конфигурации.
* Выбирайте документ Configuration Settings, для почтового сервера или серверов, которым Вы хотите ограничить почту и выбирайте – Edit Configuration.
* Выбирайте закладку Router/SMTP – Basics.
* Заполните это поле и затем сохраните документ:
|
Поле |
Значение |
|
Number of mailboxes |
Число от 1 до 10, чтобы установить число почтовых ящиков для каждого сервера, который использует этот документ конфигурации. По умолчанию - 1 |
Способы поиска адреса в Person документах пользователей
Вы можете определить, как локальные пользователи будут искаться адреса в Domino Directory. Имеются три выбора:
* Fullname only - ищется полное имя SMTP, в Domino Directory (First_Last Acme.com)
* Local Part only
- чтобы искать локальную часть адреса в Domino Directory
* Fullname then Local Part - чтобы искать полный адрес сначала, а затем локальную часть, если не имеется первого.
Обратите внимание, Если Вы заполнили поле интернет адреса в Person документах пользователей для всех Ваших пользователей, выбирайте только – Fullname.
Для выбора способа поиска адресов.
* Удостоверитесь, что Вы уже имеете документ Configuration Settings для сервера(ов).
* Откройте его для редактирования на закладке Router/SMTP – Basics.
* Заполните эти поля и затем сохраните и закройте документ:
| Поле | Значение | ||
| Address lookup | Выбирайте одну функцию:
* Fullname then Local Part - (по умолчанию) искать сначала интернет адрес, а затем локальный. * Fullname only - чтобы посмотреть полный адрес интернета * Local Part only - искать только, для определения адреса Notes пользователя | ||
| Exhaustive lookup | Выбирайте одно:
* Enable - разрешается поиск во всех Directories * Disabled - (по умолчанию) ограничивается поиск только первым Directory. |
Сравнивание серверов (Decommissioning a server)
Вы можете использовать инструмент - Анализа для исключения сервера, когда Вы объединяете существующий сервер, с другим сервером, или удаляете сервер из Вашей системы серверов. Объединяете ли Вы сервера в один сервер, или переименовываете сервер, результат один и тот же - старое имя сервера заменяется на новое. Инструмент анализа может помочь Вам избежать потери сервисов, для Вашего Domino сервера. Инструмент анализа сравнивает исходный сервер с новым сервером назначения и сообщает различия между ними, которые могли причинить возможную потерю служб обслуживания.
Когда Вы запускаете инструмент анализа, из клиента Domino Administrator, Вы создаете базу данных результатов анализ (decomsrv.nsf), содержащую детальную информацию сравнения для двух сравниваемых серверов. Исходный сервер – сервер, который удаляется из обслуживания, и новый сервер - сервер который будет работать вместо исходного сервера, должны быть иерархическими серверами Notes, того же самого домена. Сервера не обязательно должен быть Domino R5 серверами. Только клиент Domino Administrator R5 необходим для использования инструментом анализа серверов.
Несоответствия между сервером источником и целевым сервером будут отмечены в базе данных результатов соответствующими документами. Ознакомьтесь с этими документами прежде, чем Вы исключите сервер из Вашей системы. Каждое сравнение, инструмент анализа делает индивидуально. Поэтому, Вы должны просмотреть каждое сообщение и сделать Ваши собственные выводы перед любыми действиями. Вы можете делать сравнения между двумя серверами в любой момент. Не все различия должны быть решены прежде, чем Вы замените сервера.
Прежде Вы исключите сервер, Вы должны выполнить следующие действия:
* Проверьте каждую базу данных и формулы, которые содержат определенные ссылки на названия серверов
* Проверьте документы из Domino Directory, особенно документы типа Подключения и Programs документы.
* Если старый сервер имел взаимные сертификаты, удостоверитесь, что новый сервер имеет те же самые взаимные сертификаты
* Уведомите другие домены, что доступ на сервер изменяется, в связи с изменением имени сервера
* Сообщите пользователям о новом местоположении баз данных, если это необходимо
* Проверьте протоколы сети на старом и новом сервере
* Реплицируйте все базы данных со старого сервера на новый сервер
* Переопределите таблицы маршрутизации почты, чтобы почта доставляется правильно
Запуск инструмента сравнения серверов.
* Чтобы использовать инструмент сравнения, Вы должны иметь доступ администратора к старому и к новому серверу. Если Вы не имеете права администратора, некоторые части анализа могут быть незавершенны должным образом.
* Из клиента Domino Administrator, выбирайте закладку Сервер – Анализ.
* Из панели инструментов, выбирайте - Сервер – Исключение сервера.
* Заполните следующие поля:
Рис. 73 Диалоговое окно анализа исключений сервера.
* Если Вы не используете имя по умолчанию DECOMSRV.NSF - Заполните эти поля, нажимая кнопку ДБ результатов:
Рис. 74 Диалоговое окно определения места хранения результатов анализа серверов.
* Нажимайте – ОК, затем опять – OK.
Когда анализ завершается, база данных Результатов открывается. Это может продолжаться несколько минут в зависимости от загрузки сети и числа баз данных, на обоих серверах.
Примечание Вы можете создавать несколько сообщений в одной и той же базе данных или в различных базах данных и затем, использует эти сообщения, чтобы проверить, различия между двумя серверами. Вы можете заново запускать инструмент анализа.
Просмотр отчета в базе данных Анализ исключения сервера.
Инструмент сравнения серверов производит список пунктов, которые Вы можете в последствии анализировать. Каждая категория представляет различный аспект конфигурации серверов, который нуждается во внимании. Каждый пункт вносит в список любые различия между серверами. В базе данных Результатов, Вы можете рассматривать список пунктов.
Рис. 75 Пример результата сравнения серверов.
Каждый пункт представлен в соответствии с документом. Статус документа обозначен изображением слева от документа следующим образом:
|
Иконка |
Описание |
 |
Различие было найдено при выполнении сравнений и может требовать внимания администратора |
 |
Ошибка при выполнении или попытке исполнить сравнение |
|
No icon |
Никакое внимание не требуется, потому что сравниваемые поля эквиваленты, источнику |
Рис. 76 Типичный документ отчета, сравнения серверов.
|
Поле |
Описание |
|
Report category |
Секция или категория, которой документ принадлежит. Эти категории: Сертификаты, Кластер, Подключения, Базы данных, Домены, интернет, Инструменты, Сеть, Программы, Безопасность, SMTP и маршрутизаторы. |
|
Report title |
Определенное поле или пункт, который анализируется. Например, Базы данных – Mail Users или Базы данных -- No Matching Replica. |
|
Report date |
Дата генерации отчета |
|
Server to be decommissioned (source server) |
Имя сервера, который будет удален |
|
Server to accept responsibility (target server) |
Имя сервера, который будет выполнять обязанности нового сервера |
|
Errors |
Ошибки, которые происходят в течение анализа в этом пункте или поле. Эта поле не заполнено, если не имеется никаких ошибок. |
|
Report details |
Информация, которая указывает проблему или несогласованность, которая существует между двумя серверами |
Сравнительный отчет.
Следующие типы сравнений полей, выполняемые между двумя Server документами и Configuration Settings документами:
|
Сравниваемые поля |
Описание |
|
Boolean |
Содержание из двух сравниваемых полей должно быть идентично. В некоторых случаях, если поля на сервере источнике нет, никакое сравнение не выполняется для сервера назначения. |
|
Numeric |
Два поля сравняются |
|
Text list |
Два текстовых списка сравниваются и если поля не равны, производится сообщение |
|
Name list |
Два списка имен сравниваются, дубликаты будут удалены, сообщение будет произведено, если источник имеет не полный список. |
|
Special cases |
В некоторых случаях, незаполненные поля имеет специальное значение. В этих случаях, определенная интерпретация незаполненных полей будет учтена, когда сравнения будут выполнены. |
|
Сравниваемые документы |
Описание |
|
Connection document |
Сравнение выполняется на любых Connection документах, где сервер источник, внесен в список в поле Source Server в Connection документах. Сравнение делается, чтобы гарантировать, что все сервера назначения в этих документах также были включены в отчеты связи сервера назначения. Сообщение производится, если задачи отличаются. |
|
Program records |
Все записи программ, которые внесены в список на сервере источнике, включены в сообщение. Никакое сравнение между источником и целевым сервером в отчеты не включаются, потому что не имеется никакого способа гарантировать, что выполняемые программы существуют на сервере назначения. |
|
Domain records |
Все отчеты о документах Foreign Domain проверяются, чтобы видеть имеется ли Gateway сервер для сервера источника. Если сервер найден, будет произведено сообщение, указывая, что в документе Foreign Domain есть сервер посредник. |
|
Cross Certificates |
Любой взаимный сертификат, который имеется на сервере источнике. |
|
Сравниваемые базы данных |
Описание |
|
Mail- in Databases, Rooms, Resources, Certifiers, Person documents |
Каждый документ, который содержит сервер назначения, как почтовый сервер. |
|
Replicas |
Любая база данных на сервере источнике, которая не имеет соответствующей реплики на сервере назначения, будет отображена. Имя файлов для всех баз данных, которые не имеют реплики на сервере назначения, будут отражены в отчете. Любая база данных на сервере источнике, который имеет другое название базы данных, чем название реплики базы данных на сервере назначения будет внесена в список. |
|
Сравнение документов сети |
Описание |
|
Enabled ports |
Сравнение выполняется, для имен портов и протоколов. Сообщение производится для любых различий. |
|
Notes Named Networks |
Если источник и целевой сервер не имеют той же самой Notes поименованной сети, сообщение будут произведены. |
SSL безопасность
Secure Sockets Layer (SSL) - протокол безопасности, который обеспечивает безопасность соединений и установление подлинности для Domino серверов и задач, которые работают по TCP/IP.
SSL предлагает следующие опции безопасности:
* Данные передаваемые от клиентов шифруются в течении всей сессии клиентов.
* Кодируется просмотр сообщения, присоединенных данных, и обнаруживается любое вмешательство в сообщения.
* Сертификат сервера сопровождающий данные утверждает, что сервер тот за кого он себя выдает.
* Сертификат клиента сопровождающий данные утверждает, что клиент тот за кого он себя выдает. Установление подлинности для клиента необязательно.
интернет протоколы поддерживающиеся Domino и SSL.
Вы должны установить Domino сервер и затем настроить SSL. Вы можете использовать безопасность SSL для клиентов интернета, которые используют один из протоколов интернет, чтобы соединиться с Domino сервером:
* Web сервер и Web Navigator (HTTP)
* Network News Transfer Protocol (NNTP)
* Post Office Protocol 3 (POP3)
* Internet Message Access Protocol (IMAP)
* Lightweight Directory Access Protocol (LDAP)
* Simple Mail Transport Protocol (SMTP)
* Internet Inter-ORB Protocol (IIOP)
* The Java applet that uses this protocol must be set up to use SSL.
* Simple Authentication and Security Layer (SASL)
Domino использует SASL автоматически, если SSL настроен для идентифицикации клиента на сервере и если LDAP клиент поддерживает этот протокол. Никакая дополнительная конфигурация не требуется.
SSL и S/MIME для клиентов
Клиенты могут использовать Domino Certificate Authority (CA) или CA других производителей, чтобы получить сертификат SSL. Метод, который Вы будете использовать, чтобы настроить клиента, зависит от следующего:
* Тип Клиента - или Notes или другой клиент интернет
* Тип сертификата CA - Domino CA или другой производитель CA, типа VeriSign
* Требования безопасности для клиента: серверное SSL установление подлинности, SSL установление подлинности клиента, или S/MIME безопасность для сообщений.
Идентификация с использованием SSL клиентом и сервером.
SSL - протокол, используемый Notes и другими клиентами интернета, который шифрует соединения, подтверждает данные и подлинность серверов, идентичность клиента, когда Notes или другой клиент интернет соединяется с интернетом сервером - например, Web сервером или LDAP сервером.
На сервере с настроенным SSL протоколом, Вы можете выбирать разрешение SSL на всех протоколов, или позволять SSL только на некоторых протоколах. Например, Вы можете позволить SSL на протоколах почты IMAP, POP3, SMTP, но запретить его для NNTP.
Вы можете настроить клиента для идентифицикации сервером, или и установление подлинности клиентом и сервером. Как Вы настроите клиента, зависит от того, требует ли сервер устанавливать подлинности, или установление подлинности будут осуществлять клиент и сервер.
Установление подлинности сервером позволяет клиентам проверять идентичность сервера, чтобы удостовериться, что другой сервер не выдает себя за сервер, к которому Вы хотите получить доступу.
Установление подлинности клиентом, позволяет администраторам серверов идентифицировать клиента, обращающегося на сервер и управлять доступом к базам данных, основанным на идентичности клиента.
Например, если Вы хотите, чтобы Alan Jones имел доступ редактора к базе данных, но все другие обращающийся к базе данных, имели доступ автора, Вы можете настроить ACL базы данных, чтобы включить имя Alan Jones как редактор, но предоставить пользователю Anonymous доступ автора.
Вы должны тщательно рассмотреть, хотите ли Вы требовать идентифицикации клиента. Если Вы не должны идентифицировать пользователей интернета, кто имеет доступ на сервер, Вы не должны настаивать установление подлинности клиента. Фактически, в некоторых случаях, требуя интернет сертификат, Вы может запретить пользователям вызов сервера. Если Вы требуете интернет сертификат, пользователь должен исполнить дополнительные шаги, чтобы настроить установление подлинности клиента.
Notes и клиенты интернет, которые используют установление подлинности клиента, имеет интернет сертификаты, которые содержат публичные и личные ключи, имя, дату истечения, и цифровую подпись сертификата. Клиенты Notes хранят интернет сертификаты в Notes ID файле, клиенты интернет хранят интернет сертификаты в локальном файле. Публичный ключ клиента также сохраняется в Domino Directory, так что другие могут получить к нему доступ.
интернет и клиенты Notes могут получить интернет сертификаты или от Domino CA или независимых производителей CA.
Шифрование сообщений с использованием S/MIME.
S/MIME - протокол, используемый клиентами, чтобы подписать сообщения почты и посылать шифрованные почтовые сообщения пользователям почтовых программ, которые также поддерживают S/MIME протокол. IE и Netscape Коммуникатор поддерживают эти функции. Клиент Notes использует интернет сертификат, тот же самый сертификат, используемый для SSL - в Notes ID файле и публичный ключ, сохраненный в Domino Directory, чтобы шифровать и подписывать сообщения.
Клиент Notes должен также иметь публичный ключ каждого получателя в Domino Directory, чтобы послать шифрованные сообщения другим пользователям.
SSL в международных организациях
SSL использует публичные и личные ключи для сессий, которые имеют различные степени шифрования. Лицензия, используемая для сервера, с использованием которой создается сертификат SSL - определяет силу шифрования. Сервер, который использует Северо-Американскую лицензию, имеет более сильное шифрование, чем сервер, использующий международную лицензию.
Публичные и личные ключи.
Каждый сертификат SSL имеет публичный и личный ключ. Эти ключи, которые создаются при создании сертификата SSL, позволяют владельцам сертификата идентифицировать себя по сети и использовать S/MIME, чтобы шифровать и подписывать сообщения.
Сила шифрования, используемого для ключевой пары, зависит от лицензии сервера, или браузера, с использованием которого создавался SSL сертификат. Если сервер или браузер имеет Северо-Американскую лицензию, ключевые пары создаются с использованием шифрования - 1024 бит. Если сервер или браузер имеет международную лицензию, то пары ключей создаются с использованием шифрования - 512 бит. Начиная с версии 5.0.4, Domino поставляется с Global лицензией, которая использует – 1024 битные ключи шифрования.
Negotiated session keys (cipher specification).
Ключ для сессии Negotiated создается в начале SSL рукопожатия. Это рукопожатие определяет ключ, используемый при шифровке информации для соединения. Ключ сессии Negotiated изменяется каждый раз при запуске новой сессии.
Если сервер имеет Северо-Американскую лицензию, то ключ сессии - 128 бит. Если сервер имеет международную лицензию, ключ сессии - 40 бит. Если Вы поддерживаете связь между Северо-Американскими странами и другими странами, применяется более низкий уровень шифрования. Например, пользователь в Париже (Франция), устанавливает сессию с сервером в Вашингтоне, сервер генерирует ключ шифрования - 40 бит.
Одно исключение к этому правилу - если сервер использует Global Server ID, выпущенный от имени VeriSign. VeriSign Global Server ID позволяет Американским серверам и международным банкам генерировать ключ в 128 бит, при связи с международным браузерами и серверами по HTTP, NNTP, LDAP, IMAP и POP3. Если Ваш браузер поддерживает Global Server ID, то Domino автоматически использует ключ в 128 бит для сессии. Для информации относительно VeriSign Global Server IDS, посетите Web сервер http://www.verisign.com/
Вы можете изменять спецификацию ключа, чтобы управлять размером ключа для сессий Negotiated, для требуемого сервера.
Start Port
Разрешается использование указанного порта. Используйте эту команду после того, как Вы запретили порт командой - Stop Port.
Обратите внимание. Команды Stop Port и Start Port не имеют никакого влияния на Domino Web сервер.
Stop Port
Запрещает использование указанного порта. Порт, который Вы запрещаете, определяется из меню Файл – Параметры – Параметры настройки – Порты и удалите “галочку” - Порт включен. Эта команда позволяет Вам делать изменения в настройках порта, которые вступают в силу немедленно без остановки Domino сервера. Когда вы закончили изменения в настройках порта, используете команду - Состояние, чтобы заново разрешить его использование.
Связывание (Linking) почтовых файлов с базой данных Shared Mail
После того, как Вы создаете базу данных Shared Mail на сервере, Domino автоматически сохраняет все новые сообщения в этой базе. Однако Вам может понадобится, чтобы база данных Shared Mail содержала сообщения, которые были доставлены до того, как Вы установили базу данных Shared Mail на сервере. Чтобы сохранить эти сообщения в базе данных Shared Mail, Вы используете команду Object Link, чтобы связать почтовые файлы пользователя с базой данных Shared Mail.
По умолчанию, команда Object Link автоматически перемещает содержание каждого сообщения из почтового файла пользователя в базу данных Shared Mail. Если эта команда связывает больше чем пять файлов сообщений, с базой данных Shared Mail, задача автоматически уплотняет почтовый файл пользователя, чтобы высвободить место на диске, которое было занято содержанием удаленных сообщений.
Связывание почтового файла пользователя с Shared Mail.
Введите эту команду на консоли сервера:
Load Object Link USERMAIL.NSF SHARED.NSF
Где USERMAIL.NSF - имя почтового файла пользователя или каталог, содержащий почтовые файлы. SHARED.NSF - имя базы данных Shared Mail.
Связывание почтового файла с исключением опции сжатия.
-Nocompact - ключ запрещает уплотнение почтового файла, даже если больше чем пять файлов сообщений будут связаны.
Введите эту команду на консоли сервера:
Load Object Link -Nocompact USERMAIL.NSF SHARED.NSF
Где USERMAIL.NSF - имя почтового файла или каталог, содержащий почтовые файлы. SHARED.NSF - имя база данных Shared Mail.
Повторно связывает почтовый файл с различными базами Shared Mail.
Повторно связывает почтовые сообщения пользователя с различными копиями баз данных Shared Mail.
Введите эту команду на консоли сервера:
Load Object Link -Relink USERMAIL.NSF SHARED.NSF
Где USERMAIL.NSF - имя файла почты или каталог, содержащий почтовые файлы. SHARED.NSF - имя базы данных Shared Mail.
Разрыв связей с почтовым файлом пользователей.
Введите эту команду на консоли сервера:
Load Object Unlink USERMAIL.NSF
Где USERMAIL.NSF - имя файла почты или каталог.
Разрыв связей с базой данных Shared Mail.
Введите эту команду на консоли сервера:
Load Object Unlink SHARED.NSF
Где SHARED.NSF - имя базы данных Shared Mail.
Tell
Управляющая команду для задач сервера. Команда особенно полезна для остановки задач сервера без остановки самого сервера.
Administration Process Tell Commands
| Команда | Результат | ||
| Tell Adminp Process All | Обрабатывает все новые и запросы на изменение, немедленно, интервал, ежедневно и отсроченные запросы. Эта команда не перекрывает запланированные запросы. | ||
| Tell Adminp Process Daily | Обрабатывает запросы:
* Все новые и ежедневно измененные запросы, чтобы модернизировать документы Person в Domino Directory. * Любые невыполненные запросы Rename Person in Unread List. | ||
| Tell Adminp Process Delayed | Обрабатывает все новые и изменения отсроченных запросов. Запросы, которые обычно выполняются согласно Start executing on и с назначениями Start executing at из Server документа. | ||
| Tell Adminp Process Interval | Обрабатывает немедленно все запросы и все запросы, которые обычно обрабатываются согласно Interval setting в Server документе. | ||
| Tell Adminp Process New | Обрабатывает все новые запросы. | ||
| Tell Adminp Process People | Обрабатывает все новые и запросы на изменение, документов Person в Domino Directory. | ||
| Tell Adminp Process Time | Обрабатывает все новые и запросы изменения, чтобы удалить файлы Unlinked Mail. | ||
| Tell Adminp Show Databases | Отображает, делает запись в файле LOG.NSF сервера этой информации:
* Базы данных, Particular administration server updates * Местоположения базы данных, в которых модернизируются поля Readers And Authors в базах данных. * Базы данных, которые не имеют сервера администрирования назначенного для них. | ||
| Tell Adminp Quit | Останавливает задачу Administration Process на сервере. |
Agent Manager Tell commands
|
Команда |
Результат |
|
Tell Amgr Pause |
Приостановка расписаний для агентов. |
|
Tell Amgr Resume |
Возобновление расписаний для агентов. |
|
Tell Amgr Schedule |
Показывает список всех агентов, намеченных на текущий день. Кроме того, команда показывает тип запуска агента, время намеченное для агента, имя агента, имя базы данных, на которой будет запущен агент. При проверке менеджера агента список позволяет Вам видеть, ожидает ли агент в очереди менеджера агентов. Agent Manger queues: E - Agents eligible to run S - Agents scheduled to run V - Event-triggered agents waiting for their events to occur Trigger types: S - Agent is scheduled to run M - Agent is a new mail-triggered agent U - Agent is a new/updated document-triggered agent |
|
Tell Amgr Status |
Эта команда показывает “слепок” очереди менеджера агентов и показывает назначения менеджера агента в Server документе. |
|
Tell Amgr Quit |
Остановка Agent Manager на сервере. |
|
Команда |
Результат |
|
Tell Clrepl Log |
Делает запись информации в файл сервера LOG.NSF немедленно, не дожидаясь запланированного интервала log. LOG.NSF включает информацию относительно всех кластерных репликаций ожидающего повторения. Если Replica.Сluster.Retry.Waiting statistic не равна нулю, это означает, что некоторые репликации не закончены и ожидают повторения. После того, как Вы исправляете ошибки - например, перезапускаете сервер, который был недоступен - Cluster Replicator будет запущен на следующее повторение Replica.Cluster.Retry.Waiting statistic, установится в ноль. |
|
Tell Clrepl Quit |
Останавливает все Cluster Replicator на сервере. Чтобы запретить задачу Clrepl в будущих сессиях, удалите все упоминания Clrepl из ServerTasks в NOTES.INI файле. Запрещение Clrepl task на одном сервере, только останавливает репликации этого сервера на другие сервера, но не запрещает реплики на сервер, от других серверов в кластере. |
LDAP Tell commands
|
Команда |
Результат |
|
Tell LDAP reloadschema |
Модернизирует схему directory на LDAP сервере, чтобы отразить изменения, которые Вы настраиваете для Domino Directory. |
|
Команда |
Результат |
|
Tell NNTP Newgroup groupname |
Создание новой NewsGroup используйте эту команду для сознания NewsGroup, если она автоматически не создано в течение сессии. |
|
Tell NNTP Newgroup Delete group_name(s) |
Удаление указанной NewsGroup. |
|
Tell NNTP Newgroup groupname pathname |
Tells NNTP, чтобы добавить группу в Cache, с указанным NewsGroup и путем. Используется, когда группа создается на базу шаблона. |
|
Tell NNTP print cache list |
Отображается текущий список NNTP discussion groups и соответствующие им базы Notes. |
|
Tell NNTP Print config |
Отображение текущего списка значений NNTP. |
|
Tell NNTP Quit |
Остановка задачи NNTP. |
|
Tell NNTP Reset servername |
Повторная установка всех статей на сервере. |
|
Tell NNTP Show Config |
Показывает NNTP сервер конфигурацию, из секции NNTP документа сервера. |
|
Tell NNTP Show Groups |
Показывает имена и путь для NewsGroup на сервере. |
Router Tell commands
|
Команда |
Результат |
|
Tell Router Delivery Stats |
Показать статистику доставки задачи Router. |
|
Tell Router Compact |
Уплотняет MAIL.BOX и чистит открытые очереди задачи Router. Вы можете использовать эту команду, чтобы уплотнить MAIL.BOX в любое время. Если существует более чем один MAIL.BOX, сконфигурированный для сервера. Каждый MAIL.BOX будет уплотнен последовательно. По умолчанию, MAIL.BOX автоматически уплотняется в 4 часа утра. |
|
Tell Router Show Queues |
Показывает почту ожидающую доставки. |
|
Tell Router Exit |
Остановка задачи Router на сервере. |
|
Tell Router Use databasename |
Создает базу данных Shared Mail, которую Вы определяете, и устанавливает в NOTES.INI переменную Shared_Mail=2, которая разрешает Shared Mail для доставки и перемещения почты на этот сервер. Databasename - полное имя базы данных shared mail, которую Вы выбрали для использования на этом сервере, включая каталог, например, SHARED.NSF. В дополнение к созданию базы данных Shared Mail, Domino автоматически создает файл по имени MAILOBJ.NSF в каталоге данных. MAILOBJ.NSF - связь баз данных, которая всегда указывает на фактическую базу данных Shared Mail, которую Router использует, чтобы хранить новую почту, доставляемую на сервер, во время разрешения Shared Mail. |
|
Tell Router Quit |
Остановка задачи Router на сервере. |
Schedule Manager Tell commands
|
Команда |
Результат |
|
Tell Sched Stats |
Показывает общее количество Reservations и Appointments в базе данных Free Time. |
|
Tell Sched Show username |
Показывает график для указанного пользователя на консоли сервера. Используйте эту команду, чтобы исследовать проблемы в базе данных Free Ttime. |
|
Tell Sched Validate |
Обновление значений базы данных Free Time на сервере. Обновление происходит по умолчанию в 2 часа утра; однако, Вы можете использовать эту команду, чтобы вынудить это происходить скорее. Другой способ вынуждать обновление, состоит в том, чтобы останавливать и повторно начать задачу Schedule Manager. Обновление может занимать некоторое время. Вы должны запускать эту команду на всех серверах, где файлы почты были удалены и или добавлены, чтобы гарантировать, что старая информация Free time удалялась, а новая добавлялась в базу. Не используйте эту команду, когда Вы добавляете нового пользователя. Процесс администрирования создаст документы Person для пользователей в Domino Directory перед созданием их почтовых файлов на их почтовом сервере. Schedule Manager наблюдает за созданием баз данных и автоматически обрабатывает файлы почты новых пользователей. |
|
Tell Sched Validate username |
Validates - информации для указанного пользователя. Эта команда быстрее, чем использование команды Tell Sched Validate, потому что позволяет Вам обрабатывать пользователей индивидуально, чем обработка всех данных на сервере. |
|
Tell Sched Quit |
Остановка задачи Schedule Manager на сервере. |
Statistic Collector Tell Commands
|
Команда |
Результат |
|
Tell Collector Collect |
Запуск Statistic Collection на всех указанных серверах и собирает сообщения статистики. |
|
Tell Collector Quit |
Остановка задачи Collect на сервере. |
Web Navigator Tell commands
|
Команда |
Результат |
|
Tell Web Help |
Просмотр всех команд Web Navigator на консоли сервера. |
|
Tell Web Refresh |
Переинициализация всех глобальных назначений Web Navigator. Используйте эту команду, если Вы редактировали документ администрирования, во время работы задачи Web сервера |
|
Tell Web Quit |
Остановка всех запущенных копий Web Navigator. |
Web Server Tell commands
|
Команда |
Результат |
|
Tell HTTP Restart |
Переинициализирует Web сервер с изменениями, сделанными в: * Документе сервера для Web сервера * File Protection, Virtual Server и URL Mapping документах в Domino Directory. * NOTES. INI файл, которые затрагивают задачу HTTP * HTTPD.CNF и BROWSER.CNF файлы * Изменения Java servlets или servlets.properties файлов Эта команда имеет тот же самые результаты как остановка и рестарт Web Server. Однако, эта команда Tell быстрее, чем остановка или рестарт, потому что, когда Вы используете команду Tell, задача HTTP остается в памяти. Если любые процессы HTTP активны, когда Вы запускаете команду, Domino ждет до конца процессов перед рестартом HTTP. HTTP не будет, однако, принимать никакие новые запросы, пока команда рестарта не заканчивает работу. Эта команда удаляет из памяти кэшированные станицы пользователя. |
|
Tell HTTP Show File Access |
Показывает информацию относительно защиты системных файлов на машине и на виртуальных серверах, если Вы имеете такие. |
|
Tell HTTP Show Security |
Показывает информацию по SSL и файлу Key Ring сервера, включая информацию относительно того, запущена ли серверная задача SSL на машине. Показывает информацию относительно SSL для виртуальных серверов, если Вы имеете такие. |
|
Tell HTTP Show Users |
Показывает имена пользователей и их IP адреса, истечения времени сессий для пользователей зарегистрированных на сервере, только которые использует базовую идентификацию. |
|
Tell HTTP Show Virtual Servers |
Показывает виртуальные сервера, запущенные на Вашем сервере. |
|
Tell HTTP Quit |
Остановка задачи Web сервер. |
Тестирование подключение сети с использованием утилиты PING
После того, как Вы устанавливаете соединение с интернетом, Вы должны проверить связь и убедится, что все работает должным образом.
Если Вы имеете прямую связь в интернет, самый легкий способ проверить связь состоит в том, чтобы использовать утилиту PING. Утилита позволяет Вам запросить другой компьютер, если ответ есть, это подтверждает, что программное обеспечение протокола работает правильно.
Если Вы не можете “пинговать” удаленный Domino сервер, то Ваше соединение не может работать должным образом, проверяйте Ваш Router.
Если Вы соединяетесь с интернетом через Proxy сервер, пробуете пинговать Ваш Proxy, чтобы проверить связь по сети.
Используйте следующий формат:
ping xyz.com
Если пинг успешен, утилита возвращает сообщение в формате, подобном следующему:
64 bytes from 130.000.00.00: 1cmp_seq=4, time=0, ms
Тестирование репликаций
После того, как Вы создаете документы подключения и разрешите репликации, Вы можете проверять репликации. Прежде, чем Вы начинаете проверять, удостоверитесь, что Ваша сеть запущена и работает должным образом, все модемы доступны.
Чтобы проверять репликации, создайте новую реплику базы данных, сделайте изменение в ней, затем дождитесь реплики в другие базам данных. Вы можете или вынуждать репликацию, используя функцию - Репликация, из меню, или подталкивать ее с консоли сервера. Вы можете ждать, чтобы видеть, результат выполнения реплик автоматически на консоли сервера.
Проверьте консоль сервера, чтобы просмотрите сообщения, когда задача Replicator начинает работать. Replicator отображает список баз данных на консоли сервера, которые реплицируются в процессе репликации. Используйте команду просмотра задач Sh Ta, на консоли сервера, чтобы видеть, какая серверная задача запущена в настоящее время.
Для информации о репликах, проверьте историю репликаций в свойствах баз данных, а так же проверьте LOG.NSF для резюме по репликациям. Проверить фай LOG.NSF, можно из клиента Domino Administrator, щелкнув на закладке Репликация, представление - События репликаций.
Чтобы проверять, что репликационные связи не запрещены, Вы можете просмотреть представление - Топология реплицирования.
Типы удаленных соединений
Чтобы удаленные соединения могли выполнять намеченные Вами задачи маршрутизации почты и репликации, Вы можете использовать модемы или другие устройства связи, типа ISDN устройства. Domino поддерживает следующие типы удаленных связей:
| Тип соединения | Описание | ||
| Notes Direct Dial-Up | Этот способ использует Модем и X.PC протокол, чтобы позволять связываться серверам не использующим соединения по сети LAN, с другими Domino серверами.
Вы можете использовать прямой набор модема, чтобы соединить сервера с использованием асинхронного сценария связи. Например, сервер использует файл сценария, чтобы соединиться с X.25 PAD и сервером по X.25 сети. | ||
| Network Dial-Up | Этот тип связи подобен Notes Direct Dial-Up, за исключением того, что сервер использует MS RAS, для использования сетевого протокола сети, вместо X.PC. После того, как связь установлена, сервер имеет доступ к Domino серверам и может использовать сеть, например для печати. | ||
| Passthru (with Notes Direct Dial-Up) | Этот тип связи позволяет определять сервер посредник, который действует как посредник, для получения доступа к определенному серверу. Для X.PC Dial-Up, сервер назначения не нуждается в модеме, если Passthru сервер имеет модем и может передавать информацию на него.
Как администратор, Вы могли бы установить режим Passthru соединений, для удаленных пользователей, чтобы использовать одну телефонную линию для доступа пользователей к серверам. Чтобы использовать Passthru для удаленного соединения, Вы должны создать документы Notes Direct Dial-Up Connection для Passthru сервера, чтобы установить связь сначала с посредником. | ||
| Hunt group (with Notes Direct Dial-Up) | Эта связь позволяет рабочим станциям звонить на группу модемов Hunt, на больше чем один Passthru сервер. Группа Hunt – это телефонное устройство, которое может иметь один телефонный номер, но несколько линий на нем. Любой Passthru сервер в группе Hunt может получать запрос и передать его к серверу назначения.
Чтобы использовать группу Hunt для этого типа конфигурации, Вы создаете документ Hunt group Connection, чтобы установить удаленное соединение. |
В дополнение к удаленным типам связи, внесенным в список в предыдущую таблицу, Domino предлагает и другие типы связи. Некоторые из этих типов связи также требуют дополнительное программное обеспечение или дополнительные аппаратные средства, которые покупаются отдельно.
|
Тип соединения |
Описание |
Дополнительная информация |
|
X.25 |
Установить прямое соединение по X.25 сети |
Lotus Notes Connect for X.25 Install Guide and Administrator's Guide |
|
X.400 |
Установить соединение с сервером X.400 |
Domino X.400 MTA Configuration Guide |
|
cc:Mail™ |
Установить соединение с сервером cc:Mail |
Planning and Installation for cc:Mail |
|
News/NNTP Feed |
Установить соединение с сервером NNTP |
Setting up the NNTP Service |
Топология системы репликаций
В Domino системе с больше чем одним сервером, Вы должны планировать топологию, которая решает, как соединять сервера при репликах.
Вы определяете топологию, создавая документы подключения в Domino Directory. Поскольку Вы планируете топологию, Вы должны рассмотреть и топологию движения почты и репликаций. Репликации между серверами требует одного документа подключения. Однако маршрутизация почты требует двух документов подключений, так как все это работает только в одном направлении. Часто более эффективно создавать сначала документы подключений для передачи почты, а затем добавлять репликации к этим же самым документам.
Топология репликаций обычно дублирует топологию Вашей Domino системы, и она обычно изменяется с размером Вашей организации. Маленькие фирмы используют топологию Peer-to-Peer, которая быстро распространяет изменения на все сервера, но неэффективна, когда появляется несколько серверов. Фирмы среднего размера могут использовать комбинацию репликаций Peer-to-Peer или могут осуществлять Hub-and-Spoke репликации. Большие организации, вероятно, будет использовать Hub-and-Spoke репликации, для максимальной эффективности или могут использовать кольцевую топологию репликаций между Hub серверами. Как Вы наметите свои репликации, зависит от Вашей серверной топологии и стратегии репликаций, которую Вы выбираете. Например, Acme корпорация использует Hub-and-Spoke топологию.
Trace
Используйте команду Trace, чтобы проверить связь с сервером. Эта команда показывает детальную информацию относительно каждого перехода через сервер и полезна при поиске проблем и поиска неисправностей сети. Эта команда работает так же как Трассировка, когда Вы выбираете - Файл – Параметры – Параметры настройки.
Чтобы проследить путь к серверу, введите:
Trace servername
Чтобы проследить определенный порт, введите
Trace portname!!!servername
Когда Вы пытаетесь соединяться с сервером, значок сети автоматически появляется в строке статуса, рабочего места Notes или на консоли сервера, в зависимости от того, где Вы ввели команду попытки связи. Вы можете использовать установку NOTES.INI – Console_LogLevel, чтобы управлять уровней деталей информации, которая будет выводится в строке статуса. Информация будет регистрироваться в файле log (LOG.NSF).
Transaction Logging
Domino поддерживает опцию Transaction Logging и опции восстановления после сбоя системы. Если Вы включаете этой функции, система захватывает базу данных и отслеживает все изменения, записывая их в файл Transaction Log. В случае если Ваша система отказывает, Вы можете использовать файл Transaction Log и устройство резервного копирования, чтобы восстановить Ваши разрушенные базы данных.
Single Transaction - ряд изменений, сделанных в базе данных на сервере. Например, транзакция может включать открытие нового документа, добавление в него текста и сохранение документа.
Transaction logging - обеспечивает три главных выгоды:
* В большинстве ситуаций, Вы больше не должны использовать задачу Fixup для обработки баз данных после отказа системы. Исключение использования задачи Fixup - более быстрый перезапуск сервера, так как Fixup должен сначала проверить каждый документ в каждой базе данных. Использование для восстановления Transaction Log более выгодно, так как вы можете восстанавливать или уничтожать только те транзакции, которые не записаны на диск, во время отказа системы.
* Transaction logging экономит время, потому что позволяет Domino отложить модернизацию базы данных и запись на диск в течение периодов высокой занятости сервера. Транзакции регистрирует последовательно операций в файлах протоколах.
* Использование Transaction logging упрощает Вашу ежедневную процедуру резервного копирования. Вы можете использовать утилиту резервного копирования, чтобы выполнять сохранение ежедневных изменений Transaction Logs, чем исполняют полную процедуру резервного копирования баз данных.
Transaction logging работает с базами данных Версии 5. После того, как Вы разрешаете использования опции Transaction Logging, все базы данных формата R5, автоматически будут зарегистрированы. Чтобы проверять формат баз данных, используйте закладку Файлы, из клиента Domino Administrator.
Чтобы использовать все функции Transaction logging и опций восстановления, Вы нуждаетесь в дополнительной утилите резервного копирования, которая поддерживает Transaction logging Domino R5.
Требование для работы почтовой системы
Удостоверитесь, что Ваша система Domino работает должным образом:
* Установленный Domino сервер, работает без ошибок.
* Задача Router запущенна и работает должным образом.
* Созданы файлы почты для каждого пользователя и Person документы, в Domino Directory для каждого пользователя Domino.
* Настройте Notes и, или SMTP маршрутизацию почты.
Требование к маршрутизации SMTP почты
* Установите DNS, локальные HOSTS файлы или Relay Host.
* Разрешите задачу SMTP Lister.
* Разрешите маршрутизацию SMTP, в пределах локального интернет домена.
* Разрешите маршрутизацию SMTP, для посылки сообщения за пределы Вашего локального интернет домена.
Требование к маршрутизации Notes почты
* Создайте нужные документы подключений.
В зависимости от топологии Вашей почтовой системы, создайте эти документы, по мере необходимости:
* Документы Non-Adjacent Domain.
* Документы Adjacent Domain.
* Документы Foreign SMTP domain.
* Документы SMTP Connection.
Требования для обмена почтой с другими системами в Вашей организации
* Если Вы имеете некоторых пользователей, которые используют Lotus cc:Mail, Вы нуждаетесь, по крайней мере, в одном сервере, с установленным на нем агентом МТА cc:Mail, чтобы соединить Вашу Domino систему, с cc:Mail системой.
* Если Вы имеете некоторых пользователей, которые используют X.400 почтовую систему, Вы нуждаетесь, по крайней мере, в одном сервере, с агентом X.400 MTA, чтобы соединить Вашу Domino системой с X.400.
* Установите Smart Host.
Требование установки SSL связи, с сервером
После того, как Вы установили SSL на сервере, Вы можете требовать SSL соединений. Например, Вы можете вынуждать клиентов и сервера использовать SSL, чтобы соединиться с определенным портом сервера или, не разрешать доступ клиентам и серверам, которые используют TCP/IP, чтобы соединиться с этим портом. Требуйте SSL связей, когда Вы хотите удостовериться, что клиенты используют безопасные соединения для доступа к базам данных на сервере. Если Вы не требуете SSL соединений, клиенты могут использовать или SSL, или TCP/IP, чтобы соединиться с сервером.
Вы можете требовать SSL соединений для всех баз данных на сервере или только для некоторых баз данных.
Требование соединений по SSL, для всех баз данных на сервере.
* Из клиента Domino Administrator, выбирайте закладку Настройка, откройте Server документ.
* Выбирайте закладку Ports – Intrnet Ports.
* Выбирайте закладку нужного протокола.
* В поле TCP/IP port status, выберите значение – Redirect to SSL. Обратите внимание NNTP, POP3 и SMTP не поддерживают Redirect to SSL установку.
Требование соединения SSL, для выбранной базы данных.
* Запустите клиента Notes.
* Выбрать базу данных, для которой Вы хотите вынудить клиентов использовать SSL.
* Откройте свойства базы данных.
* На закладке Basics, выберите - Web: Требовать наличия SSL-подключения.
Удаление базы данных Shared Mail
По некоторым причинам Ваша организация может решить прекратить использование базы данных Shared Mail. Чтобы удалить базу данных Shared Mail, Вы должны сначала разорвать все связи с почтовыми файлами пользователей. После этого Domino сохранят все сообщения в почтовых файлах пользователей. Если Вы не разорвете связи с почтовыми файлами пользователей прежде, чем удаляете базу данных Shared Mail, задача Object Collect не сможет произвести чистку содержания сообщений в базе данных Shared Mail.
Прежде, чем Вы разорвете связи, проверяете число и размер сообщений в ней. Вы сможете определять, имеется ли достаточно места на диске, для сохранения полных копии сообщений в почтовых файлах каждого получателя.
Удаления базы данных Shared Mail.
* Введите эту команду на консоли сервера:
Load Object Info USERMAIL.NSF
Где USERMAIL.NSF - имя файла почты пользователя или имя каталога, который содержит почтовые файлы.
* Введите эту команду на консоли сервера:
Load Object Unlink USERMAIL.NSF
Где USERMAIL.NSF - имя файла почты пользователя или имя каталога, который содержит почтовые файлы.
* Введите эту команду на консоли сервера:
Load Object Unlink SHARED.NSF
Где SHARED.NSF - имя базы данных Shared Mail.
* Удалите файл базы данных Shared Mail.
