diff --git a/agent/netflow/start_netflow.sh b/agent/netflow/start_netflow.sh index c7c1f79..f876a41 100755 --- a/agent/netflow/start_netflow.sh +++ b/agent/netflow/start_netflow.sh @@ -2,5 +2,5 @@ PATH=/usr/local/sbin:/usr/local/bin:/usr/bin -flow-capture -R /srv/http/djing/agent/netflow/netflow_handler.sh -p /run/flow.pid -w /tmp/djing_flow -n1 -N0 0/0/6343 +flow-capture -R /var/www/djing/agent/netflow/netflow_handler.sh -p /run/flow.pid -w /tmp/djing_flow -n1 -N0 0/0/6343 diff --git a/devapp/models.py b/devapp/models.py index aaf0842..1de7537 100644 --- a/devapp/models.py +++ b/devapp/models.py @@ -6,7 +6,7 @@ from .base_intr import DevBase from mydefs import MyGenericIPAddressField, MyChoicesAdapter from . import dev_types from mapapp.models import Dot -from subprocess import call +from subprocess import run from django.conf import settings @@ -99,7 +99,7 @@ def dev_post_save_signal(sender, instance, **kwargs): elif grp == 79 or grp == 91: code = 'zrk' newmac = str(instance.mac_addr) - call(["%s/devapp/onu_register.sh" % settings.BASE_DIR, newmac, code]) + run(["%s/devapp/onu_register.sh" % settings.BASE_DIR, newmac, code]) models.signals.post_save.connect(dev_post_save_signal, sender=Device) diff --git a/docs/dev.md b/docs/dev.md index af79bb3..37ffba4 100644 --- a/docs/dev.md +++ b/docs/dev.md @@ -1,5 +1,5 @@ ->Перед началом обязательно, хотя бы поверхностно, ознакомиться с документацией к -[Django](https://docs.djangoproject.com). +> Перед началом обязательно, хотя бы поверхностно, ознакомиться с документацией к +> [Django](https://docs.djangoproject.com). ## Добавление поддерживаемого устройства (Свича) Для того чтоб добавить новый тип устройства с которым потом сможет работать биллинг нужно открыть файл *devapp/dev_types.py* @@ -90,7 +90,7 @@ class EltexSwitch(DLinkDevice): Метод **@get_device_name** получает по SNMP имя устройства, просто укажите в вашей реализации нужный OID. -Метод **@uptime**, понятно что возвращает, укажите нужный OID. Вернётся тип *RuTimedelta*, это не тип Django, я сам его реализовал +Метод **@uptime**, понятно что возвращает, укажите нужный OID. Вернётся тип *RuTimedelta*, это переопределённый тип **timedelta**, я его реализовал для локализации временного промежутка на русский. Статический метод **@has_attachable_to_subscriber** возвращает правду если это устройство можно привязать к абоненту. @@ -98,7 +98,8 @@ class EltexSwitch(DLinkDevice): абонентам при авторизации. Статический метод **@is_use_device_port** используется в DHCP чтоб понять что мы используем для привязки к абоненту всё устройство или -только порт устройства. Например, если у устройства только 1 порт абонента (PON ONU), то нужно вернуть True, во всех остальных случаях False. +только порт устройства. Например, если у устройства только 1 порт абонента (PON ONU), и мы привязываем этого абонента ко всему устройству +а не к порту, то нужно вернуть False, На обычных свичах где мы авторизуем абонента на порту возвращаем True. Реализация SNMPBaseWorker по сути не нужна, класс абстрактных методов не имеет. Потому когда наследуем наследуемся от *DevBase* то в базовые классы добавим и SNMPBaseWorker, как это сделано в *DLinkDevice*: @@ -267,8 +268,10 @@ NasNetworkError, как понятно из названия, вызываетс Биллинг прослушивает эти исключения при выполнении, и при возбуждении этих исключений отображает текст ошибки на экране пользователя. -При переопределении базового класса пожалуйста не забывайте вызвать базовый метод чтоб отработали декораторы методов интерфейса, этот декоратор проверяет тип входных данных. -Динамическая типизация python иногда подкладывает свинью в том смысле что можно передать не то что вы хотели бы передать, потому типы лучше проконтролировать, и тогда интерпретатор станет вашим другом помошником :) +При переопределении базового класса пожалуйста не забывайте вызвать базовый метод чтоб отработали декораторы методов +интерфейса, этот декоратор проверяет тип входных данных. +Динамическая типизация python иногда подкладывает свинью в том смысле что можно передать не то что вы хотели бы передать, +потому типы лучше проконтролировать, и тогда интерпретатор станет вашим другом помошником :) Когда я прошу вызвать базовый метод, я имею ввиду это: ```python @@ -279,8 +282,9 @@ def add_user_range(self, user_list): ... ``` -Кстати, не все методы обязательно реализовывать, некоторые из них зарезервированы на будущие цели, в комментариях к их прототипам в интерфейсе *BaseTransmitter* это сказано. -Поэтому просто переопределите эти зарезервированные методы как пустые, например метод *add_tariff_range* нигде в биллинге пока не вызывается. так что можно определить его пустым. +Кстати, не все методы обязательно реализовывать, некоторые из них зарезервированы на будущие цели, в комментариях к их +прототипам в интерфейсе *BaseTransmitter* это сказано. Поэтому просто переопределите эти зарезервированные методы как +пустые, например метод *add_tariff_range* нигде в биллинге пока не вызывается. так что можно определить его пустым. ```python def add_tariff_range(self, tariff_list): pass diff --git a/docs/intro.md b/docs/intro.md deleted file mode 100644 index 4611068..0000000 --- a/docs/intro.md +++ /dev/null @@ -1,7 +0,0 @@ -Текущие возможности: -1. Может наблюдать за устройствами по snmp -2. Отправлять изменения мгновенно на mikrotik -3. Привязывать на карте к точкам топологии устройства -4. Есть привязка монтажника к группам абонентов -5. Есть менеджер задач на абонентов. Это оператор может выбрать абонента и описать проблему. Система отправит оповещение через telegram ответственному за групу указанного абонента монтажнику с текстом проблемы, адресом и телефоном абонента. -6. Долгие или сложные задачи можно отправлять на очередь исполнения diff --git a/docs/netflow.md b/docs/netflow.md index 42d5bf5..e79bd1a 100644 --- a/docs/netflow.md +++ b/docs/netflow.md @@ -19,5 +19,13 @@ rm -rf djing_flow_git ``` Инструкцию по использованию можно найти на странице [djing_flow](https://github.com/nerosketch/djing_flow). -Посмотреть пример работы можно так: +Посмотреть пример работы можно с помощью файла дампа трафика flow-tools. Соберём такой дамп с помощью **flow-capture**. +> \# flow-capture -p /run/flow.pid -w /tmp/djing_flow -n1 -N0 0/0/6343 +Запустится сбор трафика. Чтоб узнать больше почитайте инструкции по использованию flow-tools. Настройте netflow sensor на +ваш сервер. Для того чтоб сбросить дамп трафика на диск отправте сигнал **-HUP** процессу flow-capture. В */tmp/djing_flow* +вы найдёте этот самый файл дампа трафика. И тут уже можно посмотреть как работает утилита **djing_flow**: +> \$ ./djing_flow < /tmp/djing_flow_dump.tmp + +На выходе вы получите запрос для mysql. Можно перенаправить его по конвееру в mysql, реализацию вы можете увидеть в файле +*agent/netflow/netflow_handler.sh*.