nightfly

Потому, что в христианской культуре трупов хоронить принято.

От фонаря попробовал, без особого понимания как работает микротик - все взлетело. Что я делаю не так? А спросить либо на форуме либо у официальной поддержки решений на микротике конечно же не судьба.... Нету. Есть четкое указание - mikrotik direct устарел и больше не поддерживается, используйте mikrotik API.

Интересно, а надпись "Эта реализация считается устаревшей и рекомендуется только для ознакомления, используйте Управление MikroTik через API" написанная конскими жирными буквами, абсолютно никому ничего не говорит? ЗЫ Mikrotik Direct будет выброшен в ближайших релизах.

В догонку, обновлена живая демка: http://ubilling.net.ua/?module=fnpages&pid=demo

Изгнание демонов и очищение огнем - запланированы на 0.4.3

Релиз Ubilling 0.4.2 - rev 2660 - Изменения в структуре БД, см дамп. - Кабинет пользователя: исправлена работа функции показа оставшегося срока оплаченной услуги - Модуль «Опрос свичей»: добавлены шаблоны для Foxgate-S6224-S4, Foxgate-S6248-S4, Foxgate-S6208-S1. Спасибо DarkSpider. - Модуль «Опрос свичей»: исправлены парсеры CPU, памяти, состояния и описания портов для работы на свичах Dlink. Спасибо DemonidZe. - Модуль «Опрос свичей»: DemonidZe добавил много-много шаблонов для свичей Dlink и HP. Подробнее здесь. - Шаблоны устройств SNMP: в секции define появил

думаю 60

Если старгейзер и rscriptd версии 2.408 - такой проблемы быть не должно. Посмотрите нету ли чисто случайно потерь между самим биллингом и НАС-ом (ага, rscriptd работает на UDP). Возможно есть смысл немного увеличить UserTimeout скажем до 120. Особо хуже точно не будет. Если же ликвидация потерь и увеличение таймаута "неполученности" пакета не помогает - пробуйте выставить количество Executers в 2. Хотя в нормальных условиях такого быть не должно.

....а еще есть штатный автоматизированный скрипт, который нормально собирает и ставит все базовые зависимости.

Если вы это про Беларусь, то были толи прошлым, толи позапрошлым летом в Бресте и окресностях. Теперь в моем сознании это такая волшебная страна, с совершенно бесподобными(!) дорогами, просто очуменными(!!!) и сверхдешевыми свежими продуктами, какой-то местами очень нездоровой чистотой стерильностью улиц, которую в Европах не часто увидишь и очень вежливыми и приятными таможенниками(!!). А да, и еще фермы-поля тоже очень кавайные миленькие. Хз, возможно это все выглядит изнутри не так радужно(разница официального и нормального курса обмена, да?), но внешние впечатления очень даже приятные

Ну дык внутри все свое, родное Добавил

Усё. Ппостарался максимально не поуродовав оригинальный код всунуть ваш бекенд с фронтендом в поставку оригинального OpenPayz. Возможно, немного чего-то поломал но если что - вылезет на первом желающем использовать эту ПС. Еще раз спасибо.

Спасибо, думаю к утру уже будет в CURRENT ветке. Не виню - сам до сих пор с ним разобраться не могу Все намного проще и "влобнее"

Чисто из интереса зырнул в код - там жуткая жуть, испугался, закрыл. Давай может перепишу с нуля этот чудесный "Отчет по трафику" с учетом твоей микротичной реальности на досуге?

Ubilling такого не вміє писати взагалі. Переконайтесь, що за посиланням http://nas/graphs/queue/логінюзера/daily.gif у вас лежать графіки його черги.

Это у вас юмор такой? Извините шутку не понял.

Еммм, як?

В сторону UHW. Редирект по 47 табличке строиться абсолютно идентично. Возможно стоит убрать один из последних deny.

Доречі, це ж можна прочитати в контекстній справці

http://nas/graphs/queue/ - шось типу того.

Ну значит я был очень прав в своем желании увидеть SELECT Tariff,Login,IP from `users` WHERE `login`='vd176' В любом случае такие артефакты не критичны, поскольку при смене тарифов и чего только можно вызывается событие reset() которое всеравно подымет правильный пайп. Это к слову тоже описано в FAQ

Хорошо, лишний оверрайд грохнули. Внезапно. Окей, давайте посмотрим на SELECT Tariff,Login,IP from `users` WHERE `login`='vd176' Из того что вижу, есть чувство, что у вас слегка крякнута целостность данных. Могу предположить, что вы вырубили настоятельно(!) рекомендуемую и заведомо опасную опцию SAFE_REGMODE и пытались либо дважды зарегистрировать одного и того же пользователя, либо попытались его регистрировать удалив такого-же, но не дождавшись полного удаления предыдушего (описано в FAQ).

Хорошо, только почему их два? Сделайте по дороге DELETE from `userspeeds` where `id'='179'

Ок, будем теперь считать, что проблема с юзером А теперь немного магии. Идете в "Консоль разработчика", и тыцаете в "SQL консоль" следующие запросы: SELECT * from `userspeeds` where `login`='gai' SELECT * FROM `users` LEFT JOIN tariffs ON users.Tariff=tariffs.name WHERE login='gai'

Окей, если OnConnect дефолтный - остаются открытыми вопросы только по поводу /etc/stargazer/GetSpeed %user_login% и значения параметра "Переназначение скорости"