Администратор не может ввести команды на консоли сервера
Если администратор не имеет доступа к программе рабочей станции на сервере, используйте серверные программы Load, Tell, или Set Configuration, для защиты консоли сервера паролем.
Используйте команду Set Secure на консоли, или используйте клиента Domino Administrator, чтобы удалить пароль консоли.
Agent manager и агенты – проблемы и сообщения об ошибках
Эти темы содержат предложения для поиска неисправностей, если возникают проблемы с менеджером агентов и или агентами:
* Agent Manager не работает, как ожидалось
* Агент не запускается, как ожидалось
* Агент запускается, но не завершает свою работу
* Агент не запускается в назначенное время
* Escrow agent не работает
* Пользователь не может создать агента
Agent Manager не работает, как ожидалось
Менеджер агентов не может работать эффективно.
* Менеджер агентов не может быть намечен для запуска. Если менеджер агентов не запустится, проверьте поле Start time/End time в секции Server Task – Agent Manager, Server документа. Если время не указанно в этом поле – менеджер агентов трактует его как время простоя. Если необходимо, откорректируйте время.
* Требования системных ресурсов для менеджера агентов может быть слишком высоко. Если менеджер агентов работает слишком долго, чтобы управлять агентами, перенесите запуск агентов на ночь, когда требование к системным ресурсам, обычно низкое.
Если Ваш Сервер Domino 4.6 или ранее, Вы можете увеличивать значение поля Max % busy before delay в Server документе. Domino R5 не поддерживает это поле.
Примечание. Обратите внимание, если Вы выделяете большое количество ресурсов менеджеру агентов, количество ресурсов доступное другими задачам сервера уменьшается.
Агент не запускается, как ожидалось
Если имеются ошибки в коде агента, агент может не работать должным образом. Агент может не иметь достаточного доступа, или потому что агент не настроен для запуска на данном Сервере.
* Недостаточный доступ в базе данных ACL может нарушить работу агента должным образом. Например, пользователь может создать агента, который копирует выбранные документы из базы данных. Если пользователь и агент - не имеет доступ автора в ACL базы данных, агент запустится, но не будет копировать документы. Чтобы определять, существует ли проблема, просмотрите в журнале ошибки доступа, после запуска агента.
* Если агент не будет запускаться на выбранном сервере, проверьте ограничения агента на закладке безопасности, Server документа. Эта секция содержит поля Run personal agents, Run restricted LotusScript/Java agents, Run unrestricted LotusScript/Java agents, которые определяют, кто имеет доступ для запуска агентов на сервере. Хотя пользователь и имеет соответствующий доступ в базе данных ACL, он может быть не способен создавать агентов на сервере, без соответствующего доступа в Server документе.
Вы должны также проверить секцию доступа сервера, на закладке безопасности Server документа. Эта секция содержит поля Only allow server access to users listed in this Directory, Access server, Not access server, которые разрешают или запрещают доступ к серверу. Агент наследует привилегии доступа пользователя, который создает агента и не может запускаться на сервере, для которого создатель не имеет доступа.
* Конфликты по времени могут останавливать агента. В Server документе щелкните на закладке Server Tasks – Agent Manager и проверьте поля Daytime Parameters Start time/End time и Nighttime Parameters Start time/End time.
Если не указанно время в этих полях – сервер трактует это как время простоя. Если пользователь создает агента и определяет, что он должен запускаться во время простоя менеджера агентов, агент не будет запущен. Сравните поля в Server документа и время, на которое агент намечен для запуска. Если конфликт существует, измените, график менеджера агентов на сервере, или просите пользователя перенести время выполнения агента.
* Если LotusScript или агент Java не завершается нормально, проверьте поле Max LotusScript/Java execution time в Server документе. Если сложный агент требует большего количества времени, чем было намечено, менеджер агентов завершает агента перед завершением.
Просите пользователя перенести агента на ночь, когда период времени боле длителен, или увеличьте значение поля Max LotusScript/Java execution time в Server документе. Если ни одно из этих решений не приемлемо, просите пользователя, чтобы он заменил один агент несколькими, но менее длинными по времени выполнения.
Агент не запускается в назначенное время
Если агент запускается, но не в то время, на которое Вы его определили, возможно, что сервер может быть занят другими задачами. Чтобы собраться, информация относительно того, когда агент последний раз запустился, проверьте журнал агента. После чего проверьте эти условия состояния и исправьте их, если необходимо.
* Конфликты по времени запуска могут повлиять на запуск агента. В Server документе, щелкните на закладке Server Tasks – Agent Manager и проверьте поля Nighttime Parameters Start time/End time и Daytime Parameters Start time/End time. Если значения этих полей не содержать период Вашего рабочего дня, менеджер агентов не будет запускаться в течение этого периода. Например, если дневные параметры - 8 AM и 5 PM, и ночные параметры - 8 PM и 8 AM, менеджер агентов не будет запускать никакие агенты между 5 PM и 8 PM.
* Назначения могут быть неправильны в файле NOTES.INI. Проверьте значения переменных менеджера агента в NOTES.INI файле:
· Amgr_DocUpdateAgentMinInterval
· Amgr_DocUpdateEventDelay
· Amgr_NewMailAgentMinInterval
· Amgr_NewMailEventDelay
* Редактируйте файл NOTES.INI, чтобы включить переменную Log_AgentManager=1. Вы можете также позволять это установку в документе конфигурации для серверов из Domino Directory.
Для серверов под управлением Domino 4.6 или ранее, установка Max % busy before delay, возможно превышена. Установка Max % busy before delay управляет максимальным процентом от времени менеджер агентов, затраченного на управление агентами. Если процент от времени превышен, задержка происходит прежде, чем менеджер агентов запускает следующий агент. После падения процента ниже порога, менеджер агентов возобновляет запуск агентов.
Агент запускается, но не завершает свою работу
Когда агент запускается, но не завершает свою работу, проверьте проток сервера (LOG.NSF), консоль сервера и журнал агента, для поиска сообщений ошибок.
* Если агент запускается вручную, но не запускается, когда Вы пытаетесь его запустить в фоновом режиме, проверьте код агента. Агент может содержать команды – LotusScript, методы интерфейса пользователя, которые не предназначены для запуска в фоновом режиме.
* Поле Max LotusScript/Java execution time, Server документа определите время, за которое агент LotusScript/Java должно закончить свое выполнение. Если агент превышает этот максимум, агент не завершает свою работу и делает запись в журнале агента. Просмотрите код агента, чтобы удостовериться, что он функционирует правильно. Пример. Удостоверьтесь, что код не содержит бесконечной петли. Если код правилен, просмотрите время работы агента в Server документе.
Анонимный доступ для пользователей интернет / интранет
Когда Вы устанавливаете анонимный доступ, клиенты интернет / интранет могут получить доступ на сервера без идентификации. Domino не делает запись деятельности в базах данных для этих клиентов - например, в файле LOG.NSF и в окне диалога деятельности пользователя.
При использовании анонимного доступа, Вы никогда не знаете, кто обращается к базам данных на сервере. Поэтому, Вы не можете использовать идентификацию клиента - то есть имя клиента и пароль, чтобы управлять доступом к базам данных и модулям приложений. Используйте анонимный доступ только тогда, когда Вы не должны знать, кто обращается к базе данных, и или когда Вы не должны управлять доступом, основанным на идентичности клиента.
Вы можете использовать анонимный доступ с TCP/IP и или с SSL на любом сервере, где работают задачи NNTP, LDAP, HTTP, SMTP, IIOP. Для каждого протокола интернета позволенного на сервере, Вы можете определить метод безопасности.
Например, Вы можете позволять SSL для HTTP доступа, но требовать введений имен и паролей для NNTP доступа, то TCP/IP.
В дополнение к использованию анонимного доступа, Вы можете использовать и установление подлинности, с использованием имени и пароля по SSL. Тогда пользователи могут использовать любой из этих методов для соединений с сервером.
Например, если пользователь имеет сертификат SSL, пользователь может получить доступ на сервер с использованием SSL, кто не имеет сертификата SSL, получает доступ на сервер анонимно.
Архивирование и удаление статей из групп новостей
Управление группами новостей подразумевает удаление статей, когда они бездействуют или истекли их сроки. Из клиента Notes, Вы можете установить архивирование, чтобы удалять или архивировать статьи. Вы должны иметь доступ менеджера к базе данных новостей.
Архивирование статей.
Параметры в архивирования устанавливаются для баз данных, когда Вы определяете параметры архива через свойства базы данных. Параметры архива, которые Вы устанавливаете, применяются только к статьям в выбранной базе данных.
* Откройте базу данных группы новостей, для которой Вы хотите изменить параметры архивирования.
* Из клиента Notes выберите - Файл – База данных – Свойства.
* Выбирайте – Настройка архива.
* Выбирайте любую опцию из следующего выбора:
* Выбирайте – OK.
Удаление статей из групп новостей.
По умолчанию, статьи из групп новостей, созданных на сервере автоматически - удаляются через пять дней.
Чтобы изменять эти установки, измените переменные в NOTES.INI:
Задача | Установки NOTES.INI | ||
Определите число дней прежде, чем бездействующая статья будет удалена | NNTP_Delete_Days | ||
Определите число дней, прежде чем просроченная статья будет удалена | NNTP_Delete_Days_Expired |
Удаление групп новостей
* Удостоверьтесь, что Вы имеете доступ менеджера в ACL групп новостей базы данных.
* Введите на консоли сервера:
tell nntp newsgroup delete group_name(s)
Где group_name(s) - имя группы новостей.
Вы можете использовать звездочку (*), чтобы указать больше чем одну группы новостей. Вы можете использовать запятые, чтобы отделить имена групп новостей. Например, для group_name(s) Вы может определить rec.skiing или comp.groupware.
Балансировка рабочей нагрузки на кластер
После контроля Вашего кластера и определения, что Вы хотите сделать в настройках, Вы можете делать следующее, чтобы лучше сбалансировать рабочую нагрузку на сервера в кластере:
* Ограничите рабочую нагрузку на сервера, изменяя порог готовности сервера
* Измените настройку максимального числа пользователей на сервере
* Переместите базы данных на другой сервер
* Создайте большее количество реплик занятых баз данных
* Добавьте один или большее количество серверов к кластеру
Имейте в виду, что балансирование рабочей нагрузки не является решением недостатка мощности серверов в Вашей организации. Если Ваши Domino сервера сильно загружены и не имеется никаких дополнительных серверов, чтобы распределить нагрузку, то балансирование рабочей нагрузки не решит проблему. Балансировать рабочую нагрузку Вы должны, если имеются некоторые сервера, на которых постоянная загрузка сервера ниже, чем на других серверах
База данных Administration Requests
Чтобы просматривать документы в базе данных Administration Requests, Вы можете использовать клиента Domino Administrator или Web Administrator.
Действия, которые требуют одобрения администратора.
Когда процесс администрирования запрашивает администратора одобрения и если оно получено, оно сохраняется в базе данных Administration Requests и процесс продолжается.
Действия, требующие одобрение администратора | Объяснение | ||
Complete Moving a mail file | Перемещение почтового файла.
Файл почты должен быть удален со старого сервера, после его перемещения на новый почтовый сервер. | ||
Move a database replica from a non-clustered server | Перемещение баз данных репликацией на другой сервер. Удаляется реплики на старом сервере. | ||
Accept administration requests from other domains | Принятие запроса администрирования из других доменов.
Если имя сервера запроса принадлежит другому домену, а запрос должен удалять или переименовать пользователя или сервера. | ||
Delete resources | Удаление ресурса.
Удаляет ресурса, типа имени зала заседаний из Domino Directory. Ресурсы также связаны с календарями и планированием пользователей. | ||
Delete mail files | Удаление почтового файла.
Одобрение администратора требуется для удаления почтового файла для удаляемого пользователя | ||
Move users to a different organization hierarchy | Перевод пользователя в различные иерархии организаций, требует одобрения администратора организации назначения. | ||
Delete Private Design Elements | Одобрение администратора требуется, для удаления личных агентов, видов, папок |
Базовые требования для Domino и Microsoft IIS
Прежде, чем Вы установите Domino для Microsoft IIS, сделайте следующее:
*
Установить Microsoft WindowsNT 4.0 с SP4.
* Установить Microsoft IIS4.
* Установите и настройте Domino сервер и удостоверитесь, что он работает правильно.
* Проверите следующее:
· NOTES.INI файл для сервера расположен в программном каталоге Domino, или в каталоге указанном в установке пути сервера.
· Если ID сервера не хранится в каталоге данных Domino, то NOTES.INI файл для сервера должен иметь полный путь к ID файлу сервера в параметре - ServerKeyFilename.
· ID файл сервера не должен использовать пароль. Вы не сможете вводить пароль, когда IIS запускает Domino ISAPI расширение.
* Удостоверитесь, Domino каталог и подкаталоги имеет, по крайней мере, доступ – Изменения файлов, для NT экаунтов пользователей, которые используют Domino для IIS. Типично, доступа к файлам по умолчанию достаточно. Однако если Вы должны изменить разрешения для файлов, имейте в виду, что пользователи Web, при обращении к серверу нуждаются в некоторых правах, чтобы делать изменения в базах данных и файлах на сервере.
* Вам надо понимать, как использовать Microsoft Management Console (MMC), которую Вы используете для конфигурирования IIS.
Безопасность
ICM поддерживает SSL. ICM может использовать те же самые SSL сертификаты, которые Domino Web сервер использует, или Вы можете определить различный набор SSL сертификатов для ICM. Вы можете сконфигурировать ICM, чтобы требовать SSL в секции Internet Cluster Manager документа сервера. ICM использует назначения секции Internet Ports, документа сервера, чтобы разрешить соответствующую версию SSL протокола и принимать ли истекшие сертификаты.
Кроме того, обычные функции безопасности Domino сервера, для баз данных, могут использоваться с использованием ICM. Однако ICM не участвует в процессе безопасности в прямом смысле слова. Когда HTTP клиент хочет получить доступ к базе данных, он посылает анонимный запрос к ICM. ICM сообщает клиенту имя сервера, на который он может получить доступ. Запрос клиента автоматически переадресовывается на соответствующий сервер. Сервер устанавливает диалог с клиентом и может использовать любые меры безопасности, которые доступны Вам. Если Вы хотите защитить ICM непосредственно от неправомочного доступа, Вы можете использовать Firewall сервер.
Безопасность публичного ключа
Каждый ID пользователя Notes и ID Domino сервера имеет уникальный публичный ключ для сертификата Notes. Публичный ключ сохраняется в ID файле и в Person документе или Server документе для этого ID в Domino Directory. Notes и Domino использует публичный ключ, чтобы идентифицировать пользователей и серверов, проверять цифровые подписи, шифровать сообщения и базы данных.
ID пользователь Notes может также иметь уникальный публичный ключ для интернет сертификата.
Создание новых публичных ключей для Notes сертификатов.
Если Вы подозреваете, что ID был украден или потерян, либо скопирован без разрешения, Вы можете создавать новый публичный ключ для ID. Создание нового публичного ключа позволяет, Вам, продолжать использовать другие части ID - например, ключи шифрования. Это лучше, чем создавать полностью новый ID.
Пользователи Notes могут создавать новый публичный ключ для сертификата Notes. Новый публичный ключ должен быть сертифицирован прежде, чем его можно использоваться Notes.
После сертификации нового публичного ключа, Вы должны настроить сервер, чтобы проверял публичные ключи. Проверка публичных ключей использует соответствие публичному ключу, сохраненному в Domino Directory, с публичным ключом в ID файле. При проверке публичного ключа неправомочный пользователь, со старым публичным ключом, не получит доступ на сервер
Добавление существующего публичного ключа в Domino Directory.
Когда Вы регистрируете пользователя или сервер, Domino автоматически добавляет публичные ключи Notes в Person документу или Server документу. Domino также автоматически добавляет интернета публичный ключ к Person документу, когда Вы выпускаете интернет сертификат, для пользователей. Однако Вы можете вручную добавить публичный ключ ID сервера или пользователя в Domino Directory в этих ситуациях:
* Пользователь хочет послать шифрованную почту пользователю Notes в другом домене или пользователю, который использует S/MIME приложение, для отправки почты. Чтобы посылать S/MIME или Notes шифрованную почту, Domino должен иметь доступ к интернет сертификату получателя или публичному ключ Notes. Если получатель находится в другом домене и Domino Directory для этого домена, сохранен на сервере в домене отправителя, то Domino не может получить доступ к публичному ключу получателя для шифрования. Отправитель должен получить публичный ключ получателя и добавлять его в персональную адресную книгу или в Domino Directory.
* Пользовательский или публичный ключ сервера в Domino Directory становится известен или случайно удален, и администратор должен заменить его.
Безопасность в Domain Search
Когда пользователь выполняет поиск Domain Search в данных, Domain Search проверяет каждый результат, сравнивая его с ACL базы данных, в которой результат был найден, чтобы проверить доступ пользователя, на чтение документа. Чтобы выполнять эту проверку, Domain Catalog содержит список для всех баз данных, который включают ACL базы данных. Проверка безопасности работает следующим образом:
* Domino проверяет доступ – Default - к базе данных ACL.
· Если – Default - имеет доступ читателя или больший, пользователь может читать документ и Domino возвращает результат в наборе результатов.
· Если – Default - имеет доступ менее читателя, Domino проверяет, имеет ли пользователь доступ читателя, или больший в ACL. Если нет, Domino не включает базу в результат.
* Если пользователь имеет доступ читателя или больше, Domino проверяет, имеет ли документ поле Readers.
· Если документ результата не имеет поля Readers, пользователь может читать документ и Domino возвращает результат в наборе результатов.
· Если документ результата имеет поле Readers, Domino проверяет, включен ли пользователь в поле. Если нет, Domino не включает результат в результат поиска.
· Если пользователь включен в поле Readers, пользователь может читать документ, и Domino возвращает результат в наборе результатов.
Для Domino, чтобы включить связь c документом в результат, пользователь должен быть способен, читать документ.
Безопасность поиска и список доступа пользователей к серверу.
Если Вы используете списки доступа к серверу, в пределах домена для ограничения доступа к информации, знаете, что Вы должны проверить ACL баз данных по этим серверам, чтобы гарантировать правильное фильтрование результатов поиска.
Иначе, поиск может возвращать результат пользователю, для тех, кто не должен иметь доступ к документам. В некоторых случаях, пользователи могут получить конфиденциальную информацию, из результата поиска.
Например, корпорация Acme имеет два сервера приложений, App-E/East/Acme и App-W/West/Acme. Пользователи Acme - сертифицированы одним из двух сертификатов орг. единицы: /East/Acme или /West/Acme. App-E/East/Acme не позволяет доступ любому пользователю с сертификатом /West/Acme. Но базы данных на сервере, не должны быть доступны для /West/Acme пользователей и имеют доступ – Default - в их ACL - читатель, так как список доступа гарантирует, что /West/Acme пользователи не могут иметь доступ к базам данных.
Когда Acme осуществляет поиск с использованием Domain Search, пользователи /West/Acme, могут получить результаты поиска, которые включают связи с документами в базах данных сервера App-E/East/Acme, так как в списках управления баз данных, /West/Acme пользователям не запрещен доступ чтения результатов. Серверные списки доступа продолжают обслуживать пользователей, так как /West/Acme пользователи не могут иметь доступа к документам из связей, но простое существование связей, потенциально может показывать конфиденциальную информацию /West/Acme пользователям.
Чтобы избежать этой проблемы, проверьте Списки управления доступом для баз данных, которые защищены серверными списками доступа. Чтобы сделать это, предположите, что серверный список доступа не существует. Измените ACL так, чтобы, в отсутствии серверного списка доступа, база данных была бы гарантировано защищена. Это гарантирует, что Domain Search проверяет базу данных ACL и отфильтровывает результаты и пользователей, которые не могут иметь доступ к данным.
Обратите внимание, что этот пример предполагает, что Domain Catalog сервер имеет сертификат, которое позволяет доступ и на App-E/East/Acme и на App-W/West/Acme.
Broadcast
Посылается сообщение определенному пользователю или всем пользователям этого сервера. Используйте эту команду, чтобы предупредить пользователей, когда сервер будет остановлен для обслуживания. Сообщение, которое Вы вводите, покажется в панели статуса пользователя.
Что делать, если при установке QMR или QMU возникают ошибки, и процесс обновления останавливается?
Иногда, в процессе установки QMR или QMU возникают ошибки, и процесс выполнения обновления останавливается. Как правило пользователь получает окно предупреждения, аналогичное приведенному ниже.
![](image/index-image018.gif)
Рис. 4 Информационное окно с сообщением об ошибке, при запуске программного обеспечения обновления QMR или QMU.
Как правило, эти ошибки можно разделить на три категории:
* Проблемы с файлом программы обновления. Обычно возникает на первом этапе установки, когда программа пытается тестировать целостность дистрибутива. В таких случаях обычно проходится скачивать обновление заново. Ничего не поделаешь, файл программы обновления иногда скачивается с ошибками…
* Вторая проблема может быть связана с недостаточным количеством свободного места на диске сервера или рабочей станции. Как правило, об этой неприятности Вы можете прочитать в окне предупреждения, Вам будет указан минимальный размер необходимый для программы обновления. Очистите диск от ненужных файлов и запустите установку заново. Кстати, вы можете избавиться от файлов *.IIB, если не планируете их в дальнейшем использовать. Опыт показывает, что они занимают довольно приличное место на диске.
* Третья причина остановки обновления самая неприятная. Она связана с несоответствием контрольной суммы некоторых файлов, Вашего установленного дистрибутива. На первом этапе, программ обновления проверяет наличие и контрольные суммы файлов, которые (как я понимаю) будут обновлены в процессе модернизации программного обеспечения. Программа обновления всегда ведет протокол своей работы и записывает его в файл UPGRADE.LOG, который обычно находится в программном каталоге сервера или рабочей станции.
Для выяснения причины остановки обновления просматриваем этот файл и выясняем причину по вине, которой произошла остановка.
Далее представлен фрагмент файла UPGRADE.LOG, с ошибкой в предпоследней строке, по вине которой и была прервана программа QMR:
Iris Incremental Installer v5.02 for W32Intel
Copyright (c) Iris Associates, Inc., 1994-1999. All rights reserved.
Executable created 14:31:31 Sep 7 2000 for 5.0.2c Intl Server -> 5.0.3 Intl Server.
Upgrade started at 17:46:44 Apr 03 2000 in D:\.
Using Notes program directory C:\NOTES
Using Notes data directory C:\NOTES\DATA
Identified Release 4.6.6c Intl Server.
File lsxbeerr.lss failed checksum. (Found 0xd2d65163, Expected 0x429b98fd)
Unable to verify release.
В большинстве случаев помогает замена файла, путем копирования его из дистрибутива. Если это, по каким то причинам невозможно, то действуем старыми “дедовскими” методами, по принципу “Нет файла – нет проблем”. Попробуйте перенести файл, с которым у вас возникли проблемы в другой, не-Notes каталог. Запустите программу обновления заново, проблема должна исчезнуть…
Что делать при крушении сервера
Наиболее общие причины аварий сервера - следующее:
* Мало системных ресурсов выделенных серверу
* Высокая загрузка сервера
* Проблемы с программным обеспечением
* Проблемы с сетью
* Изменение окружающей среды сети или операционной системы
* Изменение конфигурации компьютера сервера, например замена сетевой карты или программного обеспечения для нее.
Используйте эти шаги для анализа крушения сервера. Если, после завершения этих шагов, Вы не решили проблему, консультируйтесь с Вашим техническим представителем поддержки.
* Соберите информацию о Вашей системе:
· Версия Domino сервера
· Версия операционной системы.
· Тип сети и версии сетевых протоколов
· Версии сервисных пакетов установленных для операционной системы
· Конфигурация компьютера сервера
· Имена API программ и задач, работавших на сервере.
* Обратить внимание на любые изменения для элементов Domino или окружающей среды.
Если возможно, возвратитесь к предыдущей конфигурации, чтобы определить, происходит ли проблема.
* Если последнее сообщение на консоли сервера начиналось словом Panic, ... запишите, полное сообщение.
* Если возможно, захватите изображение последнего экрана, который был, показал на консоли.
* Остановите все задачи, запущенные на Domino сервере и затем остановите Domino сервер.
* Если NOTES.RIP или UNIX файл CORE был создан, проверите время и дату файла, который должен совпасть со временем и датой крушения. Переименуйте, и сохраните файл NOTES.RIP, или UNIX файл CORE так, чтобы Domino не перезаписал его в течение будущего крушения. Если необходимо, Lotus Customer Support будет использовать этот файл, чтобы выделить, где произошло крушение.
Обратите внимание, если крушение не производит NOTES.RIP или UNIX файл CORE, сервер, может быть, не имеет достаточного места на диске или ему не хватает памяти.
* Повторно запустите сервер.
* Проверьте представление Miscellaneous Events на наличие ошибок протоколов. Сделайте запись всех записей, которые произошли перед крушением сервера и после. Чтобы делать это, двойным - щелчком запустите соответствующую запись, чтобы открыть ее. В частности ищите *.NSF файл в записях, который может указывать, где крушение произошло. Если специфическая база данных, найдена, которая вызывает крушение, проверьте историю репликации этой базы данных для просмотра дополнительной информации.
* Соберите эти файлы конфигурации:
· CONFIG.SYS - для OS/2
· NOTES.INI - все платформы
· STARTUP.CMD - для OS/2
· PROTOCOL.INI - для OS/2
· NET.CFG - для OS/2 и сетевого обеспечения
· AUTOEXEC.NCF - для сетевого обеспечения
· STARTUP.NCF - для сетевого обеспечения
· Файл диагностики Windows - WindowsNT
Что нужно сделать перед модернизацией клиентов Notes R
Убедитесь, что все локальные базы данных Ваших клиентов используют формат R4. Если Вы имеете некоторые шаблоны в формате R3, например адресные книги или почтовые файлы, Вы должны модернизировать их, по крайней мере, до версии R4.1 перед переходом на R5.
Если Вы модернизируете клиентов R3 в R5, программа установки проигнорирует файл рабочего пространства DESKTOP.DSK и создает незаполненный набор закладок.
Что нужно учесть при модернизации системы до R
Перед проведением модернизации, просмотрите список проблем, которые могут возникнуть в ходе модернизации.
Изменения или замена операционной системы.
Клиент Notes R5 больше не доступен для операционных систем: Windows3.1, IBM® OS/2® Warp и UNIX системы. Пользователи Notes этих системами могут продолжать работать с более ранней версией Notes, или заменить платформу, которая поддерживается R5 клиентом: Windows95, Windows98, WindowsNT, Windows2000 или Macintosh PowerPC.
Domino сервер R5 больше не выпускается для Novell NetWare. Организации, в которых сервер Domino установлен на NetWare, могут продолжать использовать более раннюю версию сервера Domino или заменить платформу сервера на: HP-UX, IBM AIX®, OS/2 WARP, WindowsNT, Windows2000 и Solaris.
Требования к аппаратным средствам.
Убедитесь что Ваше “железо” удовлетворяет требованиям аппаратных средств для Domino и Notes R5. Вам, возможно, понадобится модернизировать компьютер сервера и рабочие места пользователей.
См.. Release notes для более подробной информации.
Модернизация в международной организации.
Если Ваша организация международная, оповестите Ваших коллег о планируемой модернизации. Отделы региональных областей имеют как правило различные инфраструктуры - например, домены с высокими затратами по связи. Одни филиалы могут использовать удаленный доступ к сети, например MS RAS, а другие используют связь по сети LAN, и их требования к системе будут различны. Модернизация может затрагивать каждый филиал по-разному. Например, при переходе на R5, больше не надо иметь отдельный MTA сервер, для каждого набора символов или языка.
Что происходит при репликации между двумя серверами?
* Replicator остается не задействован, пока сервер А не начинает репликацию на сервером B.
* Поскольку акции безопасности вступают в силу до репликации, два сервера подтверждают свою подлинность сравнением своих публичных и личных ключей. Сначала, два сервера находят общие сертификаты. Затем, они проверяют сертификаты друг друга, для гарантирования, их подлинности.
* Два сервера сравнивают списки баз данных, чтобы найти базы данных с идентичными копиями ID.
* Сервера проверяют время последнего изменения каждой из баз данных, чтобы видеть является ли это время более позднее, чем дата успешной прошлой репликации, зарегистрированной в истории репликации. Этот шаг позволяет серверам решить, что в базе данных должно копироваться.
* Для каждой измененной базы данных, сервера строят список из документов, элементов дизайна и изменений в ACL, которые произошли, начиная с последней репликации с другим сервером.
* Для каждого изменяемой базы данных, сервер А проверяет ACL базы, чтобы определить, какие изменения сервер B может сделать в реплике, а сервер B проверяет ACL, чтобы определить то, какие изменения сервер А может сделать.
* Если передача документов, дизайна и изменения в ACL разрешено для документов, сервер реплицирует только поля, которые изменились, при этом не копирует документы полностью.
Для документов, которые были удалены, остаются “окурки”. Чтобы экономить место на диске, Domino удаляет эти “окурки” согласно интервалу чистки, который установлен в назначениях репликаций баз данных.
В зависимости от выше перечисленных действий, происходит одно из следующего:
* Если репликация заканчивает успешно, сервер А вписывает время в истории репликации сервера B, когда репликация была закончена. Сервер B использует такую же печать времени для сервера А, чтобы делать тот же самое.
* Если репликация не заканчивается успешно, отметки времени не регистрируются в истории репликации - так, чтобы будущее репликации будут использовать более раннюю метку времени. Неудавшиеся репликации регистрируются в виде Replication базы данных LOG.NSF.
Рассмотрите следующие аспекты при планировании графика репликаций:
* Топология Репликаций
* Число документов подключения, которое Вам понадобится для реплик
* Тип репликаций
* Время репликаций
* Базы данных, которые будут участвовать в репликациях
* Приоритет баз данных, которые будут реплицироваться
* Время ограничения для репликаций
* Запуск нескольких копий репликатора
Что происходит с базой данных Portfolio в Notes R
Базы данных Portfolio представлены в R5 как закладки интерфейса.
Что происходит с рабочим пространством R при обновлении рабочей станции до R
Notes R5 автоматически конвертирует Ваше рабочее пространство в закладки. Вы можете все еще получить доступ к рабочему пространство, если хотите - но новая навигационная модель делает этот ненужным.
Ваше рабочее пространство, конвертируется в кнопки-закладки, которые расположены на левой стороне экрана клиента.
Notes дает Вам следующие закладки первоначально:
Кнопки-закладки | Описание | ||
Домашняя страница | Ваша домашняя страничка, с которой вы можете получить доступ почти ко всем наиболее важным функциям клиента, включая поиск в Web | ||
![]() Почта | Ваш почтовый ящик | ||
![]() Календарь | Календарь | ||
![]() Адресная книга | Персональная адресная книга | ||
![]() Задачи | Задачи | ||
![]() Репликатор | Закладка Репликатора. | ||
![]() Domino Administrator | Запуск клиента Domino Administrator. | ||
![]() Domino Designer | Запуск Domino Designer. | ||
![]() Избранные закладки | Ваши закладки и ссылки на различные документы и страницы | ||
![]() Базы данных | Базы данных организованные согласно Вашим старым закладкам, которые Вы использовали в рабочем пространстве | ||
![]() Дополнительные закладки | Закладки для поиска баз данных и Web страниц | ||
![]() Ссылки Internet Explorer | Закладки Избранного для Microsoft Internet Explorer | ||
![]() Ссылки Netscape Navigator | Закладки Избранного для Netscape Navigator |
Что происходит с записями для интернет почты?
Notes R5, предоставляет Вам возможность создания записей, которые содержат информацию для доступа к почте POP3, IMAP и использования почты SMTP. Если Вы в R4 имели запись, на использование сервисов POP3, Notes, конвертирует эту информацию. Если Вы используете интернет почту, Notes создает SMTP запись для Вашего пользователя.
Что такое ECL рабочей станции?
ECL – список управления безопасность данных на рабочей станции. ECL ограничивает действия формул и скриптов, запущенных на рабочей станции. Например, ECL может запрещать некоторым пользователям, работающим на компьютере - стирать данные. Как администратор, Вы можете позволить пользователям изменять ECL, или управлять защитой рабочей станции сами.
Чтобы ограничивать доступ к рабочей станции, ECL ищет подпись в базах данных и шаблонах прежде, чем они будут открыты на рабочей станции. ECL проверяет эту подпись, чтобы определить уровень доступа. Каждая система и шаблоны приложений, поставляемых с Notes, содержат подпись. Каждый шаблон или база данных Ваших проектов должна содержать подпись разработчика приложения или администратора.
Чтобы создать ECL рабочей станции, программа Установки копирует ECL из Domino Directory на клиент Notes. Прежде, чем Вы регистрируете пользователей, редактируете ECL, чтобы создать ECL рабочей станции для пользователей.
ECL рабочей станции и опции безопасности.
Выберите из этих опций нужные Вам, для ECL рабочей станции:
![](image/index-image073.gif)
Рис. 59 Диалоговое окно настройки безопасности рабочей станции Notes.
Что такое иерархическая схема имен организации и для чего она нужна?
Прежде, чем Вы установите первый сервер, Вы должны спланировать иерархическую схему имен пользователей и серверов. Иерархическая схема имен - краеугольный камень Domino безопасности, планирование схемы - критическая задача для всей системы.
Иерархическое имя состоит из одного имени организации или большего количества орг. единиц. Вы можете определить, могут ли пользователи и сервера в различных организациях и орг. единицах, связываться друг с другом.
Маленькая компания могла бы иметь организацию с только одним уровнем орг. единиц - например:
![](image/index-image020.gif)
Рис. 6 Пример дерева сертификатов для маленькой организации.
Большая компания могла бы иметь несколько уровней орг. единиц - например:
![](image/index-image021.gif)
Рис. 7 Пример дерева сертификатов для крупной организации, с использованием географического принципа построения дерева сертификатов.
Что такое кластер серверов Domino?
Domino кластер – это группа серверов, от двух до шести, которая позволяет Вам обеспечить пользователям постоянным доступом к данным, балансировать рабочую нагрузку между серверами, улучшать производительность серверов, когда Вы увеличиваете размер Вашего предприятия. Сервера в кластере могут содержать реплики баз данных, которые будут готовы к использованию всегда. Если пользователь пробует открыть базу данных на сервере в кластере, который в данный момент не доступен, Domino открывает реплику этой базы данных на любом сервере в кластере, если реплика доступна. Domino непрерывно синхронизирует базы данных так, чтобы, какую бы ни открывал реплику пользователь, информация, будет всегда идентична.
Lotus Notes® клиенты могут иметь доступ ко всем серверам в Domino кластере. HTTP клиенты, клиенты, использующие интернет браузеры, могут получить доступ только к Domino Web серверам в Domino кластере.
Что такое - профиль установки пользователя?
Перед регистрацией пользователей, Вы можете создать - Профиль установки пользователя, который можно будет использовать в документе пользователя Место вызова, рабочей станции. Назначения по умолчанию, которые Вы определяете, могут включать интернет и Passthru сервера назначения, также как набор определенных баз данных, которые появляются на рабочем пространстве каждого пользователя. Профили установки пользователя, делают регистрацию пользователей легкой.
Когда Вы регистрируете пользователей, Вы связываете их с определенным профилем, так что они получают определенную группу назначений по умолчанию. Вы можете создать несколько профилей в Вашей организации, каждый будет уникальным для определенной группы пользователей. Например, Вы можете создать профили, для регистрации людей в отдел Маркетинга, или людей работающих на Восточном побережье.
Прежде, чем Вы создадите профиль, удостоверитесь, что Вы уже установили Вашу Domino систему и сделали следующего:
* Установили Domain search сервер.
* Web Navigator и InterNotes™ сервер (сервер хранит странички в базе Web Navigator)
* Базы данных, которые Вы хотите, добавлять в рабочее пространство пользователя
* Mobile directory каталоги (или клиент каталога)
* Passthru сервера, LAN сервера, интернет сервера и удаленные сервера. Программа установки пользователя создает документы подключения в персональной адресной книге каждого пользователя, для серверов, которые Вы определяете в Профиле.
* TCP/IP и NDS Notes name сервера
* Host domains where Java applets are assumed to be safe
* Proxy сервера
После создания профиля установки пользователя, Вы можете изменять или добавлять назначения и затем распределять новый профиль пользователям.
Что такое QMRs/QMUs?
QMR и QMU – это так называемые ежеквартальные обновления и Update к ним (QMU), для серверов и рабочих станций Lotus. Выпускаются они довольно регулярно. В основном это обновления, в которых устраняются замеченные ошибки.
При установке очередного обновления, версия продукта повышается. Например, если Вы устанавливаете обновление 5.0 -> 5.0a на сервер, то при удачном завершении работы обновления и запуске сервера, на консоли сервера вместо версии 5.0, Вы увидите - 5.0а и т.д.
В настоящий момент доступны, и актуальны, обновления для версий R4 и R5. Более того, в настоящее время Lotus выпустил ряд дистрибутивов серверов, рабочих станций и обновлений к ним, с национальными интерфейсами. Доступен русский дистрибутив сервера R5, рабочей станции R5, а так же ежеквартальные обновления до версий 5.0.4a.
Программное обеспечение QMRs/QMUs, почти для всех языков, доступны по адресу:
http://www.notes.net/qmrdown.nsf/
Circuit-Level Proxy Firewalls
Circuit-Level Proxy Firewalls, определены как SOCKS сервера, и они работают вне прикладных слоев протокола. Эти сервера позволяют клиентам проходить через центральную службу и соединяться с TCP/IP портом, который клиенты определяют. SOCKS сервера могут идентифицировать исходный адрес запросов и блокировать неправомочных клиентов от соединения с интернетом. Для увеличения уровня безопасности, добавьте к фильтрованию пакетов, Firewall c определенными портам SOCKS. Для большего количества информации по SOCKS, смотрите Web страницу http://www.socks.nec.com/
Domino имеет встроенную поддержку для SOCKS версии 4.2. Большинство SOCKS версий серверов обратно совместимы. Используя встроенную поддержку SOCKS, Вы используете централизованные услуги SOCKS, которые могут существовать в общей сети. Вы можете конфигурировать рабочие станции Notes и Domino сервера, чтобы не использовать SOCKS сервер.
Рабочие места Notes и Domino сервера должны знать, как получить доступ на SOCKS сервер, чтобы использовать его. Чтобы настроить рабочую станцию или сервер, Вы должны определить информацию Proxy в документе Место вызова для рабочей станции или в Server документе для сервера.
![](image/index-image124.gif)
Рис. 107 Пример использования Domino сервера в качестве SOCKS сервера.
Следующий рисунок показывает рабочую станцию Notes и Domino сервер, с использованием встроенной поддержки SOCKS для доступа в интернет, через Domino Passthru сервер, через SOCKS сервер, и наконец через фильтрующий пакеты Firewall.
![](image/index-image125.gif)
Рис. 108 Пример защиты рабочих станций Notes, Domino серверами и серверами Firewall.
Cluster Database Directory
Cluster Database Directory – база данных CLDBDIR.NSF, которая находится на каждом сервере кластера. Cluster Database Directory содержит документ, для каждой реплики базы данных в кластере. Этот документ содержит информацию об имени базы данных, имени сервера, пути к базе данных, ID реплики. Компоненты кластера используют эту информацию, чтобы исполнить их функции.
Cluster Database Directory Manager
Задача Cluster Database Directory Manager (CLDBDIR) на каждом сервере создает базу данных Cluster Database Directory и поддерживает ее актуальном состоянии. Когда Вы добавляете сервер в кластер, Cluster Database Directory Manager создает базу данных Cluster Database Directory на этом сервере. Когда Вы добавляете, какую либо базу данных на сервер в кластере, Cluster Database Directory Manager создает документ в базе данных Cluster Database Directory, который содержит информацию относительно новой базы данных. Когда Вы удаляете базу данных с сервера в кластере, Cluster Database Directory Manager удаляет этот документ. Cluster Database Directory Manager также отслеживает статус каждой базы данных, типа Out of Service или Pending Delete.
Когда имеется изменение в базе данных Cluster Database Directory, задача Cluster Replicator немедленно копирует это изменение на каждый сервер в кластере. Это гарантирует, что каждый член кластера имеет современную информацию относительно баз данных в кластере.
Cluster Administrator.
Cluster Administrator исполняет многие вспомогательные задачи, связанные с кластером. Например, когда Вы добавляете сервер в кластер, Cluster Administrator запускает задачи кластера, типа Cluster Database Directory Manager и Cluster Replicator. Он также добавляет имена задач CLDBDIR и CLREPL в переменную ServerTasks в файле NOTES.INI так, чтобы эти задачи запускались, каждый раз, когда Вы запускаете сервер. Cluster Administrator также запускает процесс администрирования, если он еще не работает. Когда Вы удаляете сервер из кластера, Cluster Administrator удаляет эти задачи из файла NOTES.INI и останавливает эти задачи, если они еще запущенны. Он также удаляет базу данных Cluster Database Directory на этом сервере и чистит записи сервера в кластере на других серверах.
Cluster Replicator.
Задача Cluster Replicator (CLREPL) постоянно синхронизирует данные среди реплик в кластере. Всякий раз, когда изменение происходят в базе данных в кластере, Cluster Replicator немедленно выталкивает изменение в другие реплики в кластере. Это гарантирует, что каждый раз, когда пользователь обращается к базам данных, они видит современную их версию. Cluster Replicator также копирует изменения личных папок, которые сохраняются в базе данных. Каждый сервер в кластере управляет одним Cluster Replicator по умолчанию, хотя Вы можете запускать и большее количество репликаторов, чтобы улучшить выполнение работ.
Cluster Replicator просматривает базу данных Cluster Database Directory (CLDBDIR.NSF), чтобы определить, какие базы данных, имеют реплики на других серверах, членах кластера. Cluster Replicator хранит эту информацию в памяти и использует ее, чтобы копировать изменения на другие сервера. Когда Cluster Replicator обнаруживает изменения в базе данных Cluster Database Directory, он модернизирует информацию в памяти.
Задача Cluster Replicator выталкивает изменения только на серверах кластера
Cluster Manager
Cluster Manager работает на каждом сервере в кластере. Этим действием он создается список серверов в кластере, в настоящее время доступных.
Когда Вы добавляете, сервер в кластере, Domino автоматически запускает задачу Cluster Manager на этом сервере. Пока сервер является частью кластера, Cluster Manager запускается каждый раз, когда Вы запускаете сервер.
Каждый Cluster Manager контролирует кластер. Cluster Manager определяет рабочую нагрузку и готовность другого сервера в кластере.
Задачи Cluster Manager занимаются следующим:
*
Определение, какие сервера принадлежат кластеру. Это делается периодически, контролируя Domino Directory на предмет изменений в поле ClusterName, Server документа и списков членов кластеров.
* Контроль готовности сервера и рабочей нагрузки на кластер.
* Информирование другого Cluster Managers, на предмет замен в кластере серверов и их готовности.
* Переадресация запросов к базам данных, основанных на готовности серверов кластера.
* Балансирование рабочей нагрузки на сервер в кластере.
* Протоколирование переадресации и рабочей нагрузки, баланса в протоколах сервера.
Cluster Manager проверяет Domino Directory, чтобы определить, какой из серверов принадлежит к кластеру. Эта информация хранится в памяти КЭШа сервера (Cluster Name Cache). Cluster Manager использует эту информацию, чтобы обмениваться информацией, с другими Cluster Managers. Cluster Manager также использует Cluster Name Cache, для хранения информации готовности серверов. Эта информация помогает Cluster Manager исполнить функции, балансирования рабочей нагрузки и для переадресации.
Чтобы рассматривать информацию, содержащуюся в Cluster Name Cache, введите на консоли сервера команду:
show cluster
Данные не передаются между двумя серверами, соединенными Null-Modem кабелем
Если Вы соединяете два сервера Null-Modem кабелем, и сервера устанавливают связь, но данные не передаются между ними, пробуют эти шаги, чтобы решить проблему:
* Замените кабель модема или смените порт, который Вы уверено, знаете, что он работает правильно.
* Измените скорость порта. Выбирайте скорость порта, которая соответствует скорости порта, которая установлена с другой стороны.
Dbcache Flush
Закрывает все базы данных, которые являются в настоящее время открытыми в памяти сервера. Используйте эту команду, для обслуживания баз данных
Dial-Up сервер не может инициализировать модем, или синхронизировать его с удаленным модемом
Если LOG.NSF указывает, что сервер не может инициализировать модем, или синхронизироваться его с удаленным модемом. Пробуйте эти пункты, чтобы решить проблему:
* Поверьте, модем, или повторно установить это, с использованием операционной системы.
* Проверьте кабель между сервером и модемом. Удостоверитесь, что кабель исправен и присоединен к правильному порту и не поврежден.
* Удостоверитесь, что порт правильно сконфигурирован.
* Определите более низкую скорость порта.
* Замените модем или RS-232 карту интерфейса, на заведомо рабочую карту.
Directory Assistance
Первый сервер, который был зарегистрирован в домене, содержит Domino Directory и связан с Notes серверами домена. Каждый сервер хранит собственный первичный Domino Directory файл, который называется NAMES.NSF. Directory Assistance - функция, которая позволяет пользователям и серверам использовать информацию из других Directory, которые - не являются первичными для серверов. Вы можете создавать Directory Assistance, для вторичных Domino Directories и для LDAP Directories - например, для Third-Party, LDAP Directories.
Вы создаете базу данных Directory Assistance по шаблону DA50.NTF. Для каждого Directory, который Вы хотите использовать в Directory Assistance, Вы создаете документ Directory Assistance, который описывает Directory и настраивает сервер, чтобы использовать Directory Assistance database.
Directory Assistance – проблемы и сообщения об ошибках
Searches in a secondary Domino Directory configured in directory assistance fail. Удостоверитесь, что поле Domain Name, документа Directory Assistance для вторичного Domino Directory, отличается от первичного Domino Directory, или любых других Domino Directory, сконфигурированных в Directory Assistance. Если поле Domain Name, указанный для вторичного Domino Directory не будет уникально, поиск во вторичном Domino Directory закончится неудачей и Вы получите сообщение - User xxx not found in any Name and Address Book. Если вторичный каталог не связан с Notes доменом, убедитесь что ввели уникальное имя домена, которое отличается от первичного домена сервера, на котором хранится вторичный каталог.
Directory assistance could not access Public Address Book on Server x, error is Server Not Responding. Когда Вы повторно запускаете сервер, который использует Directory Assistance, сервер делает попытку доступа к репликам вторичных Domino Directory, которые указаны как связи (links) c базами данных в Directory Assistance, чтобы можно их загружать в память. Если сервер не может достигнуть реплик, это сообщение появляется на консоли сервера. Чтобы избегать этой проблемы, в документах Directory Assistance, вводите в имена серверов и название файлов для реплик. Избегайте указания связей (links) с базами данных реплик. Это сообщение может появиться, когда сервер использующий Directory Assistance, пытается посмотреть имя во вторичном Domino Directory, на недоступном в данный момент сервере. Как механизм борьбы, Вы можете определить больше чем одну реплику вторичного Directory для Directory Assistance.
Directory catalog – проблемы и сообщения об ошибках
Эти темы описывают проблемы, с которыми Вы можете сталкиваться при работе с Directory catalog
Имя отсутствует в Directory catalog.
Если окажется, что имена отсутствуют в Directory catalog, удостоверьтесь, что задача DirCat строит Directories, как ей было назначено.
* Откройте исходный Directory catalog.
* Выбирайте документ Configuration, затем - Файл – Свойства Документа.
* Щелкает на закладке Поля, вторая закладка свойств.
* Выбирайте поле Directories. Проверите, что задача DirCat может иметь доступ ко всем Directories, указанным в окне. Типично, это означает что сервер, который хранит исходный Directory catalog также, хранит реплики всех Directories.
* Выбирайте поле Since, чтобы видеть дату и время когда задача DirCat последний раз запускалась на всех Directories, указанных в поле Directories. Если любое из следующего имеет место, запустите Dircat задачу снова:
· Если имеется меньшее количество отметок время/дата чем фактических Directories - например, если имеется четыре Directories в поле Directories, но только две отметки время/дата имеются – для задачи DirСat и она попыталось получить доступ к исходному Directory catalog, но потерпела неудачу.
· Если отметки время/дата старше, чем ожидается - задача DirСat возможно еще не завершилась для модернизации исходного Directory catalog.
* Если вышеупомянутые шаги не решают, проблему, редактируйте файл NOTES.INI, чтобы включить установку Log_Dircat=1, которая будет протоколировать информацию задачи DirCat в файл LOG.NSF.
Вы можете использовать эту информацию для решения проблемы.
Domino не может найти реплику Directory catalog на сервере.
Чтобы искать информацию в Directory catalog, сервер должен хранить реплику Directory catalog. Кроме того, Public Directory Profile в первичном Domino Directory сервера должен определять имя файла для Directory catalog. Все реплики Directory catalog на серверах в одном домене должны использовать то же самое имя файла.
Исходный Directory catalog больше по размеру, чем его реплики.
Когда задача DirСat запущенна по исходному Directory catalog, она строит дополнительное скрытое представление, которое содержит информацию Identifying, относительно конфигурации Directories в каталоге. Когда Вы создаете реплику исходного Directory catalog на сервере или когда пользователь создает локальную реплику исходного Directory catalog, реплика не содержит это дополнительное представления, поэтому реплики всегда меньше чем исходный Directory catalog.
Directory Catalogs
Directory Catalog - объединяет записи о пользователях, группах, почтовых базах данных и ресурсах, из одного или нескольких Domino Directories, в отдельную легкую базу данных, с быстрым доступом. Вы можете использовать User Setup Profile, чтобы создать реплику Directory Catalog на клиентских компьютерах Notes, известных как Mobile Directory Catalog. При этом пользователи Notes могут быстро адресовать почту, любому пользователю Вашей организации, даже когда они отключены от сети. Автоматический поиск просматривает Mobile Directory Catalog быстрее, чем Domino Directory на сервере, уменьшая при этом нагрузку на сеть. Вы можете также создать Directory Catalog на сервере, чтобы сервер мог использовать одну базу данных, чтобы искать имена в нескольких Domino Directories. Типично, Вы создаете два Directory Catalogs: Mobile Directory Catalog и Server Directory Catalog.
Directory Catalog может объединять записи нескольких Domino Directories и быть при этом очень маленьким. Например, несколько Domino Directories, которые содержат, больше чем 350,000 пользователей и имеют общее дисковое пространство в 3GB, при объединении в Directory Catalog, вероятно, будут иметь объем только - 50МБ. Вообще, каждая запись в Directory Catalog занимает - 100 байт.
По умолчанию, в записи Directory Catalog включаются следующие поля, которые требуются для поиска почтовых адресов. Вы можете включать и другие поля в каталог.
Поля, включенные по умолчанию | Записи, которые используют эти поля | ||
FullName | Person, Mail-In Database, Resource | ||
ListName | Group | ||
Type | Person, Mail-In Database, Resource, Group | ||
FirstName | Person | ||
MiddleInitial | Person | ||
LastName | Person | ||
Location | Person | ||
MailAddress | Person | ||
Shortname | Person | ||
MailDomain | Person, Mail-In Database, Resource | ||
InternetAddress | Person, Mail-In Database | ||
MessageStorage | Person, Mail-In Database |
Чтобы создать Directory Catalog, Вы создаете базу данных Directory Catalog, используя шаблон базы данных - DIRCAT5.NTF.
Потом Вы создаете документ конфигурации в этой базе данных, в котором Вы определяете имена файлов Directories, чтобы объединить в каталоге поля, которые Вы включили в каталог и другие опции конфигурации. Сервер, на котором хранится Directory Catalog типично, хранит все реплики Directories, объединенные в каталоге.
После конфигурирования базы Directory Catalog, Вы запускаете задачу Directory Cataloger (DirCat) на сервере, который хранит базу Directory Catalog. Задача DirCat суммирует записи для пользователей, групп, почтовых баз данных и ресурсах планирования, из всех сконфигурированных Domino Directories и объединяет записи в Directory Catalog. Если Вы создаете Mobile Directory Catalog, Вы используете User Setup Profile, для репликации клиентам этой базы Notes. Если Вы построили Server Directory Catalog, реплицируете его на все Domino сервера, чтобы использовать его. Чтобы использовать Server Directory Catalog, Вы должны включить его имя файла, в Public Directory Profile в Server документах.
Запускайте задачу DirCat регулярно, чтобы держать Directory Catalog, в синхронизированном состоянии со всеми Directories. создайте график регулярных репликаций для Directory Catalog клиентам и серверам повсюду в Вашей организации.
Для чего используется документ Configuration Settings?
При использовании документов Configuration Settings, Вы можете настраивать маршрутизацию почты для нескольких Domino серверов, одним документом. Документ Configuration Settings включает в себя назначения серверов и Notes или SMTP маршрутизацию. Используйте один документ Configuration Settings для:
* Для всех Domino серверов в Notes домене.
* Для серверов в определенной группе.
* Для определенного сервера.
Вы можете выбрать опцию настроек для всех серверов в Notes домене. Это дает Вам контроль над Вашей системой и может экономить время, потому что Вы можете использовать один документ, чтобы изменить назначения для всего домена.
Каждая установка, которую Вы определяете, применяется к каждому серверу, включенному в документ Configuration Settings. Поэтому, Вы будете нуждаться в нескольких документах конфигураций, если Вы нуждаетесь в различных назначениях для определенных серверов. Например, если Ваш Notes домен включает три географически разделенных сервера, Вы может создать Configuration Settings документ для каждого сервера. Вы можете создавать группы, которые включают все сервера определенного местоположения и использовать место расположения - как имя группы.
Чтобы определить дополнительные ограничения для сервера, который включен в группу, создают отдельный документ Configuration Settings, для определенного сервера. Например, Вы имеете документ Configuration Settings для группы серверов, или для всех серверов. Если в Вашей компании Вы хотите ограничить, или наоборот предоставить некоторые права, определенному серверу, создайте документ Configuration Settings для этого сервера. Документ конфигурации для конкретного сервера, будет иметь приоритет, по отношению к документу конфигурации для группы.
Каждый сервер проверяет документы Configuration Settings в следующем порядке:
* Документ, определенный для сервера
* Документ группы серверов
* Документ по умолчанию
Если имеется несколько документов Configuration Settings для групп, содержащих один и тот же самый сервер, результат будет неопределенный. Например, Вы имеете сервер A и две группы с именем группа 1 и группа 2. Обе группы содержат сервер A. Если Вы создаете документ Configuration Settings для сервера A, все назначения, которые будут установлены в этом документе, будут использоваться сервером A. Если не имеются документа для сервера назначения А, то просматриваются документы Сonfiguration Settings для групп 1 и 2. Однако любые назначения, которые были определены в документе сервера А, не будут действовать в группах 1 и 2. Если после поиска документов для групп 1 и 2, документы не найдены, применяются назначения по умолчанию.
Обратите внимание
на использование полных имен хостов в полях документов Configuration Settings вместо IP адресов. Хотя IP адресы будут работать и полностью поддерживаются.
Создания документов Configuration Settings.
* Из клиента Domino Administrator, выбирайте закладку – Настройка, затем откройте секцию Почта.
* Выбирайте представление – Конфигурации.
* Выбирайте – Add Configuration, чтобы создать новый документ Configuration Settings.
* Выбирайте закладку – Basics.
![](image/index-image104.gif)
Рис. 87 Пример Configuration Settings документа.
* Заполните любые поля и сохраните документ.
Для чего используется документ EDNI?
Документ External Domain Network Information (EDNI) позволяет пользователям соединяться более легко с серверами, которые не принадлежат Вашему домену. Без этого документа, Domino пользователи будут нуждаться в документах подключения, сделанных для серверов, во внешних доменах. EDNI документ из Domino Directory и содержит имена и адреса серверов из внешних доменов, которые используют специфический протокол. Когда пользователи пробуют соединиться с серверами из внешних доменов.
При создании EDNI документа, Вы определяете домен, в котором находятся сервера, и определяете протокол. Во многих случаях, TCP/IP - единственный протокол. Вы также определяете сервер в Вашем локальном домене, который запрашивает информацию, Requesting Server и сервер во внешнем домене, который снабжает информацией Information Server.
Перед созданием EDNI документа, определите, является ли информация о связи, полезна для Вашего домена. Например, если Вы используете NetBIOS протокол, который не может быть маршрутизирован, то прямая связь к внешнему домену не может быть установлена, даже если Вы имеете адрес сети сервера в EDNI документе. Также, если внешний сервер домена имеет несколько TCP/IP портов, адрес возвращенный EDNI документу не может быть адресом соответствующего порта, чтобы его можно было использовать. Потому что каждый протокол имеет собственные ограничения, Вы должны полностью исследовать и проверять способность поиска домена, используя информацию о сети в Вашей организации перед использованием этой особенности.
Вы можете создавать EDNI документ с любого сервера в локальном домене. В намеченное время, которое Вы определяете, Requesting Server соединяется с внешним сервером домена и обновляет информацию об адресах серверов. Эта информацию размещается в запросе на обработку для процесса администрирования серверов. Когда сервер администрирования обрабатывает запрос, он помещает информацию в ответ на EDNI документ, в Domino Directory.
Т.к. Requesting Server собирает информацию из Server документов, внешнего домена, эти документы должны быть сконфигурированы должным образом, чтобы позволять поиск имен серверов.
Например, документ с полным именем хоста или адресом IP, позволит произвести поиск, но документ только с общим именем не может возвратить результаты поиска, т.к. он не содержит IP адреса хоста.
EDNI документ работает с серверной задачей Getadrs. Удостоверьтесь что задача Getadrs, запущена.
Настройка документа External Domain Network Information.
* Из клиента Domino Administrator, выбирайте закладку Настройка.
* Выбирайте Ваш сервер в поле Справочник из, для открытия нужного Domino Directory.
* Выбирайте – Сервер и затем выбирайте – External Domain Network Information.
* Выбирайте – Add External Domain Network Information.
* Заполните эти поля и выбирайте – Сохранить и Закрыть:
Поля |
Значения |
Requesting server |
Имя сервера запрашивающего информацию из внешнего домена |
Information server |
Имя сервера из внешнего домена, отвечающего на запросы |
Domain to query |
Имя внешнего домена |
Protocols to query |
Имя одного протокола, из внешнего домена, который будет обслуживать запрос |
Для чего используются группы?
Группы - списки пользователей, групп и серверов, которые имеют общие черты свойств. Они полезны для списков адресов и списков контроля доступа. Использование групп может упростить задачи администрации.
Например, если Вы создаете группу с именем - Terminations и внесете в нее всех уволенных служащих, Вы можете использовать имя группы в полях, Server документа, для запрещения доступа к этому серверу. Когда служащий увольняется из компании, Вы добавляете его имя к группе Terminators, затем реплицируете Domino Directory на другие сервера Вашего домена. Использование группы Terminations, экономит Ваше время, когда вы вручную добавляете имена в каждый Server документ.
Чтобы создать группу, создаете документ Group в Domino Directory. Вы можете добавить зарегистрированных пользователей в группу, в документ Group. Вы можете добавлять новых пользователей к группе, когда Вы регистрируете их. Предела числу имен, которые Вы можете добавлять к группе - нет. Однако общее количество знаков, используемых для имени группы, не может превышать 15КБ. Чтобы Вашими группами легче было управлять, распределите большой список Ваших пользователей на две или более групп.
По умолчанию, Domino Directory содержит две группы: LocalDomainServers и OtherDomainServers. LocalDomainServers включает в себя все сервера Вашего домена. Domino автоматически добавляет сервера, которые Вы регистрируете в домене к группе LocalDomainServers. Группа OtherDomainServers содержит имена всех серверов, которые не принадлежат Вашему домену. В группу OtherDomainServers, могут быт включены имена серверов других компаний, с которыми Ваша компания связывается.
Каждая группа должна иметь владельца, кто обычно является менеджером баз данных или администраторов.
Обротите внимание, что группа действует в пределах одного домена !
Добавление и удаление полей из Directory Catalog
По умолчанию, Directory Catalog предлагает определенный набор полей; Person, Group, Mail-In Database и Resource documents, из Domino Directory. Однако, Вы можете добавлять поля и удалять поля из Directory Catalog. Например, чтобы посматривать пароли Web клиентов в Directory Catalog, используемым сервером, Вы добавляете поле HTTPPassword к каталогу.
Обратите внимание, что Вы не должны добавить это поле к Mobile Directory Catalog.
По умолчанию, конфигурация Directory Catalog включает поля, которые позволяют пользователям быстро адресовать почту. Лучше оставить эти поля без изменения. Вообще, не добавьте много полей, потому что размер Directory Catalog увеличится. Сделайте Directory Catalog как можно меньше, особенно Mobile Directory Catalog. Добавляйте поля только из форм: Person, Group, Mail-In Database и Resource.
Если Вы настраиваете шаблон Domino Directory, используя подформы, чтобы добавить поля к Person или Group, Вы можете добавить некоторые из этих полей в Directory Catalog. Чтобы сделать это, Вы должны сначала копировать и вставить эти подформы в базу данных Directory Catalog. Чтобы избежать ошибки, используйте клиента Domino Designer, для копирования и вставки полей из форм в шаблон Domino Directory.
Вообще, не добавьте поля, которые изменяются часто, это требует что бы Domino часто модернизировал записи в первичном Directory Catalog, а затем реплицировал изменения.
Всегда добавьте поля AltFullName и AltFullNameLanguage, из форм Person, даже если пользователи не используют альтернативные имена. Добавьте поле Members, из формы Group, чтобы позволить пользователям использовать сервер Directory Catalog для поиска свободное времени.
Чтобы добавить или удалить поля в Directory Catalog сделайте следующее:
* Откройте в режиме редактирования базу данных первичного Directory Catalog.
* В поле Additional fields to include добавьте новые поля, или удалите существующие значения.
* Сохраните и закройте документ.
Добавление публичного ключа Notes в Domino Directory
Вы можете копировать публичный ключ Notes в файл или отправлять его пользователю или администратору, который вставит публичный ключ в персональную адресную книгу или в Domino Directory. Это позволяет пользователям шифровать почту, посланную пользователю в другую организацию.
Как послать публичный ключ по почте.
* Выбирайте Файл – Сервис – Учетная запись.
* Ведите пароль (если требуется).
* Выбирайте кнопку Дополнительно – Отправить общий ключ.
* Адресуйте письмо человеку, который будет вставлять ключ в Domino Directory или в персональную адресную книгу.
* (Необязательно) В поле Копия:, введите имена любых других людей, которых Вы хотите уведомить относительно запроса.
* (Необязательно) Выбирайте - Подписать или Шифровать, чтобы доказать, что Вы - отправитель ID.
* Выбирайте – Отправить.
Копирование публичного ключа в файл.
* Выбирайте Файл – Сервис – Учетная запись.
* Ведите пароль (если требуется).
* Выбирайте кнопку Дополнительно и выбирайте – Копировать общий ключ.
* Спасите содержание буфера обмена в файле.
* Передайте файл тому, кто будет вставлять его в Domino Directory или в персональную адресную книгу.
Вставка публичного ключа в персональную адресную книгу.
* В Вашей персональной адресной книге, создайте документ Контакта для владельца общественного ключа.
* Выбирайте закладку Дополнительно, откройте файл или почтовое сообщение, которое содержит публичный ключ.
* Скопируйте публичный ключ в буфер обмена и вставьте его в поле Заверенный общий ключ, документа Контакта.
* Сохраните документ.
Вставка публичного ключа в Domino Directory.
* Из клиента Domino Administrator, делайте одно из следующего:
· Выбирайте закладку Пользователи и группы, затем – Edit Person.
· Выбирайте закладку Настройка, затем – Edit Server.
* Выбирайте – Certificates – Notes Certificates – Notes certified public keys, в Person документе, или закладка Administration – Certified public keys, Server документа.
* Открывайте файл или почтовое сообщение, который содержит публичный ключ.
* Скопируйте публичный ключ в буфер обмена и вставьте его в одно из полей:
· Поле Public certified key, для иерархических сертификатов Domino.
· Поле Flat name key, для Person документа, неиерархических сертификатов Domino.
Примечание. Вы не может вставлять сертификат интернета в Person документ или Server документ.
* Сохраните Person документ или Server документ.
Добавление WindowsNT групп в Notes
Когда Вы добавляете NT группу в Notes, Вы можете также создавать документ Group в Notes и зарегистрировать членов группы. Если NT группа - группа локальная и содержит глобальные группы как членов группы, Вы можете добавлять эти глобальные группы в Notes и зарегистрировать ее членов как пользователи Notes. Вы можете изменять членство группы перед добавлением их к Notes без того, чтобы воздействовать на NT группу.
Создание новой группы WindowsNT и регистрация ее в Notes.
* Создать новую группу WindowsNT как указано в документации по WindowsNT.
* Если вы будете запрошены, введите пароль для Вашего ID пользователя Notes.
* Выбирайте - Создать группу со следующими параметрами и заполните эти поля, затем щелкайте - OK:
Поля | Значения | ||
Имя группы Notes | Имя Группы | ||
Тип группы | Тип Группы:
* Многоцелевая (по умолчанию) * Только для почты * Только для ACL * Только для Отказов | ||
Описание | Описание для группы | ||
Зарегистрировать пользователей NT в Notes | Члены группы будут зарегистрированные как пользователи Notes. Person документы, Пользовательские ID и почтовые файлы будут созданы для пользователей.
Запретите опцию, если Вы не хотите регистрировать членов группы как пользователи Notes. |
* Выбирайте на кнопке – Состав, если Вы хотите добавлять, или удалить членов групп из NT, затем заполните эти поля:
Поля |
Значения |
Входят |
Удалите из этого списка, тех пользователи, кто больше не будет членом группы этой группы, или добавляют к этому списку имена новых пользователей. |
Не входят |
Добавьте к этому списку тех пользователей, кто не будут членом группы, или удалите из этого списка имена пользователей, если хотите включить их в список членов группы. |
Добавление существующих WindowsNT групп в Notes.
* В окне User Manager Groups, выберите группу, которую Вы хотите добавить в Notes.
* Выбирайте из меню Notes – Добавить выделенные группы/пользователей NT в Notes.
Далее следует процедура регистрации группы описанная в предыдущем пункте.
Документы подключений для репликаций
Для репликаций между двумя серверами, Вы создаете документ подключения, который определяет, как и когда происходит обмен изменениями. Используйте только один документ подключения одновременно, чтобы обратиться ко всем репликам между каждой парой серверов. Создание ненужного документа подключения увеличивает сетевой трафик.
Передача почты и репликации разрешаются по умолчанию, но Вы можете изменять эти установки и использовать отдельные документы подключений, чтобы наметить график для каждой из задач. Этим путем, Вы можете управлять диапазоном времени, или интервалом повторения для реплик и передачи почты раздельно.
Как Вы соединяетесь с серверами для репликаций, зависит от местоположения серверов. Вы можете соединять сервера для реплик по локальной сети или по телефонной линии, с использованием модема или службы удаленного доступа. Кроме того, Вы можете использовать Passthru сервера для репликаций.
Репликации по интернету выполняются, так же как и по сети LAN с использованием TCP/IP. Domino сервер должен быть в том же самом Notes домене, что и Domino сервер, с которым Вы хотите реплицироваться. Если они находятся в разных доменах, сервера нуждаются во взаимных сертификатах.
Настройка документов подключений для репликаций.
Назначайте только один сервер, для соединения в одно и тоже время.
* Удостоверитесь что:
· Вы создали документ подключения, чтобы соединить каждую пару серверов.
· Domino Directory копируется должным образом.
* Заполните эти поля:
Поля | Значения | ||
Usage priority | Приоритет – Normal (используется по умолчанию) | ||
Source server | Имя вызывающего сервера | ||
Source domain | Имя вызывающего домена | ||
Use the Port(s) | Используемый порт и протокол для установления соединения. | ||
Destination server | Имя сервера назначения | ||
Destination domain | Имя домена назначения |
* Выбирайте закладку Routing/Replication и заполните эти поля:
Поля |
Значения |
Replication task |
Выбирайте – Enabled |
Replicate databases of Priority |
Выбирайте приоритет: * High * Medium & High * Low & Medium & High (по умолчанию) |
Replication type |
Выбирайте тип репликации: * Pull Pull * Pull Push (по умолчанию) * Pull Only * Push Only |
Files/Directories to Replicate |
Вы можете выбрать конкретно, что именно реплицировать. Внесите в список несколько баз или каталогов, разделяя их точкой с запятой. |
Replication Time Limit |
Можете указать лимит времени для реплик |
Поля |
Значения |
Schedule |
Выбирайте – Enabled, для разрешения расписания |
Call at times |
Укажите Время вызова сервера назначения По умолчанию 8 AM - 10 PM |
Repeat interval of |
Интервал повторения вызовов По умолчанию 360 минут |
Days of week |
Укажите дни недели для соединений По умолчанию Sun, Mon, Tue, Wed, Thu, Fri, Sat |
Domain Name Service (DNS) и маршрутизация почты
Domain Name Service (DNS) - используется задачей SMTP, чтобы конвертировать имена, типа acme.com, в IP адрес сервера. Сервер получает IP сервера назначения от DNS и посылает должным образом сообщение получателю. Вы должны правильно сконфигурировать DNS, чтобы поддерживать использование SMTP. Чтобы определять адрес IP почтового сервера назначения, Domino делает следующее:
* Просматривает серверную часть домена и адреса каждого получателя в DNS.
* Если DNS находит запись MX, сервер пробует соединять с сервером, из списка записей MX. Если имеются больше чем одна запись MX, сервер пробует соединяться с записью, которая имеет самую низкую стоимость. Если больше чем одна запись MX имеют низкую стоимость, сервер беспорядочно выбирает одну и пробует соединиться с этим сервером.
Обратите внимание, что могут иметься больше чем одна запись MX определяемая для имени домена. Каждая запись содержит адрес IP для хоста сервера.
* Если DNS находит запись, Domino маршрутизирует сообщение по IP адресу.
* Если DNS не находит запись, Domino не может доставить сообщение и посылает сообщение недоставке отправителю.
Вы можете также использовать DNS, чтобы сопоставить IP адрес имени хоста, или имя хоста - IP адресу, чтобы проверить, кто фактически посылает сообщение. Используйте эту проверку, чтобы ограничить доступ Reley через Ваш сервер или запрещать незапрашиваемую коммерческую электронную почту (UCE).
MX записи сопоставляют имени домена одну или большее количество имен хостов. Удобнее использовать имена хостов в записях МХ по некоторым соображениям:
* Некоторые инструменты Third- Party признают только имена хостов, а не IP адреса.
* Если Вы должны заменять или переместить компьютер, Вы можете назначать существующее имя хоста и IP адрес новому компьютеру. Эта замена прозрачна для пользователей и сообщения продолжают маршрутизироваться должным образом.
Когда Вы устанавливаете больше чем одну запись MX имен, Вы можете устанавливать приоритет, который управляют, как DNS выбирает записи. DNS выбирает записи с более низким значением сначала. Например, DNS выбирают 5, а потом 10. Если Вы, имеете больше чем одну запись MX. Если имеются записи с той же самую стоимостью, DNS беспорядочно, выбираете из этих записей MX. Если одна из этих записей MX терпит неудачу - например, потому что сервер недоступен - DNS переходит к следующей записи MX, которая имеет ту же самую стоимость.
Например, acme.com домен имеет четыре MX записи:
MX record: acme.com IN MX 5 mail1.acme.com
MX record: acme.com IN MX 5 mail2.acme.com
MX record: acme.com IN MX 10 mail3.acme.com
MX record: acme.com IN MX 10 mail4.acme.com
Когда сервер пробует соединяться с acme.com, DNS сначала использует запись MX с предпочтением 5. Так как имеется две записи MX с предпочтением 5, DNS беспорядочно выбирает между записью MX mail1.acme.com и mail2.acme.com. Если DNS возвращает запись MX mail1.acme.com, но mail1.acme.com недоступен, DNS возвращается к записи MX mail2.acme.com. Если mail2.acme.com недоступен, обе записи MX со стоимостью 5 потерпят неудачу. DNS тогда выбирает запись MX, которые имеют стоимость 10.
Domino Certificate Authority
Authority Certificate (CA) сертификат, позволяет серверам и клиентам использовать SSL или S/MIME для обмена почтой. CA - ручается за идентичность сервера и клиента, выпуская сертификаты интернета, в которые впечатана с цифровая подпись CA. Цифровая подпись гарантирует клиенту и серверу, что сертификату клиента или сервера можно доверять. Если клиент и сервер идентифицирует, то есть идентифицирует цифровую подпись в сертификате, они могут устанавливать безопасную сессию SSL или обмениваться безопасными сообщениями S/MIME. Если клиент и сервер не может идентифицировать друг друга, они не могут устанавливать безопасные сессии или обменивать безопасными сообщениями.
Вы можете использовать, коммерческий сертификатор, производителей третьих фирм, типа VeriSign. Вы можете также использовать шаблон базы данных Application Authority Certificate (CCA50.NTF) чтобы установить свой Domino CA. Использование Domino CA, избавит Вас от лишних расходов. Кроме того, многие из администраторов уже знакомы с Domino, поэтому не будет требоваться дополнительное обучения.
Таблица администраторских задач Domino CA.
Domino администратор CA ответственен за эти задачи:
Задача | Цель | ||
Подписывать сертификаты для серверов и клиентов | Создаются, имеющие силу сертификаты, для сервера и клиента, которые включают цифровую подпись CA. | ||
Создавать Person документы для клиентов в Domino Directory | Person документ хранит сертификат клиента, который используется для идентифицикации клиента. Поэтому, Person документ должен существовать для клиента прежде, чем запрос может быть одобрен. | ||
Добавлять сертификаты клиентам, использующим сертификаты Third-Party СА в Domino Directory | В течение идентифицикации клиента и шифрования S/MIME, Domino проверяет Person документ на наличие публичного ключа клиента. | ||
Ресертифицировать клиентам, просроченные сертификаты. | Это гарантирует, что сервера и клиенты могут продолжать использовать сертификат. |
Domino Directory
Domino Directory – новое название базы данных Public Address Book или Name Address Book. Domino автоматически создает эту базу на каждом сервере, или реплицирует его с другого сервера. Domino Directory на серверах Domino выполняет две главные цели:
* Это домино каталог, содержит информацию относительно пользователей, серверов, групп и других объектов, которые Вы можете включать в каталог самостоятельно - например, принтеры.
* Эта база данных так же является также инструментом, который администраторы используют, чтобы управлять Domino системой. Администраторы создают документы в Domino Directory, для соединения серверов для репликаций или передачи почты. Регистрируют пользователей и сервера, намечают серверные задачи, для запуска их на сервере Domino.
Типично, Domino Directory связан с Notes доменом. Когда Вы регистрируете пользователей и сервера в домене, Вы создаете Person документы, Server документы в Domino Directory. Эти документы содержат детальную информацию о каждом пользователе или сервере.
Когда Вы устанавливаете первый сервер в Notes домене, Domino автоматически создает на нем базу данных Domino Directory, называет его NAMES.NSF. Когда Вы добавляете, новый сервер в домен, Domino автоматически создает реплику Domino Directory на новом сервере.
Дополнительные сервисы Directory.
В дополнение, Domino Directory предоставляет Вам три службами каталога: Directory Catalog, Directory Assistance и LDAP Service. Эти функции помогают пользователям найти имена пользователя, для адрессования им почты и другую информацию из Domino Directory.
Directory Catalog - объединяет информацию о пользователях, группах из одного или нескольких Domino Directory в маленькую, легкую базу данных. Пользователи Notes, которые используют копию Local Directory Catalog – Mobile Directory Catalog - могут быстро адресовать почту пользователям во всей Вашей организации, даже если организация использует большой каталог, или несколько каталогов пользователей. В организациях, которые используют несколько Domino каталогов, Directory Catalog на сервере объединяет эти каталоги в одну базу данных так, чтобы сервер смог просматривать имена в одной базе данных намного быстрее, чем в нескольких Domino каталогах.
Directory Assistance – эта функция, которая помогает управлять поиском имен в организациях, которые используют несколько Domino каталогов, или адресных книг производителей других почтовых систем (Third-Party). База данных Directory Assistance связывает каждый Domino Directory/LDAP, с определенными иерархическими именами. В процессе поиска Domino сначала просматривает каталог, который содержит имена из этой определенной иерархии.
Lightweight Directory Access Protocol. Вы можете настроить Domino сервер, чтобы он использовал службу LDAP. Вы можете разрешить LDAP клиентам, поиск и изменения информации в базе данных Domino Directory.
Domino Directory и маршрутизация почты
Domino Directory содержит всю информацию, необходимую для маршрутизации почты в Вашей инфраструктуре исключая DNS, который поддерживается отдельно. Domino Directory поддерживает LDAP сервис так, чтобы интернет почтовые клиенты могут использовать LDAP, чтобы отыскивать информацию в Domino Directory, если они имеют доступ к нему.
Таблица маршрутизации.
Когда Вы запускаете Router на сервере, сервер собирает информацию из документов подключений, документов доменов и Server документов, из Domino Directory. Когда пользователь посылает почту, получателю в локальном домене, Router просматривает Domino Directory (или вторичный Directory) и ищет Person документ получателя, который содержит запись о домашнем сервере получателя. Router проверяет таблицу маршрутизации, чтобы определить оптимальный путь к этому серверу и маршрутизирует сообщение согласно этому пути. Если Вы перегружаете сервер, Router повторно вычисляете таблицу маршрутизации.
Имя хоста в системе Domino.
Lotus рекомендует в Domino системе, использовать полные имена хостов, вместо IP адресов. В то время как IP адреса работают и полностью поддерживаются, т.к. IP изменяются более часто, чем имена хостов. Domino не может работать должным образом, если адреса должным образом не обновляются. Например, изменение или реорганизация может потребовать изменения в адресации серверов. В этом случае, если Server документ использует имена хостов, обновления документов не нужны, однако обновление необходимо, если документы содержат IP адреса.