Reset всех абонентов на NAS

[dimmons 0]

Доброго времени суток!

 

Настроил связку Mukrotik + Ubiling + PPPoE, все работает, но возник вопрос: сгорел у меня микротик, конфиг его типовой, залить на новый дело пары минут, а как пролить на нем очереди всех абонов заново (кроме как на каждом давить ресет)?? Есть ли какойто штатный механизми запуска скриптов Connect/Disconnect по группе абонентов?

[nightfly 1 221]

Ага - называется модулем "Массовый ресет".

Хотя более логично было бы не мудрствуя долго, тупо рестартнуть stargazer, чтобы он по человечески поднял каких надо юзеров на новом НАС-е.

[dimmons 0]

Спасибо, включил! 

 

ИМХО в вэбморде кнопочку удобней жать чем в консоль лезть)

[jcomm 6]

 

 

в вэбморде кнопочку удобней жать чем в консоль лезть

Ага, только по времени происходить это будет раза в 3 дольше...

[nightfly 1 221]

Ну да + никаких гарантий.

Возможно хорошим выбором может стать еще RESET_AO=1 но всеравно, никаких гарантий и это еще дольше.

[jcomm 6]

 

 

Возможно хорошим выбором может стать еще RESET_AO=1

Да, он бы был хорош, если бы не было этого:   

//very shitty hack
sleep(2);

[nightfly 1 221]

//very shitty hack

Ну я хотя бы честен с собой

[dimmons 0]

Выполз еще один момент, при удалении пользователя он не удаляется с NAS, скрипт onDisconnect запускается, но вылетает с ошибкой. Ниже лог процесса, сначала я добавляю 2 юзеров, они появляются на NAS, потом одного из них удаляю:

 

2013-07-23 10:45:25 - [ubilling] -  OnConnect started for user `qaz`:

2013-07-23 10:45:25 - [Database] - DEBUG INFO: MySQL Class loaded...

2013-07-23 10:45:25 - [Database] - DEBUG INFO: Connection with database is established...

2013-07-23 10:45:25 - [Database] - DEBUG INFO: USER NETWORK ID - `2`;

2013-07-23 10:45:25 - [Database] - DEBUG INFO: USER PASSWORD - `qaz`;

2013-07-23 10:45:25 - [Database] - DEBUG INFO: USER REASSIGNED RATE - `NULL`!

2013-07-23 10:45:25 - [Database] - DEBUG INFO: USER TARIFF - `Tester`;

2013-07-23 10:45:25 - [Database] - DEBUG INFO: USER TARIFF TX RATE - `1024`;

2013-07-23 10:45:25 - [Database] - DEBUG INFO: USER TARIFF RX RATE - `1024`;

2013-07-23 10:45:25 - [Database] - DEBUG INFO: USER MAC - `14:88:56:52:44:37`;

2013-07-23 10:45:25 - [Database] - DEBUG INFO: NAS IP - `172.16.0.2`;

2013-07-23 10:45:25 - [Database] - DEBUG INFO: NAS TYPE - `mikrotik`;

2013-07-23 10:45:25 - [Executer] - DEBUG INFO: MikroTik Executer loaded...

2013-07-23 10:45:25 - [Executer] - DEBUG INFO: Connection with MikroTik via API is established...

2013-07-23 10:45:26 - [Executer] - SUCCESS: Address List entry with ID - `*16` was updated;

2013-07-23 10:45:26 - [Executer] - SUCCESS: Queue entry with ID - `*E` was updated;

2013-07-23 10:45:26 - [Executer] - DEBUG INFO: ARP entry creation is turned off;

2013-07-23 10:45:26 - [Executer] - DEBUG INFO: DHCP entry creation is turned off;

2013-07-23 10:45:26 - [Executer] - DEBUG INFO: PPP entry creation is turned off;

2013-07-23 10:45:26 - [ubilling] -  Elapsed time: 0.786 sec.

 

2013-07-23 10:45:26 - [ubilling] -  OnConnect started for user `qaz`:

2013-07-23 10:45:26 - [Database] - DEBUG INFO: MySQL Class loaded...

2013-07-23 10:45:26 - [Database] - DEBUG INFO: Connection with database is established...

2013-07-23 10:45:26 - [Database] - DEBUG INFO: USER NETWORK ID - `2`;

2013-07-23 10:45:26 - [Database] - DEBUG INFO: USER PASSWORD - `qaz`;

2013-07-23 10:45:26 - [Database] - DEBUG INFO: USER REASSIGNED RATE - `NULL`!

2013-07-23 10:45:26 - [Database] - DEBUG INFO: USER TARIFF - `Tester`;

2013-07-23 10:45:26 - [Database] - DEBUG INFO: USER TARIFF TX RATE - `1024`;

2013-07-23 10:45:26 - [Database] - DEBUG INFO: USER TARIFF RX RATE - `1024`;

2013-07-23 10:45:26 - [Database] - DEBUG INFO: USER MAC - `14:88:56:52:44:37`;

2013-07-23 10:45:26 - [Database] - DEBUG INFO: NAS IP - `172.16.0.2`;

2013-07-23 10:45:26 - [Database] - DEBUG INFO: NAS TYPE - `mikrotik`;

2013-07-23 10:45:26 - [Executer] - DEBUG INFO: MikroTik Executer loaded...

2013-07-23 10:45:26 - [Executer] - DEBUG INFO: Connection with MikroTik via API is established...

2013-07-23 10:45:27 - [Executer] - SUCCESS: Address List entry with ID - `*16` was updated;

2013-07-23 10:45:27 - [Executer] - SUCCESS: Queue entry with ID - `*E` was updated;

2013-07-23 10:45:27 - [Executer] - DEBUG INFO: ARP entry creation is turned off;

2013-07-23 10:45:27 - [Executer] - DEBUG INFO: DHCP entry creation is turned off;

2013-07-23 10:45:27 - [Executer] - DEBUG INFO: PPP entry creation is turned off;

2013-07-23 10:45:27 - [ubilling] -  Elapsed time: 0.791 sec.

 

2013-07-23 10:46:10 - [ubilling] -  OnDisconnect started for user `qaz`:

2013-07-23 10:46:10 - [Database] - DEBUG INFO: MySQL Class loaded...

2013-07-23 10:46:10 - [Database] - DEBUG INFO: Connection with database is established...

2013-07-23 10:46:10 - [Database] - ERROR: USER NETWORK ID - `NULL`!

2013-07-23 10:46:10 - [Database] - ERROR: USER NETWORK ID - `NULL`!

2013-07-23 10:46:10 - [Database] - ERROR: NAS IP - `NULL`!

2013-07-23 10:46:10 - [Database] - ERROR: NAS TYPE - `NULL`!

2013-07-23 10:46:10 - [ubilling] - ERROR: Cannot load NAS Command Executer, queried empty NAS TYPE from database!

2013-07-23 10:46:10 - [ubilling] -  Elapsed time: 0.005 sec.

 

После удаления пользователь некоторое время висит пустой (без адреса и мака, но с IP), но нетвор id скрипт не получает.

[jcomm 6]

 

2013-07-23 10:46:10 - [Database] - ERROR: USER NETWORK ID - `NULL`!

2013-07-23 10:46:10 - [Database] - ERROR: USER NETWORK ID - `NULL`!

2013-07-23 10:46:10 - [Database] - ERROR: NAS IP - `NULL`!

2013-07-23 10:46:10 - [Database] - ERROR: NAS TYPE - `NULL`!

Т.к. информация о пользователе удаляется и БД скрипт не может ее извлечь.. Единственное, что можно сделать - это задействовать скрипт "OnUserDel", но, насколько я знаю, Ubilling вызывает только "OnConnect" и "OnDisconnect"..

Відредаговано 2013-07-23 08:16:23 jcomm

[jcomm 6]

 

 

Ubilling вызывает только "OnConnect" и "OnDisconnect"

Я ошибся.. Решение придумаю, ждите релиз..

[nightfly 1 221]

Нефиг удалять пользователей - они нивчем не виноваты

[dimmons 0]

Судя по тому что я вижу, скрипт OnConnect при отсутствии пользователя и очереди их добавляет (вероятно он при отсутствии пользователя сам запускает OnUserAdd), а скрипт onDisconnect просто отключает запись в Address Lists. Запуск OnDisconnect в таком случае при удалении бесполезен, записи останутся висеть. 

 

Можно ли както активировать запуск скрипта OnUserDel при удалении. А то ведь что получается, если пользователи остаются висеть в Address Lists c логином и IP удаленного пользователя  (и в очереди с именем соответствующим логину удаленного пользователя) то при создании нового пользователся с таким же IP и другим логином начинается образование бардака на NAS в виде дубликатов записей и очередей.

 

P.S. Пардон.. пока писал уже пришел ответ..

Відредаговано 2013-07-23 08:39:15 dimmons

[dimmons 0]

Нефиг удалять пользователей - они нивчем не виноваты

 

Да както нехочется неразбериху разводить, к томуже если на микротике будет висеть множество неиспользуемых очередей, врядли это улучшит его самочувствие (Судя по описанию на сайте сопоставление пакета на совпадение с правилами в очереди идет последовательно, перебором, мертвяки должны таки уменьшать производительность)...

[nightfly 1 221]

Ну как вариант - потыкайте в jcomm пачкой денег, может сделает опциональное "удалять правила" вместо текущего "просто ставить их неактивными".

[dimmons 0]

Я начинаю понимать jcomm )). Stargazer передает при запуске UserAdd и UserDel довольно бесполезные для создания и удаления юзера параметры: логин, тариф и т.п., ни IP адреса, ни скорости.. Так что для управления микротиком эти два скрипта бесполезны. Надо переделывать скрипты OnConnect/OnDisconnect на удаление/добавление адреса и очереди... Попробую расковырять сам, если не получится побегу за пачкой ))).

[madf 279]

Я начинаю понимать jcomm )). Stargazer передает при запуске UserAdd и UserDel довольно бесполезные для создания и удаления юзера параметры: логин, тариф и т.п., ни IP адреса, ни скорости.. Так что для управления микротиком эти два скрипта бесполезны. Надо переделывать скрипты OnConnect/OnDisconnect на удаление/добавление адреса и очереди... Попробую расковырять сам, если не получится побегу за пачкой ))).

Если мне не отшибло память, в UserAdd/Del передается только логин. И это архи-полезная штука, т.к. по ней можно откопать все что надо из базы.

[jcomm 6]

 

 

Если мне не отшибло память, в UserAdd/Del передается только логин. И это архи-полезная штука, т.к. по ней можно откопать все что надо из базы.

Согласен с архи-полезностью, ведь всего лишь логина хватит, чтобы удалить все следы пребывания пользователя на NAS`е...

[dimmons 0]

Имею некоторый предрассудок в использовании логинов как якорей для идентификации пользователей в конфигах железок, но это дело хозяйское, кому как удобней (на некоторых насах с логинами вообще проблема, на каком нибудь ериксоне например)

 

Обвязку скриптов я переписал по своему, она теперь юзеров и очереди удаляет по запуску OnConnect/OnDisconnect (OnUserAdd/OnUserDel я не трогал). Все работает замечательно, за исключением 1 нюанса. При удалении юзера из биллинга, он исправно запускает скрипты, но в данных уже нет. При этом в интерфейсе биллинга, в пользователях онлайн, удаленный юзер есть (из этого делаю вывод что гдето в базе есть и данные о юзере). Использую запрос вида:

 

select nh.netid, n.nasip, n.nastype, rsp.speed, u.tariff, sp.speedup, sp.speeddown, u.ip from nethosts as nh 

join nas as n on n.netid = nh.netid 

join users as u on u.login = 'ttt'

join userspeeds as rsp on rsp.login = u.login

join speeds as sp on sp.tariff = u.tariff

where nh.ip = u.ip

 

В принципе вывернуться из ситуации можно просто:

 

• Для удаления юзера можно вообще в базу не обращаться, скорости мне чтобы удалить данные с наса не нужны. Достаточно того что получает скрипт (собственно обращение к базе в OnDisconnect остались из-за того, что он был быстро вылеплен из OnConnect и отличается только коммандами в API)
• Сказать манагеру чтобы перед удалением юзера он его приостанавливал (пока так и делают ))))

 

Но все таки мне просто интересно, откуда берутся в юзерах онлайн данные о пользователе после его удаления?? Есть знатоки которые могут прояснить как это все происходит?

[nightfly 1 221]

 

Но все таки мне просто интересно, откуда берутся в юзерах онлайн данные о пользователе после его удаления?? Есть знатоки которые могут прояснить как это все происходит?

Как-то так это все происходит. Неочищенной остается только `users` и то не долго. Рано или поздно Stargazer обязательно прикончит логин.

На будущее внес в FAQ.

[dimmons 0]

Ваша оперативность меня вдохновляет )), вы дадите фору многим платным биллингам.

 

У меня еще появилась мысль о массовом ресете. Каков механизм работы после нажатия кнопки? Хочу по нажатию этой кнопки запускать синхронизацию по насам (чтобы всех юзеров не удалять-добавлять, а выявлять только то что надо поправить). 

 

Я предполагаю что сейчас дается какаято команда старгейзеру и тот пологинно делает дисконнект-коннект.

[nightfly 1 221]

Я предполагаю что сейчас дается какаято команда старгейзеру и тот пологинно делает дисконнект-коннект.

Да - пользователю последовательно либо тупо выставляется Down 1/0 либо AlwaysOnline 0/1 в случае RESET_AO=1 в billing.ini.

 

Ваша оперативность меня вдохновляет )), вы дадите фору многим платным биллингам.

[dimmons 0]

Тогда проще сделать синхронизацию кроном раз в час.

[nightfly 1 221]

...Либо просто дорисовать хреновину на ssh с публичными ключами удаляющую очереди/arp-записи по логину убиваемого пользователя, или чего вам там нужно на микротике и действительно просто пихнуть ее в OnUserDel. Как образец для реализации этого всего в четыре строчки можете взять скажем уже не поддерживаемый, но в принципе рабочий на таких редких задачах direct.

[dimmons 0]

При наличии Mikrotik API смысла в ssh думаю нет, да и за эти дни библиотеку под API полностью допилил. А удаление все таки сделаю в OnDisconnect, ip адрес мне старгейзер дает, остается NAS по ip адресу в базе найти, что не есть проблема.

 

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

 

Я тут смотрел исходники динамического шейпера, и как я понял он работает только если NAS сделан локально на сервере биллинга. А есть какой то вариант реализующий его на удаленных NAS?

 

И еще вопрос про rscriptd, я с ним раньше не сталкивался никогда, у него какието преимущества перед ssh c ключами есть? Просто у меня уже есть ранее написанная обвязка под другой биллинг для управления ipfw работающая через ssh или локально, переделать под этот билинг, буквально запросы адаптировать и все. Может ли rscriptd что то чего не может ssh?

[jcomm 6]

Как-то так это все происходит. Неочищенной остается только `users` и то не долго. Рано или поздно Stargazer обязательно прикончит логин.

На будущее внес в FAQ.

Если последовательность не критична, то можно переместить удаление пользователя STG до удаления информации о принадлежности к сети, а сети к NAS`у, чтобы извлечь options и по человечески удалить на нужном MikroTik'е очередь, ARP-запись и запись в Address List.

 

Відредаговано 2013-07-25 20:28:32 jcomm