Конфигурирование Jabberd 2 ( Поверхностное конфигурирование Jabberd 2. )

OS: Debian Lenny.

Создаем на сервере разрешения доменных имён соответствующие нашему сервису записи (для Bind9):


Записи типа "SRV" для XMPP протокола играют роль схожую с записями типа "MX" для почтового протокола, они помогают размещать и описывать компоненты сервиса на хостах с доменами отличных от указанного в акаунте пользователя сервиса. Если реальное доменное имя сервера и наименование, указанное в акаунте совпадает, то получается ситуация, которая вполне описывается выражением: "кашу маслом не испортишь" В любом случае, лучше указать записи SRV, чем не указать.

Проведем подготовительный работы на СУБД, выбранной нами для хранения данных - MySQL.

В комплекте исходных кодов Jabberd2 есть набор скриптов, позволяющих создать структуры хранения данных. Воспользуемся скриптом "/usr/src/jabberd-2.2.9/tools/db-setup.mysql", применительно к выбранному нами MySQL:


Если вывод отличается от показанного наличием ошибок, то следует пересмотреть своё отношение к происходящему в сторону большей сосредоточенности:



Создадим пользователя, от имени которого будем обращаться к нашим базам:


Если мы переносим базу пользователей со старого сервера в пределах линейки Jabberd2, то можно осуществить вывод данных базы на старом сервере в резервную копию и перенести её на новый. При смене версий с "2.1.1" на "2.2.9" изменения в структуре таблиц незначительны и выражаются в увеличении количества служебных полей, не отражающееся на общем функционале.

Создаем резервную копию базы (необходимо оперировать от имени пользователя, который имеет право блокировать таблицы на сервере для исключения внесения изменений в таблицы во время создания резервной копии так как пользователь jabberd2 таких привилегий не имеет; можно просто остановить сервер MySQL на период изготовления резервной копии и убрать из вызова команды ключ "--first-slave"):



Применяем "дамп" на сервере MySQL:


Лучше бы применять "дамп" непосредственно в консоли MySQL, так как в приведённом выше примере мы не получим вывода информационных сообщений о прохождении вставки данных. Лучше это делать так:


Далее работаем с конфигурационными файлами, расположенными в директории "/etc/jabberd".

Сервис Jabberd2 построен по модульному принципу с аутентификацией модулей по отношению друг к другу. Определимся, с тем, что для всех модульных сервисов нашего Jabberd2 сервера и акаунта сервера баз данных мы применим одинаковые реквизиты доступа, для простоты (все равно, далее localhost обращения не пойдут). Это не имеет никакого отношения к авторизации пользователей сервиса, просто метод обеспечения проверки подлинности подключения модулей. По умолчанию логин и пароль в блоке авторизации модуля равны "jabber" и "secret"; логин оставим неизменным, а вот пароль повсеместно следует сменить на свой. Пример блока авторизации:



Объявляем в конфигурационных файлах о том, что соединение между модулями возможно и нужно с шифрованием с использованием указанного ключа. (блок, подлежащий раскомментированию однотипен во всех конфигурационных файлах):



Обозначим в конфигурационных файлах модулей место расположения pid файлов jabber сервера, для того, чтобы мы могли корректно запускать и останавливать наш Jabberd2. Во всех конфигурационных файлах устанавливаем путь к pid файлу "/var/jabberd/pid/" по принципу, приведённому в примере (обращаем внимание на то, чтобы модули со сходными названиями не использовали чужие файлы pid):


Мне нравится иметь вывод событий каждого приложения или модуля в отдельном файле, а не в общей свалке syslog. Добьемся этого соответствующими исправлениями конфигурационных файлов. Добиваемся примерно такого вида блока "log" в каждом конфигурационном файле с соответствующей адаптацией (обращаем внимание на то, чтобы модули со сходными названиями не использовали чужие журнальные файлы):


Кому-то, возможно, имеет смысл дублировать логи в файл и syslog, особенно, если ведётся централизованная обработка syslog. Думаю, можно попробовать использовать два блока описания журналирования в конфигурационном файле.

Корректируем конфигурационные файлы, доводя до сведения Jabberd2 параметры хранилища данных и реквизиты доступа к нему:









Применим доменные имена нашего jabber сервера, в нашем случае это "jabber.local" и "jabber1.local" в соответствующих файлах конфигурации менеджера сессий:




Заставляем модуль "router" прослушивать только localhost, для обеспечения ещё одного уровня безопасности и обеспечения невозможности несанкционированного подключения модулей с отличных от localhost узлов:



Сейчас можно перезапустить jabberd2 и почитать вывод модулей в журнале событий.



Описываем конфигурацию подключения клиентов к серверу.

В конфигурационном файле "/etc/jabberd/c2s.xml" есть блок описания нашего сервера, в котором можно задать параметры аутентификации, разрешить или запретить регистрацию новых пользователей, смену пароля пользователем, параметры шифрование трафика между клиентом и сервером применительно к каждому доменному имени (в блоке "id realm"), используемому нами (необходимо создать индивидуальные блоки для каждого используемого доменного имени). Параметры имеют "говорящие" имена и значения. Приведем содержимое ответственного за это блока к следующему виду:


В надежде на то, что клиентское программное обеспечение достаточно современно и поддерживает компрессию трафика в соответствии с особой спецификацией, включаем ее поддержку на сервере, убрав комментарии в файле "/etc/jabberd/c2s.xml" на указанный блок:


Поработаем над описанием механизма авторизации клиента на сервере. Поддерживаются два набора механизмов, в блоке "" и, для принудительной работы с SSL, в блоке "". Как я понимаю, при отработке механизмов с блока "", включение шифрования трафика при авторизации и последующей работе на совести клиента, а блок "" вынуждает использовать шифрование без альтернативы. Удаление блока "" при оставленном "" позволяет работать серверу и жёстко предписывает шифровать трафик. Так мы и сделаем, приведем блок описания авторизации к следующему виду, жёстко предписывающему шифровать проходящий от клиента к серверу трафик (параметры работы модуля с СУБД мы определили ранее и опускаем здесь их описание):

<!-- Authentication/registration database configuration -->
<authreg>
  <!-- Dynamic authreg modules path -->
  <path>/usr/lib/jabberd</path>
  <!-- Available authentication mechanisms -->
  <ssl-mechanisms>
    <traditional>
      <plain/>
    </traditional>
    <sasl>
      <plain/>
    </sasl>
  </ssl-mechanisms>
</authreg>

Разрешения и права доступа.

Объявляем в конфигурационном файле "/etc/jabberd/sm-domain.name.xml" пользователей, имеющий максимальные права доступа к любому имеющемуся функционалу (администраторов):

<acl type='all'>
  <jid>admin@domain.name</jid>
  <jid>admin1@domain.name</jid>
</acl>

В блоках, следующих далее, можно объявить пользователей имеющий те или иные привилегии по отношению к другим.

Описываем сервер, так как хотим выглядеть со стороны путём удаления комментирования соответствующего блока в конфигурационном файле "/etc/jabberd/sm-domain.name.xml":

<!-- Server information added to server discovery information in http://jabber.org/network/serverinfo jabber:x:data form. (XEP-0157) -->
<serverinfo>
  <admin-addresses>
    <value>mailto:admin@domain.name</value>
    <value>xmpp:admin@domain.name</value>
  </admin-addresses>
  <abuse-addresses>
    <value>mailto:abuse@domain.name</value>
    <value>xmpp:abuse@domain.name</value>
  </abuse-addresses>
  <feedback-addresses>
    <value>http://domain.name/</value>
  </feedback-addresses>
  <sales-addresses/>
  <security-addresses/>
  <support-addresses/>
</serverinfo>

Определяем параметры ограничения списка пользователей у клиента сервиса:

# cat /etc/jabberd/sm-domain.name.xml

<!-- roster module configuration -->
<roster>
  <!-- maximum items per user roster -->
  <maxitems>250</maxitems>
</roster>

Не забываем, что мы правили конфигурационные файлы полученные от разработчиков с набором исходных кодов и предустановленными настройками "по умолчанию". Произведённые нами правки вполне достаточны для обеспечения более или менее устойчивой работы сервиса, но не являются окончательными. Так же, можно предположить, что в следующих реализациях программного обеспечения приведённых правок может оказаться недостаточно. Да и вообще, более тонкая и глубокая настройка позволит достигнуть большей производительности и стабильности, чем в результате проведённых нами поверхностных работ по конфигурации.