Browse Source

Somthing make docs about extra functional, user page and dhcp

devel
Dmitry 8 years ago
parent
commit
1b12952809
  1. 5
      README.md
  2. 28
      docs/dhcp.md
  3. 20
      docs/extra_func.md
  4. 2
      docs/map.md
  5. 3
      docs/netflow.md
  6. 14
      docs/user_page.md
  7. 6
      docs/views.md

5
README.md

@ -11,7 +11,10 @@ P.S. Возможно понадобится **Python 3.5** и выше из-з
## Содержание
* [Установка](./docs/install.md)
* [Сервисы и API](./docs/services.md)
* [Разработка расширений](./docs/dev.md)
* [Менеджеры устройств](./docs/dev.md)
* [Сбор информации трафика по netflow](./docs/netflow.md)
* [Работа с представлениями](./docs/views.md)
* [Карта](./docs/map.md)
* [DHCP](./docs/dhcp.md)
* [Страница абонента](./docs/user_page.md)
* [Дополнительный функционал](./docs/extra_func.md)

28
docs/dhcp.md

@ -0,0 +1,28 @@
## ISC-DHCP Сервер, взаимодействие с биллингом.
Вобщих чертах взаимодействие происходит с помощью скрипта **dhcp_lever.py**
в корне проекта. Запущенный DHCP сервер, при возникновении событий запускает
этот сценарий , а тот говорит биллингу подробнее что произошло.
При событии *expiry* или *release* биллингу нужно освободить ip, а при *commit*
нужно назначить динамическую аренду ip для учётной записи абонента в биллинге.
Сам скрипт не выполняет все эти действия, он просто отправляет полученные от dhcp
сервера параметры на url адрес для обработки dhcp. View распологается в **abonapp.views.DhcpLever**.
### Выделение аренды ip
Как происходит выделение аренды ip, от события в dhcp сервере и до появления интернета у
абонента.
Когда в dhcp сервере происходит событие *commit* то из **abonapp.views.DhcpLever** вызывается
функция **agent.commands.dhcp.dhcp_commit**, с помощью DHCP OPTION.82 получаем mac адрес управляемого
свича и порт через который пришёл запрос. Каждое такое устройство должно быть зарегистрировано в биллинге.
Далее ищем в базе абонента, или абонентов к которому привязано устройство с переданным mac адресом.
Проверяем может-ли данный тип устройства содержать несколько подключённых абонентов(напрмер PON ONU, в основном,
содержит одного абонента). Проверка происходит по свойству **is_use_device_port** из менеджера устройства,
которое открыто для кастомизации, подробнее в [Менеджер устройства](./docs/dev.md).
А далее, если может быть несколько абонентов, то фильтруем вывод ещё по порту свича.
Получется что на управляемом свиче мы авторизуем абонентов при помощи dhcp option.82 по маку свича и порту абонента.
Если наше устройство PON ONU(ONT) то авторизуем только по mac адресу оптического юнита(onu).
После добавления абоненту аренды динамического ip, он(абонент) синхронизуется с nas сервером и открывается доступ
к интернету в соответствии с тарифом абонента.

20
docs/extra_func.md

@ -0,0 +1,20 @@
## Дополнительный фунционал
В процессе реализации проекта понадобился функционал, который отсутствует в базовой поставке **Django**.
Его совсем не много, но без внимания оставить нельзя.
Все вспомогательные модули можно найти в пакете **djing.lib**.
### tln
Это модуль работы по *telnet*
### messaging
Этот модуль помогает работать с форматами СМС сообщений.
### init
Содержит всякие мелкие примочки, код прост и с комментариями, зайдите посмотрите.
## auth_decorators
Бэкенд авторизации
## decorators
Дополнительные декораторы.

2
docs/map.md

@ -24,4 +24,4 @@
### Другое
Статусы устройств на точках с одним устройством обновляются автоматически 2 раза в минуту.
Это означает что когда вы изучаете карту и какое-либо устройство пропало из сети то вы
увидите это сразу без перезагрузки карты.
увидите это в течение 2х минут без перезагрузки карты.

3
docs/netflow.md

@ -27,5 +27,6 @@ rm -rf djing_flow_git
вы найдёте этот самый файл дампа трафика. И тут уже можно посмотреть как работает утилита **djing_flow**:
> \$ ./djing_flow < /tmp/djing_flow_dump.tmp
На выходе вы получите запрос для mysql. Можно перенаправить его по конвееру в mysql, реализацию вы можете увидеть в файле
На выходе вы получите запрос для mysql. Можно перенаправить его по конвееру в mysql, рабочий пример
перенаправления этогй утилиты вы можете увидеть в файле
*agent/netflow/netflow_handler.sh*.

14
docs/user_page.md

@ -0,0 +1,14 @@
## Особенности страницы абонента.
Находится она в разделе **Абоненты** внутри группы. На этой странице вы увидите несколько логических блоков,
из которых самые важные, пожалуй, 2. Первый это **Изменение абонента** а второй **Выберите устройство**.
На первом блоке можно редактировать базовую информацию абонента. Если снять галку *Активен* то абонент перестанет
получать услуги даже при подключённой услуге.
Блок с устройством содержит то самое устройство, к которому подключён абонент. Если это устройство не будет назначено
то биллинг не сможет авторизовать абонента по dhcp option.82. Галочка **Динамические настройки по dhcp** означает что
учётная запись абонента сможет получать динамический ip. Это означает что если галка не будет выставлена, то сколько бы
запросов не приходило с этого устройства абонент не изменить свой ip, это полезно когда абонент работает со статическим
ip.
Вверху есть вкладки. с соответствующим названию функционалом. Например на вкладке **Тарифы** вы можете назначить
абоненту услугу или добавить периодический платёж, который абонент увидит в своём личном кабинете.

6
docs/views.md

@ -22,8 +22,8 @@ class PaysListView(ListView):
```
Тогда в шаблоне с bootstrap вы можете увидеть примерно такую пагинацию которую
вы конечно же можете изменить на свою.
Тогда в шаблоне с bootstrap вы можете подключить шаблон пагинации *templates/pagination.html* и
увидеть примерно такую пагинацию которую вы конечно же можете изменить на свою.
![paginator](./img/pagination.png).
@ -53,4 +53,4 @@ class PaysListView(ListView, OrderingMixin):
pass
```
Примесь *OrderingMixin* добавляет в контекст переменные *order_by* и *dir* для использования в шалоне.
Примесь *OrderingMixin* добавляет в контекст переменные *order_by* и *dir* для использования в шаблоне.
Loading…
Cancel
Save