UMGUM.COM (лучше) 

S2S configuration ( Используемый мною файл S2S-конфигурации XMPPсервера Jabberd2. )

17 июля 2012  (обновлено 25 января 2017)

Эта публикация отнесена в архив. Она неактуальна.

Эта публикация скрыта. Она доступна только по прямой ссылке.

Далее полное содержимое используемого сервером "мгновенных сообщений" (на основе протокола XMPP, установка и настройка которого рассматривается в публикациях выше) конфигурационного файла менеджера между-серверных сессий.


<!-- s2s configuration -->
<!-- настройки: серверы к серверам -->
<!-- далее, "ядро XMPP-сервера", пишется как "ядро" -->

<s2s>
  <!-- Идентификатор модуля, с которым таковой подключается к ядру (default: s2s) -->
  <id>s2s</id>

  <!-- Адрес PID-файла (в нём фиксируется ID процесса) -->
  <pidfile>/var/jabberd/pid/s2s.pid</pidfile>

  <!-- Настройки подключения к ядру -->
  <router>
    <ip>127.0.0.1</ip>
    <port>5347</port>

    <!-- Имя пользователя, от имени которого модуль подключается к ядру, и пароль для аутентификации -->
    <user>jabberd</user>
    <pass>strongPassword</pass>

    <!-- Файл, содержащий SSL-сертификат и закрытый ключ, используемые для шифрования подключения модуля к ядру -->
    <pemfile>/usr/local/etc/jabberd/server.pem</pemfile>

    <!-- Настройки переподключения модуля к ядру -->
    <retry>
      <!-- Количество попыток инициирования подключения модуля к ядру (default: 3, без ограничений: -1) -->
      <init>5</init>

      <!-- Количество попыток переподключения модуля к ядру в случае потери связи (default: 3, без ограничений: -1) -->
      <lost>5</lost>

      <!-- Задержка (в секундах) между попытками подключения и переподключения (default: 2) -->
      <sleep>2</sleep>
    </retry>
  </router>

  <!-- Настройки журналирования (поддерживаемые типы: "syslog", "file" или "stdout") -->
  <log type='file'>
    <file>/var/jabberd/log/s2s.log</file>
  </log>

  <!-- Настройки сетевых подключений -->
  <local>
    <!-- Перечисляем IP-адреса несущего сервера, которые будут прослушиваться (default: 0.0.0.0) -->
    <ip>0.0.0.0</ip>

    <!-- Указываем порт, который будет прослушиваться модулем (default: 5269) -->
    <port>5269</port>

    <!-- Если XMPP-сервер работает в системе с более, чем одним IP-адресом, можно явно указать, с какого из них следует инициировать исходящие соединения (если этот параметр не установлен, то соединения будут исходить с адреса, используемого для входящих подключений) -->
    <!--
    <origins>
      <ip>1.2.3.4</ip>
    </origins>
    -->

  </local>

  <!-- Настройки подсистем ввода/вывода -->
  <io>
    <!-- Указываем максимальное количество открытых модулем одновременно "файловых дискрипторов". На каждое подключение модуля к другому XMPP-серверу (по соединению на сеанс связи с пользователем на удалённом сервере, надо полагать) создаётся по дискриптору. Кроме того, обеспечение функциональности самого модуля требует пару-тройку сетевых подключений, сокетов или открытых файлов. В общем, нужно иметь в виду, что допустимое количество не должно быть меньше предполагаемого числа одновременно подключенных удалённых сессий (default: 1024, что на мой взгляд экстремально много для мелкого нераскрученного XMPP-сервера и смешно мало для обжитого пользователями сервера с многолетней историей) -->
    <max_fds>1024</max_fds>

    <!-- Ограничения пропускной способности -->
    <limits>
      <!-- Для предупреждения попыток заслать на сервер ненормально большой объём данных, ограничим максимальный размер (в байтах) XML-блока (следует иметь в виду, что минимальная граница значения: 16384) (для отключения функции следует значение установить в "0"). -->
      <stanzasize>65535</stanzasize>
    </limits>

    <!-- Включаем поддержку сжатия потока передаваемых данных (XEP-0138) -->
    <compression/>

  </io>

  <!-- Настройки контроля активности соединений -->
  <check>
    <!-- Установим интервал (в секундах) проверки активности соединений. По таймеру будут запускаться описанные далее тесты (для отключения функционала следует значение установить в "0") (default: 60) -->
    <interval>60</interval>

    <!-- Queue expiry and connection timeout.

         While a connection is being established and dialback is in
         progress, packets are queued. If a valid connection has not
         been established within this many seconds, the connection
         process will be aborted and the queued packets will be
         bounced. Timeout checks are made for three phases of
         setting up a route authenticated through dialback:
         1. Connection establishment to exchange of stream headers
         2. Initiating dialback (incoming connections)
         3. Completing dialback (incoming and outgoing)

         If stage 1 connection establishment fails and there are
         alternative hosts for this route that have not failed
         recently, they will be tried too before finally giving up.

         0 disables queue expiry. (default: 60) -->
    <queue>60</queue>

    <!-- Queue retry timeout.

         If the queue is older than this timeout, the connection
         will not be retried even if there are alternative hosts
         that have not failed recently.

         0 disables retry expiry. (default: 300) -->
    <retry>300</retry>

    <!-- Пассивный тест: устанавливаем интервал (в секундах), по истечении которого принудительно закрываются соединения, не передающие данных вообще (для отключения функционала следует значение установить в "0") (default: 86400). -->
    <idle>86400</idle>

    <!-- Активный тест: устанавливаем интервал (в секундах), по истечении которого по соединению не проявляющему активности будет отправлен одиночный символ; если на отправленный запрос не придёт ответа, то TCP-соединение будет закрыто (для отключения функционала следует значение установить в "0") (default: 0). -->
    <keepalive>0</keepalive>

    <!-- Устанавливаем интервал (в секундах), по истечению которого запрос на разрешение доменного имени целевого узла отправляется серверу DNS, минуя встроенный "кеш" модуля (для отключения функционала следует значение установить в "0") (default: 300). -->
    <dnscache>300</dnscache>
  </check>

  <lookup>
     <!-- Доменные имена удалённых XMMP-серверов "резольвятся" модулем в IP-адреса по следующим правилам: вначале отрабатываются SRV-записи, а уж если они не найдены, отрабатываются прямые соответствия записей типа "A" IP-адресам. -->

    <!-- Идентификатор SRV-записи, регламентированный для сервера современной спецификацией XMPP -->
    <srv>xmpp-server</srv>

    <!-- Устаревший идентификатор SRV-записи, оставленный для обратной совместимости -->
    <srv>jabber</srv>

    <!-- Минимальное время кеширования результата DNS lookup. -->
    <min-ttl>30</min-ttl>

    <!-- Максимальное время кеширования результата DNS lookup. -->
    <max-ttl>86400</max-ttl>

    <!-- Время, на которое кешируются результаты DNS lookup, полученные из "/etc/hosts" (default: 86400). -->
    <etc-hosts-ttl>86400</etc-hosts-ttl>

    <!-- Время, на которое модуль запомнит, что предыдущая попытка "резольвинга" хоста была неудачной и до истечения указанного интервала не будет её повторять (для отключения функционала следует значение установить в "0") (default: 3600). -->
    <bad-host-timeout>3600</bad-host-timeout>

    <!-- Кеширование DNS-запросов силами модуля можно отключить, на случай, если под боком полнофункциональный NS, да не один (в этом случае повторное кеширование лишено всякого смысла) -->
    <no-cache/>

  </lookup>

</s2s>


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


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