Ваш регион:
Заказать звонок
Имя пользователя: Пароль:
 
Личный кабинет
Введите Ваше имя
Закрыть

Контакты

senao@senao.ru

КОНТАКТЫ

Как нас найти ??

- - - - - - - - - -- - - -
Москва:
м. Бауманская
+7495-782-43-43
+7495-506-00-44
+7495-506-00-88

- - - - - - - - - - -- - - -

Санкт - Петербург:
Минеральная 13
+7812-612-70-40
+7951-664-00-22
+7963-750-03-43

Яндекс.Метрика

Настраиваем биллинг UTM с Mikrotik

  • Тех Инфо
  • Настраиваем биллинг UTM с Mikrotik

    В этой статье мы опустим пояснение, что такое биллинг, как устроены системы учета трафика, что такое VoIP-биллинг или зачем это все необходимо. Мы остановимся на конкретно взятом программном и аппаратном обеспечении, достаточных для создания современной, мощной и масштабируемой системы учета работы пользователей в сети Интернет. Предполагается, что читатель уже знаком с общими понятиями, которыми мы будем оперировать дальше.

    Классификация

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

    Бесплатные или условно бесплатные:
    FreeNibs;
    http://netbilling.nm.ru;
    NeTAMS;
    Abills;
    и д.р.

    Платные
    NetUP UTM;
    IPSoft Billing;
    LANBilling;
    Traffic Inspector;
    и д.р.

    Для лучшего понимания текущей классификации современных биллинг-систем взгляните на эту схему:


    Общая структура биллинговых систем.

    В случае с использованием авторизации пользователей, отличной от Radius, практически всегда в биллинг уже встроены средства снятия, обработки и записи наработанной статистики своими внутренними средствами. Если же NAS (Network Access Server) и сам биллинг разнесены на разные компьютеры, то для снятия статистики используются уже проверенные средства: с помощью Alive пакетов от NAS сервера, протокола SNMP (Simple Network Monitoring Protocol) или NetFlow. Использование протокола NetFlow (протокол, разработанный компанией Cisco специально для мониторинга сети) позволяет получать подробнейшую информацию о сетевой активности пользователей. Именно поэтому данный способ сбора статистики является основным для построени мощных и отказоустойчивых систем.

    Поставленная задача

    Нам необходимо установить и настроить систему учета работы пользователей Интернет, используя биллинг UTM5 и программно-аппаратную платформу FISC MTIK Mikrotik RouterOS, котора будет обслуживать одновременно до 300 пользователей. В нашем случае выбор UTM5 очевиден. За сравнительно малой ценой кроется высокий потенциал, который можно будет в полной мере раскрыть при создании тарифных планов, работе с клиентами, создании отчетов и другими аспектами работы системы. Для сбора статистики будем использовать технологию NetFlow, для хранения информации базу данных MySQL. В качестве операционной системы для биллинга выберем Debian Etch. Выбор операционной системы лучше останавливать на той, которую вы достаточно хорошо знаете.

    Вкратце опишем схему работы нашей будущей системы:


    Структура взаимодействия UTM c NAS

    Сервер доступа при поступлении запроса от клиента на подключение обязан будет передать их Radius-модулю биллинга. Последний должен обратиться к ядру, чтобы получить от него разрешение на авторизацию, и в случае положительного ответа, другие параметры: адрес клиента и скорость. После подключения, сервер доступа будет в режиме реального времени передавать всю информацию о трафике с сетевых интерфейсов ядру биллинга, которое при наступлении условия отключени пользователя отправит сигнал в модуль Firewall, который получит доступ к командной строке сервера доступа и сбросит нужного клиента или заблокирует ему доступ.

    Данная схема прозрачна и надежна, что подтверждает ее широкое применение на практике. Использование в качестве сервера доступа операционной системы Mikrotik во многом обусловлено низкой стоимостью одной лицензии, удобных способов настройки, надежностью. К тому же в ней изначально встроены средства для работы с NetFlow и авторизации пользователей по протоколу Radius.

    Описание аппаратной части

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

    Для биллинг-сервера мы используем компьютер следующей конфигурации:
    процессор: AMD Athlon XP 1700+;
    память: 2 Гбайт;
    жесткие диски: 3 х 200 Гбайт SATA в программном RAID 5;
    блок питания: 450 Вт;
    сетевая карта: любая, желательно с аппаратной обработкой пакетов на чипах 3com, Intel;
    корпус: любой с хорошей вентиляцией.

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

    Особое внимание стоит обратить на жесткие диски. Использование программного или аппаратного RAID строго обязательно, если вы не хотите в один прекрасный день потерять информацию о трафике или клиентах. Также стоит предусмотреть возможность резервного копирования данных на внешние носители. Не стоит экономить и на оперативной памяти, так как в нашем случае в именно от нее будет зависеть скорость работы сервера в целом.

    В качестве серверов доступа (NAS) логичнее всего будет использовать уже готовые платформы, поставляемые самими разработчиками Mikrotik или же сторонними производителями. В нашем случае мы будем использовать платформы Lex, поставляемые компанией Ниеншанц - Телеком с предустановленной лицензионной версией RouterOS Mikrotik.

    Выбор в пользу такого решения приведем следующие аргументы:
    производительности платформы достаточно для решения наших задач;
    система имеет очень скромные габариты и может быть легко установлена даже в самом ограниченном пространстве;
    большая гибкость, масштабируемость и надёжность системы;
    отсутствие подвижных частей (кроме жесткого диска), и, как следствие, практическое отсутствие шумов и износа;
    достаточная устойчивость и проверенная временем надежность;
    наличие трех Ethernet-портов, что легко позволит в случае надобности организовать DMZ-зону или настроить маршрутизацию между сетями;
    малая потребляемая мощность;
    наличие лицензионной версии операционной системы Mikrotik на Flash карточке.

    Этот список можно продолжать и дальше, однако давайте на самом деле убедимся, хватит ли нам производительности этой платформы и на чем основана сказанная выше "стабильность".

    Аппаратная платформа

    В нашей самой первой статье об операционной системе Mikrotik мы использовали для тестирования компьютер на базе процессора Pentium 166 МГц с поддержкой инструкций MMX. Остальная конфигураци также не блестала: 200 Мбайт жесткий диск, 128 Мбайт ОЗУ и две сетевые карты. Всего этого вполне хватало, чтобы передавать пакеты из одного места в другое. В связи с этим не стоит удивляться малой вычислительной мощности рассматриваемого маршрутизатора. В его арсенале числится 500 МГц процессор VIA C3 и системная плата, куда он впаян, остальные компоненты (модуль памяти, жесткий диск) вам придется установить самостоятельно.

    Материнская плата от Lex System не позволит собрать на ее основе суперфункциональный "комбайн", как в случае обычной системной платы, но зато она отлично подходит для возложенных на нее задач. Рассмотрим характеристики платы более подробно:


    процессор - VIA C3 (500 МГц, 376 PIN, EBGA);
    системная шина - 100/133 МГц;
    чипсет - VIA PLE133 (VT8601 + VT82C686B);
    интегрированное графическое ядро с возможностью выделения 8 Мбайт памяти;
    один слот памяти PC133 SDRAM максимальным объемом до 512 Мбайт;
    звуковой кодек AC‘97 2.1;
    три сетевые карты 10/100 Мбит/с на основе контроллеров Realtek RTL8100B;
    один IDE-разъем для подключения двух устройств (с поддержкой UDMA100);
    один 44-жильный IDE-разъем для подключения жестких дисков форм-фактора 2.5";
    один разъем DOC(Disk-On-Chip);
    один 50-контактный разъем для подключения флэш-карт формата CompactFlash.

    Процессор, как мы упоминали выше, заменить не удастся. Его производительность по современным меркам довольно низкая, однако для одновременного обслуживания 80-150 клиентов её хватит.


    Материнская плата Lex CV860. Общий вид

    И действительно, если взглянуть на роутер в разобранном виде, то обнаружить каких-либо движущихся частей не удастся. Процессор и чипсет прекрасно обходятся пассивным охлаждением, чего вполне достаточно и к тому же снижает конечную стоимость девайса.

    Чипсет VIA PLE133 был представлен несколько лет назад, и может работать с процессорами Intel Pentium III, Intel Celeron (под Socket 370) и VIA C3. Что касается типа поддерживаемой памяти, то это SDRAM (вплоть до PC133), что в свете скорого перехода на DDR3 выглядит совсем уж архаично. И дело здесь не в низкой скорости (современные двухканальные контроллеры способны обеспечить в 12 раз большую пропускную способность), сколько в том, что найти в продаже SDRAM-планки памяти будет достаточно сложно. Причем она почти гарантированно будет из разряда б/у. Пожалуй, это единственный серьезный минус этого чипсета по отношению его использования в роутерах.

    Знать остальные возможности PLE133 для нас необязательно, но для интересующихся вкратце перечислим их. Чипсет содержит встроенное графическое ядро класса UniChrome. Имеетс поддержка звуковых кодеков AC‘97, до четырех портов USB 1.1 (через южный мост VIA VT82C686B), двух каналов UDMA100, а также 10/100 Мбит сетевой карты (при установке специального чипа-компаньона на плате).


    Дизайн платы спроектирован полностью в соответствии возлагаемыми на роутер задачами.



    Сетевые контроллеры Realtek RTL8100B

    Сразу в глаза бросается три сетевых контроллера Realtek RTL8100B. При необходимости все их можно задействовать.


    Разъемы IDE, DOC и CF

    Еще из неординарных для обычного компьютера решений можно отметить возможность подключения ноутбучного жесткого диска без переходника. Специально для него распаян 44-контактный разъем IDE. Рядом с ним соседствует стандартный 40-контактный IDE, разъем DOC (Disk-On-Chip) и специальный слот для карт памяти CompactFlash. Присутствие последнего особенно радует, так как в системе он обозначен как еще один IDE-канал. Поэтому, устанавливая туда флэш-карту, она будет распознана как еще один жесткий диск. Следовательно, ничего не помешает установить на нее операционную систему. Таким образом в роутере вообще не будет никаких движущихся механизмов, что снижает не только шум, но и повышает надежность.

    К сожалению, неизвестно, карта какого максимального объема поддерживается платой. Сегодня их емкость достигла 8 и более Гбайт, чего вполне хватит для установки роутерных операционных систем.


    Разъем памяти SDRAM

    На краю платы расположен единственный разъем для модуля памяти SDRAM.


    Разъемы на задней панели платы

    На заднюю панель плату выведены следующие разъемы:
    12-вольтовый разъем питания;
    два PS/2 для клавиатуры и мыши;
    два USB 1.1;
    три разъема RJ-45 (Ethernet);
    два разъема COM;
    один разъем LPT.

    Как можно заметить, производитель задействовал все сетевые контроллеры, распаянные на плате.


    Разъемы на передней панели платы

    Спереди также выведено несколько разъемов, а также других элементов:
    один USB 1.1;
    аудио выход и аудио вход;
    три индикатора, свидетельствующие о выполнении той или иной операции (роутер включен, идет передача данных, идет работа жесткого диска);
    кнопка включения/выключения.


    Роутер. Общий вид

    Все это упаковано в темно-синий корпус с вентиляционными отверстиями.


    Роутер в полной сборке

    При желании можно "одеть" роутер в специальные панели.


    Комплект поставки

    Осталось сказать несколько слов о комплекте поставки рассматриваемого устройства. Помимо его в коробке было обнаружено следующее:
    блок питания FSP;
    крепление для ноутбучного жесткого диска к внутренней части крышки корпуса;
    44-жильный шлейф для подключения ноутбучного жесткого диска;
    термоинтерфейс для жесткого диска;
    термопаста;
    набор винтов для закрытия корпуса роутера;
    диск с программным обеспечением;
    руководство пользователя.

    Корпус роутера спроектирован таким образом, что внутри него поместится только 2.5-дюймовый жесткий диск. Не удивительно, что в комплектации для него присутствует столько компонентов. Если вы захотите подключить что-нибудь "покрупнее", то, вероятно, придется выносить это за пределы корпуса.

    Производительность

    Наверное, для многих будет интересен вопрос производительности операционной системы Mikrotik на вышеназванной платформе и его реальные требования к конфигурации компьютера.

    Стоит отметить, что заявленные минимальные требования полностью соответствуют реальным. На 32 мегабайтах оперативной памяти и процессоре Pentium 133 система обслуживала одновременно около 20 подключенных по протоколу PPTP клиентов, динамически ограничивая скорость и фильтруя нежелательный трафик. Обща скорость канала составляла примерно 512/512 Кбит/с. При всём этом загрузка процессора редко когда доходила до 40% и в среднем равнялась 15-25%. В условиях, когда скорости измеряются мегабитами, системные требования заметно возрастают.

    Хотелось бы обратить ваше внимание на то, что популярный нынче протокол VPN (PPTP) достаточно ресурсоёмок и во всех возможных случаях вместо него рекомендуется использовать альтернативный и лёгкий PPPOE, клиентская поддержка которого реализована уже в Windows XP. Для более ранних операционных систем его придется устновить отдельно. Так же в целях повышения производительности Mikrotik стоит очень аккуратно отнестись к настройке Firewall и шейпера, по возможности отключить встроенную генерацию графиков загрузки канала и ресурсов системы.

    Тесты производительности

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

    Способ тестирования Размер пакета в байтах (TX/RX) Средний результат Рисунок
    Поднимаем VPN тоннель и запускаем Btest на TCP both. TX/RX 80/640 27/29 мегабит 1
    Поднимаем VPN тоннель и запускаем Btest на TCP both. TX/RX 640/80 8/36.5 мегабит 2
    Поднимаем VPN тоннель и запускаем Btest на TCP both. TX/RX 1024/1024 19/32 мегабит 3
    Поднимаем VPN тоннель и запускаем Btest на TCP both. Ставим скорость 128/64 и считаем общий канал. TX/RX 80/640 60-80 подключений до 5120/10240  
    Поднимаем VPN тоннель и запускаем Btest на UDP both. TX/RX 80/640 1/6.9 мегабит 4
    Поднимаем VPN тоннель и запускаем Btest на UDP both. 640/80 141 кбит/51.1 мегабит (аномалии) 5
    Поднимаем VPN тоннель и запускаем Btest на UDP both Ставим скорость 128/64 и считаем общий канал. TX/RX 80/640 4.3/5.6 мегабит 60 подключений  
    Поднимаем PPPOE тоннель и запускаем Btest на TCP both. TX/RX 80/640 47.4/17.5 мегабит 6
    Поднимаем PPPOE тоннель и запускаем Btest на TCP both. TX/RX 640/80 20/29 мегабит  
    Поднимаем PPPOE тоннель и запускаем Btest на TCP both. TX/RX 1024/1024 40/25 мегабит  
    Поднимаем PPPOE тоннель и запускаем Btest на TCP both. Ставим скорость 128/64 и считаем общий канал. TX/RX 80/640 110 подключений 7040 кбит/14080 кбит  
    Поднимаем PPPOE тоннель и запускаем Btest на UDP both. TX/RX 80/640 13/11 мегабит  
    Поднимаем PPPOE тоннель и запускаем Btest на UDP both TX/RX 640/80 381/74.6 мегабит  
    Поднимаем PPPOE тоннель и запускаем Btest на UDP both. TX/RX 1024/1024 38.2/74.1 мегабит  

    Ниже вы можете увидеть как проходило тестирование на примере нескольких скриншотов.


    Тест 1


    Тест 2


    Тест 3


    Тест 4


    Тест 5


    Тест 6


    Перекачка больших файлов с FTP сервера


    Закачка файлов на сервер

    Нельзя учитывать эту информацию как абсолютно точную, так как проводилось синтетическое тестирование и оно кое-где привело к противоречивости информации. На последних двух графиках была показана загрузка системы при перекачке через маршрутизатор больших файлов на файл-сервер, подключенный по PPPOE к этому же серверу доступа. Как видим, загрузка процессора при этом составила около 90%, а реальная пропускная способность сетевых интерфейсов 65-79 Мбит/с, что, согласитесь, не мало. В расчете мощности оборудования, взяв за основу наше тестирование, необходимо учесть, что мы проводили тесты на одном физическом PPTP/PPPOE подключении. В реальных "боевых" условиях при 80-90 виртуальных подключениях значительно больше ресурсов процессора уйдёт на обсчёт служебной информации и пропускная способность окажетс меньше указанной.

    Рваные кривые на графиках обусловлены высокой загрузкой процессора клиентской программой. На практике такой маршрутизатор способен обслужить около ста одновременных пользователей, разделяя между ними полосу в 5-10 Мбит/с. Для большей устойчивости системы, мы порекомендовали бы использовать два сервера доступа и один резервный для горячей замены в случае проблем.

    Займёмся NAS-ами

    Предположим, что у нас уже есть 1-2 платформы или обычных компьютера с установленной RouterOS Mikrotik версии после 2.9.14. Такое условие обусловлено наличием ошибок в реализации протокола Radius в ранних версиях этой операционной системы. В идеальном случае, конечно, лучше всего использовать последнюю доступную лицензионную версию Mikrotik, однако если жажда приключений вас не покидает, постарайтесь всё-таки использовать любую условно-бесплатную стабильную версию.

    Настройка серверов доступа будет заключаться в выполнении трёх действий: настройке его авторизации на биллинге, настройке экспорта информации о сетевой статистике посредством NetFlow и настройке доступа модуля биллинга для управления Firewall на Mikrotik. Если первые два шага вполне понятны, то третий нужно объяснить.

    Биллинг UTM не предусматривает каких-либо встроенных средств для работы с удалённым Firewall серверов доступа, отличных от Cisco. Вместо этого в нём реализован механизм, позволяющий нам самим управлять поведением системы в зависимости от поступлени определённых команд или наступления определённых условий. К примеру, при создании нового аккаунта клиента Firewall системы создаст на сервере доступа правило, разрешающее этому клиенту выход в Интернет. При необходимости блокировки доступа наш скрипт пошлёт нужные команды на Mikrotik, запрещающие клиенту работать.

    Сначала настроим взаимодействие Mikrotik с Radius-сервером.

    /radius add address=10.20.3.250 secret=radsecret

    И отключим возможность управлять состоянием Radius-сервера, так как все манипуляции по отключению пользователей мы будем производить средствами Firewall.

    /radius incoming set accept=no


    Настройка RADIUS на Mikrotik

    Теперь перейдём к настройке протокола NetFlow, который в Mikrotik назван TrafficFlow.

    /ip traffic-flow target add address=10.20.3.250 version=5
    /ip traffic-flow set enabled=yes cache-entries=4k active-flow-timeout=00:01:00 inactive-flow-timeout=00:00:05 interfaces=all


    Настройка NetFlow на Mikrotik

    В первом правиле мы указали на какой адрес нужно отсылать всю статистику и в каком формате. Во втором правиле разрешили собирать статистику на всех интерфейсах с группировкой экспортируемых данных по 4 Кбайта. Сбор статистики по NetFlow работает следующим образом. Перед отправкой данных ядру биллинга система пытаетс сгруппировать статистику и делает это по следующему алгоритму: когда пользовать устанавливает постоянное подключение к удаленному серверу и начинает перекачивать данные, то наш сервер по прошествии active-flow-timeout циклически сбрасывает накопленную статистику на биллинг, и в случае, если через открытое активное подключение в течение времени inactive-flow-timeout не поступает новых данных, информация о нём посылается биллингу.

    Сейчас приступим к настройке взаимодействи биллинга и Firewall нашего Mikrotik. Схема его работы достаточно проста - управление разрешением пользователей будет производиться с помощью редактирования src-list адресов клиентов в Firewall. Доступ к нашему NAS для этих операций будет осуществляться средствами ssh. Для простоты взаимодействия мы добавим пользователя без пароля, которому разрешен вход только с одного определенного IP-адреса.

    /user group add name=ssh policy ssh,write
    /user add name=USERNAME group=ssh address=UTM_IP_ADDRESS /p>

    Вместо USERNAME необходимо вписать любое имя пользователя, а вместо UTM_IP_ADDRESS IP адрес нашего сервера с UTM.

    И разрешим forward только списку разрешенных адресов. Когда вы увидите, как это всё вместе работает, возможно, у вас возникнут другие предложения по реализации отключением пользователей и вы их сможете достаточно легко реализовать.

    /ip firewall filter add chain=forward action=accept dst-address-list=allow_ip
    /ip firewall filter add chain=forward action=accept src-address-list=allow_ip
    /ip firewall filter add chain=forward action=drop

    С настройкой сервера доступа на этом покончено. При использовании графической утилиты Winbox у вас уйдёт на это буквально несколько минут.

    Установка UTM5

    К сожалению, разработчики UTM по какой-то причине не работают с распространёнными дистрибутивами, отличными от RedHat/SuSe, поэтому для установки пакета rpm в системе debian нам потребуется установить утилиту alien или рассовать файлы по системе вручную, чего мы делать не будем.

    utm:/etc/init.d# apt-get install alien

    Еще нам нужен сервер баз данных и инструменты для работы самого биллинга

    apt-get install ssh mysql-server-5.0 proftpd mc apache2 libssl0.9.7 libstdc++5

    Сейчас скопируем пакет utm на машину с debian. Дл этого воспользуемся любым FTP-клиентом. Не забудьте скопировать файл с регистрационной информацией, если он у вас есть.

    Воспользуемся утилитой alien, чтобы установить utm-5.2.1-001.i386.rpm

    utm:/etc/init.d# alien utm-5.2.1-001.i386.rpm

    В результате чего мы получим пакет utm-5.2.1-001.i386.deb, установить который можно одной командой

    utm:/etc/init.d# dpkg -i utm-5.2.1-001.i386.deb

    Сейчас создадим базу данных.

    utm:/etc/init.d# mysqladmin create UTM5;

    И создадим в нём нужные таблицы

    utm:/etc/init.d# mysql -u root UTM5

    Если вы планируете использовать базу данных PostgreSQL, то вам потребуется файл UTM5_PG.sql, который можно найти в директории с программой. Также нужно изменить путь к сокету mysql в файле /netup/utm/utm5.cfg:

    database_sock_path=/var/run/mysqld/mysqld.sock

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

    Немного отредактируем стартовые скрипты utm5_core, utm5_radius и utm5_rfw., но сначала скопируем из каталога /etc/rc.d/init.d/ файлы utm5_core, utm5_radius и utm5_rfw в каталог /etc/init.d/. Меняем содержимое строки в файле utm5_core c

    utm_exec=safe_utm5_core

    на

    utm_exec=utm5_core

    в utm5_radius c

    utm_exec=safe_utm5_radius

    на

    utm_exec=utm5_radius

    и в utm5_rfw c

    utm_exec=safe_utm5_rfw

    на

    utm_exec=utm5_rfw

    Сейчас настроим автозапуск скриптов при старте системы

    utm:/etc/init.d# update-rc.d utm5_core defaults
    utm:/etc/init.d# update-rc.d utm5_radius defaults
    utm:/etc/init.d# update-rc.d utm5_rfw defaults

    При запуске каждой из команд вы увидите нечто вроде этого

    Adding system startup for /etc/init.d/utm5_core ...
       /etc/rc0.d/K20utm5_core -> ../init.d/utm5_core
       /etc/rc1.d/K20utm5_core -> ../init.d/utm5_core
       /etc/rc6.d/K20utm5_core -> ../init.d/utm5_core
       /etc/rc2.d/S20utm5_core -> ../init.d/utm5_core
       /etc/rc3.d/S20utm5_core -> ../init.d/utm5_core
       /etc/rc4.d/S20utm5_core -> ../init.d/utm5_core
       /etc/rc5.d/S20utm5_core -> ../init.d/utm5_core

    Нужно не забыть создать несколько файлов и папок, так как при конвертации пакета .rpm в .deb все установочные скрипты потерялись и нам придётся возложить на себя их работу

    utm:/etc/init.d# mkdir /netup/utm5/log/
    utm:/etc/init.d# touch /netup/utm5/log/utm5_radius.log
    utm:/etc/init.d# mkdir /netup/utm5/db/

    Всё остальное система создаст сама. Нам осталось только зарегистрировать UTM5, а делается это следующим образом: разработчики не стали себя утруждать какими-либо удобными механизмами и вместе с самим биллингом поставляют файл с SQL-запросом, который нужно импортировать в нашу базу данных.

    utm:/etc/init.d# mysql -u root UTM5

    Если всё прошло без заминки, то можно запускать биллинг и приступать к его настройке.

    utm:/etc/init.d#/etc/init.d/utm5_core
    utm:/etc/init.d#/etc/init.d/utm5_radius
    utm:/etc/init.d#/etc/init.d/utm5_rfw
    utm:/etc/init.d# ps aux
    grep utm5
    root      4613  0.2  4.8  85368  9268 pts/2    Sl   14:49   0:00 /netup/utm5/bin/utm5_core start
    root      4629  0.5  1.0  32340  2100 pts/2    Sl   14:52   0:00 /netup/utm5/bin/utm5_radius start
    root      4638  0.5  1.0  12392  2016 pts/2    Sl   14:52   0:00 /netup/utm5/bin/utm5_rfw start




















    Напишите нам, мы онлайн
    up