]> git.stg.codes - stg.git/blobdiff - doc/help/ch4.xml
Merge pull request #2 from bobr-kun/MySQL_custom_port
[stg.git] / doc / help / ch4.xml
index 00130ea01a549edc125f8d7e8324e66ddc142c90..b3dc7159123db8d8d124a8794d2cdc7507921086 100644 (file)
@@ -3,7 +3,7 @@
   <para>После инсталляции система должна быть подвергнута процедуре настройки. Обычно следует начинать с настройки сервера.</para>
   <para>Основные конфигурационные  файлы  сервера по умолчанию находятся в каталоге /etc/stargazer. Они включают в себя: основной конфигурационный файл stargazer.conf, файл описания направлений тарификации rules, набор скриптов On* и два каталога — conf-available.d и conf-enabled.d, содержащих конфигурационные файлы отдельных модулей. Для включения какого-либо модуля нужно сделать символическую ссылку на его конфигурационный файл в каталоге conf-enabled.d или прописать его конфигурационную секцию в разделе &lt;Modules&gt; файла stargazer.conf.</para>
   <simplesect>
-    <title>Ð\9dаÑ\81Ñ\82Ñ\80ойка ÐºÐ¾Ð½Ñ\84игÑ\83Ñ\80аÑ\86ионного Ñ\84айла /etc/stargazer/stargazer.conf </title>
+    <title>Ð\9aонÑ\84игÑ\83Ñ\80аÑ\86ионнÑ\8bй Ñ\84айл /etc/stargazer/stargazer.conf </title>
     <para>Файл имеет текстовый формат, содержащий пары ПАРАМЕТР = ЗНАЧЕНИЕ и секции &lt;ИМЯ_СЕКЦИИ ПАРАМЕТРЫ_СЕКЦИИ&gt;. Комментарии в файле начинаются с символа #. В файле описываются общие параметры, которые являются глобальными значениями для всего сервера биллинга, а также параметры соответствующих модулей. Параметры модулей должны быть заключены в секции:</para>
     <programlisting linenumbering="unnumbered">
     &lt;Module имя_модуля&gt;
       <listitem><para>MessagesTimeout — необязательный параметр, устанавливающий время жизни не отправленных сообщений абонентам. Время указывается в сутках. При превышении этого времени сообщение будет удалено, в т. ч. из БД. Если указано значение 0 то не отправленные сообщения никогда не будут удаляться из базы (в частности, это приведет к постепенному росту размера базы, увеличению нагрузки на сервер при авторизации абонентов и к тому что долго отсутствовавший абонент при авторизации получит все пропущенные сообщения). По умолчанию имеет значение 0.</para></listitem>
       <listitem><para>FeeChargeType — необязательный параметр, регулирующий процесс снятия абонплаты. Может принимать значения 0, 1 и 2, по умолчанию имеет значение 0. При значении 0 абонплата снимается как обычно, при значении 1 абонплата снимается только если баланс пользователя положительный или равен нулю, при значении 2 абонплата снимается только если баланс пользователя больше или равен абонплате. Значение 2 следует использовать с осторожностью, т. к. при этом на безлимитных тарифах абоненты получат услугу бесплатно.</para></listitem>
       <listitem><para>ReconnectOnTariffChange — необязательный параметр, указывающий серверу выполнить переподключение пользователя при смене тарифа. Может принимать значения yes и no, по умолчанию имеет значение no. При указании значения yes подключенные пользователи будут отключены непосредственно перед сменой тарифа и подключены сразу после нее. Может быть полезно для управления шейпером.</para></listitem>
-      <listitem><para>ScriptParams — необязательный параметр, который определяет дополнительный набор данных передаваемых в скрипты OnConnect и OnDisconnect. По умолчанию этот параметр пуст. В нем можно указать названия полей записи пользователя, разделенных пробелами, значения которых будут переданы в скрипты после стандартного набора, включающего login, ip, cash, id и dirs. Допустимые имена полей: "cash", "upload", "download", "lastCashAdd", "passiveTime", "lastCashAddTime", "freeMb", "lastActivityTime", "password", "passive", "disabled", "disabledDetailStat", "alwaysOnline", "tariffName", "nextTariff", "address", "note", "group", "email", "phone", "realName", "credit", "creditExpire", "ips", "userdata0" ... "userdata9". Так, например, если указать ScriptParams = tariffName userdata0 то список параметров передаваемых в скрипты будет: login, ip, cash, id, dirs, tariffName, userdata0. Названия параметров регистронезависимые.</para></listitem>
+      <listitem>
+        <para>ScriptParams — необязательный параметр, который определяет дополнительный набор данных передаваемых в скрипты OnConnect и OnDisconnect. По умолчанию этот параметр пуст. В нем можно указать названия полей записи пользователя, разделенных пробелами, значения которых будут переданы в скрипты после стандартного набора, включающего login, ip, cash, id и dirs. Допустимые имена полей:</para>
+        <programlisting linenumbering="unnumbered">"cash", "upload", "download", "lastCashAdd", "passiveTime", "lastCashAddTime", "freeMb", "lastActivityTime", "password", "passive", "disabled", "disabledDetailStat", "alwaysOnline", "tariffName", "nextTariff", "address", "note", "group", "email", "phone", "realName", "credit", "creditExpire", "ips", "userdata0" ... "userdata9".</programlisting>
+        <para>Так, например, если указать ScriptParams = tariffName userdata0 то список параметров передаваемых в скрипты будет: login, ip, cash, id, dirs, tariffName, userdata0. Названия параметров регистронезависимые.</para>
+      </listitem>
       <listitem><para>DisableSessionLog — необязательный параметр позволяющий отключать запить сессий пользователя в БД. Может принимать значения yes и no. По умолчанию установлен в no, то есть запись сессий включена.</para></listitem>
       <listitem><para>FilterParamsLog — необязательный параметр который позволяет фильтровать запись в журнал изменений параметров. Может принимать значения "*" (разрешена запись жернала для всех параметров) или список названий полей записи пользователя, разделенный пробелами. Допустимые имена полей такие-же как и для ScriptParams. По умолчанию имеет значение "*", то есть разрешено журналирование всех параметров. Если указать FilterParamsLog = cash tariffName password то в журнал изменений будут попадать только изменения параметров cash, tariffName и password. Изменения других параметров, например note, group или address в журнал не попадут.</para></listitem>
       <listitem><para>Для именования направлений учета трафика в конфигурационном файле используется секция DirNames:</para>
@@ -67,7 +71,8 @@
     &lt;/Modules&gt;
     </programlisting>
     <para>Если модуль не имеет настраиваемых параметров, то он все равно должен быть указан. Некоторые модули, такие как store module, обязательно требуются при старте и без их подключения система не может быть запущена. По умолчанию для указания конфигурации модулей используются отдельные файлы из каталога conf-enabled.d. Для этого используется директива &lt;IncludeFile ПУТЬ_К_ФАЙЛУ&gt;&lt;/IncludeFile&gt;. Одна директива указана в секции Modules, а вторая в корне файла конфигурации (для store module).</para>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля InetAccess (auth_ia) для работы с авторизаторами абонентов:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>Port – обязательный параметр, определяющий на каком порту сервер будет принимать обращения авторизаторов абонентов. Стандартное значение: 5555.</para></listitem>
           <listitem><para>none - ничего не передавать.</para></listitem>
         </itemizedlist>
       </listitem>
+      <listitem><para>LogProtocolErrors – не обязательный параметр, включающий расширенное журналирование ошибок протокола. Может принимать значения yes или no, значение по умолчанию: no.</para></listitem>
     </itemizedlist>
     <para>Обмен данными авторизатора с сервером осуществляется по протоколу UDP. Можно указать несколько модулей авторизатора auth_ia для авторизации с разных портов.</para>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Модуль авторизации auth_ao.</title>
     <para>Модуль параметров не имеет. Используется для поддержки режима Always Online у абонентов. Без включения этого модуля установка параметра alwaysOnline для абонента эффекта иметь не будет. В режиме Always Online абонент находится в авторизованном состоянии все время, независимо от использования авторизатора. Тем не менее он может быть отключен по причине отсутствия средств на счету, заблокирован администратором или «заморожен». В этом режиме так же возможно использование авторизатора за одним исключением — абонент не может сам вызвать «отключение».</para>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля SGConfig (conf_sg) для работы с конфигуратором:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>Port – обязательный параметр, определяющий, на каком порту сервер будет принимать обращения конфигураторов. Стандартное значение: 5555.</para></listitem>
     </itemizedlist>
     <para>Обмен конфигуратора с сервером осуществляется по протоколу TCP. Можно указать несколько модулей конфигуратора с указанием разных портов.</para>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля файловой БД:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>WorkDir – обязательный параметр, указывающий серверу где находится рабочая директория с файлами БД. Стандартное значение: /var/stargazer.</para></listitem>
       <listitem><para>StatOwner, StatGroup, StatMode – обязательные параметры, описывающие владельца, группу и права доступа на файлы статистики (stat) абонента соответственно. StatOwner должен содержать корректное имя пользователя системы (см. файл /etc/passwd), стандартное значение: root. StatGroup должен содержать корректное название группы в системе (см. файл /etc/group), стандарное значение: root. StatMode должен содержать корректные права на файл (только ugo-биты), стандартное значение: 640.</para></listitem>
       <listitem><para>UserLogOwner, UserLogGroup, UserLogMode – обязательные параметры, описывающие владельца, группу и права доступа на файлы журналов (log) абонента соответственно. UserLogOwner должен содержать корректное имя пользователя системы (см. файл /etc/passwd), стандартное значение: root. UserLogGroup должен содержать корректное название группы в системе (см. файл /etc/group), стандарное значение: root. UserLogMode должен содержать корректные права на файл (только ugo-биты), стандартное значение: 640.</para></listitem>
     </itemizedlist>
-      <para>При создании каталогов (например для записи детальной статистики) используются те-же права, но с добавлением x-бита для всех ненулевых полей. Например: для 640 будут права 750, а для 644 будут 755. Для записи детальной статистики используются параметры StatOwner, StatGroup и StatMode. Для записи сообщений используются параметры ConfOwner, ConfGroup и ConfMode.</para>
-    </sect2>
-    <sect2>
+    <para>При создании каталогов (например для записи детальной статистики) используются те-же права, но с добавлением x-бита для всех ненулевых полей. Например: для 640 будут права 750, а для 644 будут 755. Для записи детальной статистики используются параметры StatOwner, StatGroup и StatMode. Для записи сообщений используются параметры ConfOwner, ConfGroup и ConfMode.</para>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля для работы с СУБД Firebird:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>Server – необязательный параметр, описывающий адрес сервера, на котором расположена СУБД. Может быть доменным именем или IP-адресом. Значение по умолчанию: localhost.</para></listitem>
         </itemizedlist>
         </listitem>
     </itemizedlist>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля для работы с СУБД PostgreSQL:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>Server – необязательный параметр, описывающий адрес сервера, на котором расположена СУБД. Может быть доменным именем или IP-адресом. Значение по умолчанию: localhost.</para></listitem>
       <listitem><para>Password – необязательный параметр, описывающий пароль пользователя БД. Значение по умолчанию: 123456.</para></listitem>
       <listitem><para>Retries — необязательный параметр, описывающий количество попыток переподключения к СУБД в случае потери связи. Попытки производятся с интервалом в 1 секунду. Значение по умолчанию: 3.</para></listitem>
     </itemizedlist>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля для работы с СУБД MySQL:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>Server – обязательный параметр, описывающий адрес сервера, на котором расположена СУБД. Стандартное значение: localhost.</para></listitem>
       <listitem><para>User – обязательный параметр, описывающий имя пользователя БД. Стандартное значение: stg.</para></listitem>
       <listitem><para>Password – обязательный параметр, описывающий пароль пользователя БД. Стандартное значение: 123456.</para></listitem>
     </itemizedlist>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля ping для пингования абонентов:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>PingDelay – обязательный параметр, определяющий, время в секундах между пингами одного и того же абонента. Стандартное значение: 15.</para></listitem>
     </itemizedlist>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля Remote Script Executer (remote_script) для передачи команд на исполнение скриптов на NAS:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>SendPeriod – обязательный параметр, определяющий время в секундах между посылками подтверждений того, что клиент находится в состоянии Online. Стандартное значение: 15.</para></listitem>
       <listitem><para>Port – обязательный параметр, определяющий номер порта через который будет происходить обмен данными между сервером биллинга и клиентом. Может принимать значения от 1 до 65535, стандартное значение: 9999.</para></listitem>
       <listitem><para>SubnetFile — обязательный параметр, представляющий собой путь к файлу с описанием соответствия сетей и NAS'ов. Стандартное значение: subnets. При указании относительного пути поиск будет производиться в каталоге с настройками (обычно это /etc/stargazer, но может быть переопределено указанием пути в качестве параметра при старте дэмона). Файл имеет формат: &lt;сеть в CIDR-нотации&gt; &lt;адрес NAS'а&gt;. Количество сетей не ограничено. Файл перечитывается заново при посылке процессу сигнала SIGHUP. Если файл содержит ошибки при старте дэмона — система не будет запущена. Если файл содержит ошибки при перечитывании — будут использоваться старые значения.</para></listitem>
     </itemizedlist>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля radius для поддержки авторизации и аккаунтинга пользователей через сервер FreeRADIUS:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>Port — обязательный параметр, определяющий порт, на который будут приходить запросы от FreeRADIUS. Может принимать значение от 1 до 65535, стандартное значение: 6666.</para></listitem>
       <listitem><para>AcctServices — необязательный параметр, задающий список сервисов, по которым будет производится аккаунтинг. При успешной авторизации в этих сервисах абонент переходит в состояние Online и для него производится подсчет трафика. Необходимо заметить, что в этом случае трафик захватывается как обычно, без использования возможностей протокола RADIUS (через пакет аккаунтинга InterimUpdate), т.к. это не позволяет классифицировать полученный трафик по направлениям. Названия сервисов в списке должны разделяться пробелами, по умолчанию этот параметр пуст.</para></listitem>
     </itemizedlist>
     <para>Обмен данными между плагином и FreeRADIUS происходит по протоколу UDP.</para>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля XML-RPC (conf_rpc) для поддержки протокола управления XML-RPC:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>Port — обязательный параметр, определяющий порт на который будут приходить запросы XML-RPC. Может принимать значения от 1 до 65535, стандартное значение: 8080.</para></listitem>
       <listitem><para>CookieTimeout — необязательный параметр, задающий время существования авторизационного Cookie в случае отсутствия активности в секундах. Значение по умолчанию: 1800 (30 минут).</para></listitem>
     </itemizedlist>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Модуль захвата трафика cap_ether (только для ОС Linux).</title>
     <para>Модуль не имеет параметров. Для захвата трафика используются так называемые «raw sockets», которые позволяют получить доступ к Ethernet-фреймам. Перехватывается весь трафик попадающий в сетевую подсистему ядра. При использовании обычной маршрутизации трафик будет посчитан два раза: на входящем интерфейсе и на исходящем. При использовании NAT удвоения трафика не происходит, так как NAT заменяет адрес источника. При интенсивном сетевом обмене или при высокой нагрузке на сервер, на котором происходит захват трафика, модуль может терять отдельные пакеты. Процент потерь тем выше чем выше скорость прохождения пакетов и чем выше загрузка сервера. Модуль рекомендуется использовать для ознакомления или в небольших сетях до 100 абонентов с трафиком до 100 Мбит.</para>
-    </sect2>
-    <sect2>
-    <title>Модуль захвата трафика cap_ipq (только для ОС Linux).</title>
+  </simplesect>
+  <simplesect>
+    <title>Ð\9cодÑ\83лÑ\8c Ð·Ð°Ñ\85ваÑ\82а Ñ\82Ñ\80аÑ\84ика cap_ipq (Ñ\83Ñ\81Ñ\82аÑ\80евÑ\88ий, Ñ\82олÑ\8cко Ð´Ð»Ñ\8f Ð\9eС Linux).</title>
     <para>Модуль не имеет параметров. Для захвата трафика используются передача пакетов из пространства ядра в пространство пользователя посредством очередей (ip queue). Для его работы требуется поддержка ip queueing в ядре (модуль ip_queue.ko) и специальная настройка файрвола (правило QUEUE для iptables). Следует обратить внимание на то что обычно требуется два правила в файрволе для полного перехвата: одно для входящих пакетов и одно для исходящих. Модуль гарантирует 100% перехват трафика, но так как пакет перед отправкой обязательно проходить через плагин — может приводить к снижению пропускной способности роутера. При этом следует обратить внимание на нагрузку на процессор, возможно имеет смысл заменить его на более производительный. В противном случае стоит рассмотреть использование модуля cap_nf для захвата трафика.</para>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
+    <title>Описание параметров модуля захвата трафика cap_nfqueue (только для ОС Linux).</title>
+    <itemizedlist mark="opencircle">
+      <listitem><para>queueNumber — не обязательный параметр, определяющий номер очереди netfilter из которой будет происходить захват трафика.</para></listitem>
+    </itemizedlist>
+    <para>Для захвата трафика используются передача пакетов из пространства ядра в пространство пользователя посредством очередей (netfilter queue). Модуль является заменой устаревшего cap_ipq. Для его работы требуется поддержка netfilter queueing в ядре (модуль xt_NFQUEUE.ko) и специальная настройка файрвола (правило NFQUEUE для iptables). Следует обратить внимание на то что обычно требуется два правила в файрволе для полного перехвата: одно для входящих пакетов и одно для исходящих. Модуль гарантирует 100% перехват трафика, но так как пакет перед отправкой обязательно проходить через плагин — может приводить к снижению пропускной способности роутера. При этом следует обратить внимание на нагрузку на процессор, возможно имеет смысл заменить его на более производительный. В противном случае стоит рассмотреть использование модуля cap_nf для захвата трафика.</para>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля cap_bpf для захвата трафика (только для ОС FreeBSD):</title>
     <itemizedlist mark="opencircle">
       <listitem><para>iface — обязательный параметр, определяющий на каком интерфейсе будет происходить захват трафика. Параметр может быть задан более одного раза.</para></listitem>
     </itemizedlist>
     <para>Для захвата трафика используется инфраструктура Berkeley Packet Filter, представляющая собой «продвинутый» аналог «raw sockets». Так как интерфейсы для перехвата указываются явно, дублирования трафика при обычной маршрутизации не наблюдается. Фильтрование пакетов не используется, перехват происходит по мере возможности, по этому этот модуль, как и cap_ether, тоже может терять пакеты при высокой нагрузке на сервер или высокой скорости прохождения пакетов. Рекомендуется использовать для ознакомления или для небольших сетей до 100 абонентов с трафиком до 100 Мбит.</para>
-    </sect2>
-    <sect2>
+  </simplesect>
+  <simplesect>
     <title>Модуль захвата трафика cap_divert (только для ОС FreeBSD).</title>
-    <para>Модуль не имеет параметров. Для захвата трафика используются divert-сокеты. Как и IPQ эта технология использует прохождение пакетов через пространство пользователя. Для работы модуля требуется поддержка divert-сокетов в ядре и специальная настройка файрвола. Для передачи пакета в пространство пользователя в файрволе используется правило divert или tee. Первое правило работает аналогично цели QUEUE для iptables — пропускает пакет через пространство пользователя перед отправкой. Соответственно, это может вызвать те-же проблемы с пропускной способностью роутера. Правило tee передает в пространство пользователя копию пакета, а оригинал отправляет дальше. Такой подход позволяет избежать снижения пропускной способности сервера при высокой нагрузке на него, так как исключается ожидание пакета в время его нахождения в пространстве пользователя.</para>
-    </sect2>
-    <sect2>
+    <itemizedlist mark="opencircle">
+      <listitem><para>Port — необязательный параметр, указывающий порт на который будет происходить перенаправление трафика. Значение по умолчанию: 15701.</para></listitem>
+      <listitem><para>DisableForwarding — необязательный параметр, отключающий форвардинг пакетов. Значение по умолчанию: no.</para></listitem>
+    </itemizedlist>
+    <para>Для захвата трафика используются divert-сокеты. Как и IPQ эта технология использует прохождение пакетов через пространство пользователя. Для работы модуля требуется поддержка divert-сокетов в ядре и специальная настройка файрвола. Для передачи пакета в пространство пользователя в файрволе используется правило divert или tee. Первое правило работает аналогично цели QUEUE для iptables — пропускает пакет через пространство пользователя перед отправкой. Соответственно, это может вызвать те-же проблемы с пропускной способностью роутера. Правило tee передает в пространство пользователя копию пакета, а оригинал отправляет дальше. Такой подход позволяет избежать снижения пропускной способности сервера при высокой нагрузке на него, так как исключается ожидание пакета в время его нахождения в пространстве пользователя. При использовании правила tee рекомендуется отключать форвардинг пакетов.</para>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля cap_nf для захвата трафика:</title>
     <itemizedlist mark="opencircle">
       <listitem><para>TCPPort — необязательный параметр, указывающий порт который будет использоваться для приема данных при работе с NetFlow-proxy. Стандартное значение: 9996. Если параметр не указан — прием по протоколу TCP производиться не будет.</para></listitem>
       <listitem><para>UDPPort — необязательный параметр, указывающий порт для приема NetFlow-дагарамм. Стандартное значение: 9996. Если параметр не указан — прием датаграмм по протоколу UDP производиться не будет.</para></listitem>
     </itemizedlist>
     <para>В явном виде захват трафика не происходит. Данные о нем поступают от NetFlow-сенсора посредством протокола NetFlow. Это позволяет физически разделить перехват трафика и его учет. NetFlow-сенсор перехватывает трафик, и собирает данные о сессиях (в контексте UDP это передача данных между двумя портами в одном направлении). Информация о сессии включает в себя IP-адреса источника и назначения потока пакетов, номера портов источника и назначения, суммарную длину пакетов и различные дополнительные данные. NetFlow-трафик существенно меньше трафика, который он описывает, так как передается мета-информация а не сами данные. С учетом этого факта и того что биллинговый сервер теперь может не заниматься маршрутизацией пакетов и NAT'ом это существенно снижает нагрузку на него. Этот плагин рекомендуется использоваться в крупных сетях с развитой топологией, включающей несколько NAS'ов. Возможно использование совместно с аппаратными маршрутизаторами Cisco (они единственные имеют лицензию на аппаратную реализацию NetFlow). В качестве NetFlow-сенсоров можно использовать такие утилиты как fprobe, softflowd или ipcad. Так же можно использовать модуль ядра ipt_netflow (Linux) или ng_netflow (FreeBSD).</para>
-    </sect2>
-    <sect2>
     <itemizedlist mark="opencircle">
       <listitem><para>Server — обязательный параметр, указывающий IP-адрес сервера на котором находится snmpd. Стандартное значение: 127.0.0.1.</para></listitem>
       <listitem><para>Port — обязательный параметр, указывающий порт на сервере через который будет происходить взаимодействие с snmpd. Стандартное значение: 199.</para></listitem>
       <listitem><para>Password — необязательный параметр, задающий пароль для авторизации плагина в snmpd. По умолчанию пароль не используется.</para></listitem>
     </itemizedlist>
+  </simplesect>
+  <simplesect>
     <title>Описание параметров модуля smux для мониторинга состояния Stargazer:</title>
     <para>Модуль позволяет производить мониторинг биллинга средствами протокола SNMP. Он не реализует полноценный SNMP-сервер а лишь взаимодействует с существующим дэмоном snmpd, регистрируясь в нем для обслуживания определенного дерева параметров. В комплекте с биллингом идет MIB, описывающий доступные параметры для мониторинга. Параметры разделены на 6 секций, находящихся в узле stg24:</para>
     <itemizedlist mark="opencircle">
     <para>Для доступа к значениями параметров можно использовать следующую команду: snmpget -v2c -ccommunity_w -m +STG-MIB 10.0.0.1 stg24.users.totalUsers. Ключ -v указывает используемую версию протокола. На сегодняшний день существует 3 версии протокола: 1, 2 и 3. Версия 1 считается устаревшей и почти не используется. Версия 2 существует в двух модификациях: user-based (с суффиксом «u») и community-based (с суффиксом «c»). Версия 3 является самой новой и предоставляет широкие средства аутентификации, контроля целостности и шифрования. Ключ -c задает community для доступа к серверу. Ключ -m позволяет подключать дополнительные mib-файлы. При использовании доступа к параметрам по названию необходимо подключить mib-файл STG-MIB. Далее следуют два аргумента: адрес SNMP-сервера и название параметра. Утилита snmpget позволяет получить значение скалярных параметров — параметров имеющих только одно значение. Для доступа к таблицам и деревьям используется утилита snmpwalk имеющая такой-же синтаксис.</para>
     <para>Можно обращаться к параметрам по цифровому OID: snmpwalk -v2c -ccommunity_w 10.0.0.1 .1.3.6.1.4.1.38313.1.2. В этом случае загружать дополнительные mib-файлы не требуется. «.1.3.6.1.4.1» - OID enterprise-ветки всего дерева SNMP. «38313» - официально полученный от IANA (http://www.iana.org) enterprise-номер, уникально идентифицирующий дерево параметров Stargazer. Следующая за ним цифра 1 говорит о том что мы работаем с узлом stg24. «.1.3.6.1.4.1.38313.1.2» - OID таблицы tariffUsageTable.</para>
     <para>Для того чтобы установить взаимодействие между плагином smux и дэмоном snmpd нужно провести дополнительную настройку последнего. А именно: указать в конфигурационном файле (обычно это /stc/snmp/snmpd.conf) параметр smuxpeer (OID обслуживаемый плагином, в нашем случае это .1.3.6.1.4.1.38313) и smuxsocket (IP-адрес с которого будут приходить пакеты от smux-плагина).</para>
-    </sect2>
   </simplesect>
   <simplesect>
-    <title>Ð\9dаÑ\81Ñ\82Ñ\80ойка ÐºÐ¾Ð½Ñ\84игÑ\83Ñ\80аÑ\86ионного Ñ\84айла /etc/stargazer/rules</title>
+    <title>Ð\9aонÑ\84игÑ\83Ñ\80аÑ\86ионнÑ\8bй Ñ\84айл /etc/stargazer/rules</title>
     <para>Файл rules описывает парвила классификации трафика по направлениям тарификации. Это текстовый файл, каждая строка которого описывает одно правило классификации. Формат строки файла:</para>
   <programlisting linenumbering="unnumbered">  
   &lt;протокол&gt; &lt;CIDR&gt;[:&lt;порт&gt;[-&lt;порт&gt;]] &lt;направление&gt;