UMGUM.COM (лучше) 

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

25 марта 2010  (обновлено 29 декабря 2014)

Эта публикация отнесена в архив. Она неактуальна.
Ресурс по следующей ссылке является преемником: Поверхностное конфигурирование XMPP-сервера Jabberd2.

OS: Debian Lenny.

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

прямую запись типа "A": jabber.local. A 10.10.2.23
запись типа "SRV" для сервера (устаревшая): _jabber._tcp.jabber.local. IN SRV 5 0 5269 jabber.local.
запись типа "SRV" для сервера: _xmpp-server._tcp.jabber.local. IN SRV 5 0 5269 jabber.local.
запись типа "SRV" для клиента: _xmpp-client._tcp.jabber.local. IN SRV 5 0 5222 jabber.local.

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

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

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

# mysql -h localhost -u root -p
# mysql>source /usr/src/jabberd-2.2.9/tools/db-setup.mysql;

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


Database changed
Query OK, 0 rows affected (0.05 sec)
Query OK, 0 rows affected (0.01 sec)
...
Query OK, 0 rows affected (0.00 sec)

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

# mysql>GRANT select,insert,delete,update ON jabberd2.* to jabberd2@localhost IDENTIFIED by 'password';
# mysql>quit;

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

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

# mysqldump --verbose --first-slave --add-locks --no-create-db --no-create-info --complete-insert --host=localhost --databases jabberd2 --result-file=/path.to.file/jabberd2.sql --user=user --password=password

-- Connecting to localhost...
-- Retrieving table structure for table active...
-- Sending SELECT query...
-- Retrieving rows...
...
-- Retrieving table structure for table vcard...
-- Sending SELECT query...
-- Retrieving rows...
-- Disconnecting from localhost...

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

# mysql -h localhost -u root -p -e "source /path.to.file/jabberd2.sql" jabberd2

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

# mysql -h localhost -u root -p
# mysql>use jabberd2;
# mysql>source /path.to.file/jabberd2.sql;
# mysql>quit;

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

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

# cat /etc/jabberd/c2s.xml

<router>
  <!-- Username/password to authenticate as -->
  <user>jabberd</user>
  <pass>password</pass>  <!-- default: secret -->

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

# cat /etc/jabberd/c2s.xml:

<!-- Router connection configuration -->
<router>
<!-- File containing a SSL certificate and private key to use when setting up an encrypted channel with the router. If this is commented out, or the file can't be read, no attempt will be made to establish an encrypted channel with the router. -->
  <pemfile>/etc/jabberd/server.pem</pemfile>

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

<pidfile>/var/jabberd/pid/c2s.pid</pidfile>

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

<!-- Log configuration - type is "syslog", "file" or "stdout" -->
  <log type='file'>
    <file>/var/jabberd/log/c2s.log</file>
  </log>

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

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

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

<!-- Storage database configuration -->
  <storage>
    <driver>mysql</driver>

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

<!-- MySQL driver configuration -->
  <mysql>
    <host>localhost</host>
    <port>3306</port>
    <dbname>jabberd2</dbname>
    <user>jabberd2</user>
    <pass>password</pass>
    <transactions/>
</mysql>

# cat /etc/jabberd/c2s.xml:

<!-- Authentication/registration database configuration -->
  <authreg>
    <!-- Backend module to use -->
    <module>mysql</module>

# cat /etc/jabberd/c2s.xml:

<!-- MySQL module configuration -->
<mysql>
  <host>localhost</host>
  <port>3306</port>
  <dbname>jabberd2</dbname>
  <user>jabberd2</user>
  <pass>secret</pass>
</mysql>

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

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

<!-- Session manager configuration -->
  <sm>
    <id>domain.name</id>

<!-- Local network configuration -->
<local>
  <!-- Who we identify ourselves as Users will have this as the domain part of their JID. If you want your server to be accessible from other Jabber servers, this IDs must be FQDN resolvable by DNSes. If not set, the SM id is used. -->
  <id>domain.name</id>
  <!--
  <id>vhost1.localdomain</id>
  <id>vhost2.localdomain</id>
  -->
</local>

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

# cat /etc/jabberd/router.xml:

<!-- Router configuration -->
<router>
  <!-- Local network configuration -->
  <local>
    <!-- IP address to bind to (default: 0.0.0.0) -->
    <ip>127.0.0.1</ip>

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

# /etc/init.d/jabberd2.sh restart

Terminating jabberd2 processes ...
  Stopping router...
  Stopping sm-jabber.local...
  Stopping sm-jabber1.local...
  Stopping c2s...
  Stopping s2s...
Initializing jabberd2 processes ...
  Starting router...
  Starting sm-jabber.local...
  Starting sm-jabber1.local...
  Starting c2s...
  Starting s2s...

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

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

<!-- Local network configuration -->
  <local>
    <id realm='domain.name'
        pemfile='/etc/jabberd/server.pem'
        require-starttls='true'
        password-change='true'
    >domain.name</id>

    <ip>0.0.0.0</ip>
    <port>5222</port>
    <ssl-port>5223</ssl-port>
    <pemfile>/etc/jabberd/server.pem</pemfile>
    <httpforward>http://domain.name/</httpforward>
  </local>

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

<!-- Enable XEP-0138: Stream Compression -->
  <compression/>

Поработаем над описанием механизма авторизации клиента на сервере. Поддерживаются два набора механизмов, в блоке "" и, для принудительной работы с 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>

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


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )