массовый резет Ubilling + mikrotik nas

[zaza12 2]

Ubilling + mikrotik nas . Заметил что резет , или массовый резет не затрагивает отключенных абонентов , те которые с минусом на счету. Может кто подскажет как заставить скрипты резетить (обновлять параметры в фаерволе , очередях , лизах) если они временно отключенные . Ну например случайно  или не случайно в адрес листе включился в allow ,  тот  кто должен быть в dany ? Или при замене микротика , отключенные абоненты (те кто в минусе ) не добавятся в микротик и  ip  просто не получат.

Edited 2016-06-16 08:34:37 by zaza12

[galactic 0]

Так же столкнулся с этим вопросом. Было бы еще интересно как удалять все лишне, пропущенное ранее. т.е. удалить все и записать только нужное

[mgo 20]

 

 

аметил что резет , или массовый резет не затрагивает отключенных абонентов , те которые с минусом на счету.

так і має бути, старгейзер відстріленого користувача нетрогає, він і так помер)

для НАС rscriptd & Local NAS  цілком пристойно ця логіка працює.

 

а для мікротіка очищуйте вручкну фаєр і  арп перед масовим ресетом а краще перезапуск старгейзера.

з масовим ресетом колись спецефекти всякі спостерігались.

[zaza12 2]

то что существует технология добавления вручную в микротик запись в  arp лист и адрес лист - мы уже знаем! Почему скрипты в ubilling не добавляют по api просто запись в микротик тех у кого минус на счету  ( минус , это не значит что клиент труп , у него есть кабинет и ip который выдает микротик ) ?

[mgo 20]

 

 

Почему скрипты в ubilling не добавляют по api просто запись в микротик тех у кого минус на счету

це все додається скриптом onConnect

він відпрацьовує тільки коли абонент активний

чо так? запитайте того хто писав.

[zaza12 2]

 

Почему скрипты в ubilling не добавляют по api просто запись в микротик тех у кого минус на счету

це все додається скриптом onConnect

він відпрацьовує тільки коли абонент активний

чо так? запитайте того хто писав.

 

Что там спрашивать , мне кажется что тот кто писал больно уж предвзято относится к микротик ,  учитывая с какой скоростью резетятся  на микротике 50 записей - минуты 2 или 3. Складывается впечатление что тот кто писал , сам удаленно подключается к микротик  и вручную все там правит.

[mgo 20]

скажите спасибо за то что есть.

остальное ненравится напилете сами))

[Golthana 3]

 

 

тот кто писал больно уж предвзято относится к микротик

 

Зря Вы так думаете. Если учитывать тот факт, что продукт полностью бесплатный и над ним работает не так много людей, то сам проект достаточно быстро развивается. Попробуйте использовать FreeRadius вместо предложенного API

[jcomm 6]

Почему скрипты в ubilling не добавляют по api просто запись в микротик тех у кого минус на счету  ( минус , это не значит что клиент труп , у него есть кабинет и ip который выдает микротик ) ?

Хмм... Предлагаете мимо старгайзера дергать скрипты OnConnect/OnDisconnect?

MikroTik API абсолютно ничем не отличается от rscriptd. Хотите, почистите таблицы ipfw и arp на насе для и запустите масс. ресет. Что-то подсказывает, что "минусовых" пользователей тоже не будет.

 

Что там спрашивать , мне кажется что тот кто писал больно уж предвзято относится к микротик ,  учитывая с какой скоростью резетятся  на микротике 50 записей - минуты 2 или 3. Складывается впечатление что тот кто писал , сам удаленно подключается к микротик  и вручную все там правит.

Не нравиться, пишите сами. Не можете сами, давайте мешок денег и готов с вами пообсуждать глобальные проблемы моего кода.

2016-06-16 00:00:19 - [Ubilling] - OnDisconnect started for user `16ap8_8jkg`:
2016-06-16 00:00:19 - [Executer] - Success: Firewall entry was updated/created
2016-06-16 00:00:19 - [Executer] - Success: Queue entry was updated/created
2016-06-16 00:00:19 - [Executer] - Success: ARP entry was updated/created
2016-06-16 00:00:19 - [Ubilling] - QC: 6, elapsed time: 0.297 sec.

Эмм.. 120/50 = ~2.4 секунды на пользователя? (да, так и есть на пятой ветке ROS). Вот если бы вы, не предвзятый, следили бы за changelog`ами, то знали бы, что в 6 ветке они работают гораздо быстрее.  Как по мне 0.297 сек. на пользователя никак не стоят рядом с вашими ~2.4 сек.

 

P.S. На всякий случай, для НЕ понимающих. Проблема времени не в написанном коде, а в самом ROS API. Обновитесь до 6 ветки и будет вам счастье.

Edited 2016-06-16 17:18:17 by jcomm

[Golthana 3]

У меня чуть больше, чем указано выше, но тем не менее шустро. Так что пробуйте обновить RouterOS

[Golthana 3]

 

jcomm, не могли бы Вы объяснить что даст для пользователей Ubilling управление деревом очередей. Это альтернатива обычным очередям или дополнение. Заранее спасибо.

 

[jcomm 6]

jcomm, не могли бы Вы объяснить что даст для пользователей Ubilling управление деревом очередей. Это альтернатива обычным очередям или дополнение. Заранее спасибо.

Да, это альтернатива простым очередям. Саму политику деревьев нужно настраивать самостоятельно. Скрипты просто будут добавлять пользователя в address-list, соответствующий тарифу пользователя. Лично я пользуюсь только простыми, но это дело вкуса, как по мне.

[Golthana 3]

Спасибо