nightfly

Сколько помню у них там есть свой ядерный модуль експорта - типа ng_flow. Вроде ок. Правда ніфіга не розумію яка практична цінність в авторизації юзера по login+password+mac. Нє, ну ясно - додаткове секуріті і всьо таке. Але блін... зручність такого рішення для фінального юзера це ж жесть. Тобто поверху в кращому разі UHW, додається ще "ой у мене 691 помилка" і інший букет чисто РРР проблем. Раз вже знаєте маки юзерів - не простіше роздати пачкою їм айпішок і забути?

Знаю - воно успішно і на нанобріджах, наностейшнах і паверстейшнах працює. Тільки тсссс... нікому не кажіть

а я вообще нипричем, у меня другая, правильная религия - "во имя rscriptd"

Анрыл - там все одним здоровым паком.

Не, оно таки подохло. Разбираемся.

Робить - і пох. Так кажете ніби я з ним дружу P.S. головне в jcomm нічо про кверізи не питати - від його SQL-я коні дохнуть.

Для всяких таких речей, типу "пошукати всіх юзерів з маками аля 14:88" є майстер звітів. Він власне і спрямований на формування різних нестандартних виборок.

ні Воно взагалі шукає тільки одного користувача. Бай дефолт там мав би бути строгий пошук тільки по цілому маку і діставання тільки одного юзера, за його маком, росте ногами з примусової унікальності його в рамках всього nethosts. Короче кажучи то "історична" фіча

Оцетіпасього? http://wiki.ubilling.net.ua/doku.php?id=accelppp Та аби я руками ше раз туди добровільно поліз... нєєєєє, дякую Хз, комбайн як комбайн. Нічо особливо цікавого не побачив. Можливо його так люблять, бо для цих їхніх лінуксів то один з небагатьох варіантів, хоч якось працювати, не зламавши мозок об хворий tc та всі інші обвіси. Імха Linux ISG і той концептуальніший - до нього таки буду дивитись, якщо видасться якийсь період, коли "взагалі нема чим зайнятись".

+- 5-10 хвилин від написання коду і вкомічування в репозитарій. Якщо бути точним, то COLORIZE_PROFILE_CASH там матеріалізувався 2014/09/15 23:10

Нині, від третьої ночі сижу сам на CURRENT 0.5.8 rev 3741 - поки що живий. Ну а шо ви чекали? http://wiki.ubilling.net.ua/doku.php?id=relnotes#section058

1. Включить в alter.ini TB_SWITCHMON=1 2. RemoteAPI - swping скажем раз в */20 * * * * будет вполне себе ок относительно дефолтного SW_PINGTIMEOUT. swpoll и swping никак между собой не связаны - это разные подсистемы. При ручном переопросе помниться машина времени не заполняется, поскольку количество "трупиков" для наочности планируется одинаковым в рамках суток. Так и задумано - заполняется при переодичном переопросе при помощи swping. Показывает ранее упокоившиеся свитчи. Нужно для того, чтобы можно было задним числом узнать от сколько-до-сколько валялись ка

Мало би працювати. Макрос {MAC} присутній в дефолтній вьюшці radius_reply. P.S. якщо ви насправді вирішили використовувати поточну реалізацію роботи freeradius, думаю варто оновитись до CURRENT збірки - там хоча б нормально параметри NAS-ів показуються тепер.

можете переставати чухатись - всьо буде норм

Ну приведите способ воспроизведения бага - быстренько посмотрим что можно сделать.

Я стараюсь не чіпати взагалі ніколи таблички самого старгейзера. А на убіллінгові замашки йому взагалі наплювати - він живе своїм особливим життям. "Зупинка-оновлення-старт" може бути справді потрібним тільки в тих рідких випадках, коли оновлюються скрипти ініціалізації користувачів. Останніх рік-два себе та клієнтів оновлюю тупо методом cd /usr/local/www/apache22/data && cp -R billing aaa_pamagite && sh autoubupdate.sh

Была, и неоднократно на этом форуме всплывала В сторону херово заполненных опций SGCONF = /usr/sbin/sgconf STG_HOST = localhost STG_PORT = 5555 STG_LOGIN = admin STG_PASSWD = 123456 Больше там физически нечему "сломаться". Проверяется очень просто - попыткой использования модулей кабинета, типа "замораживания", "менялки тарифа" или "попрошайки". Они все используют абсолютно одну и ту же механику работы со stargazer-ом. Также никто не возбраняет нагенерировать вам карточек с ценой "1 xyй", но искренне надеюсь, что вы до этого не догадались. В таком случае да - карточки будут помеч

нафіга?

Ну пардон. "Генетически" - так лучше? Отключать. Ну либо включать мозг и нормально строить кластер исходя из конкретных реалий. Опять же - пятизначные количества абонентов меня не пугают. Если у вас с этим какие-то проблемы - это не ко мне.

Симметрично. С другой стороны знаю достаточное количество провайдеров давно забивших на подсчет трафика. Хоть из того же flowtools можно слепить на коленке. Хотя есть и интереснее варианты. Как уже писал выше - день-два с перекурами.

это понимание, приходящее планомерно, годами в процессе работы. Нет проблем. 1. У вас нету опыта работы с большими абонбазами, судя по "вопросам" которые вы озвучиваете. 2. У вас нету понимания, работы в целом stargazer-a и внутренних процессов которые там происходят. 3. Вы не знакомы с архитектурой и с действительно больными и медленными местами Ubilling-a (а таких дохера, не отрицаю - они просто не очевидны). Поэтому, я в принципе не вижу никакого смысла обсуждать с вами вопросы внедрения Ubilling-a в сетях на 10-20-30-40-50к абонентов, построения каких-то хайлоад решений, и

дета так Дает, на самом деле. Витрати -> По номеру договору -> Деталізація трафіку. По первому клику рендерится довольно долго, так что да, думаю это таки какая-то внешняя и кешируемая стата с какого-то внешнего коллектора, как и вещалось мною выше. Оно себе может просто складывать и суммировать/сегментировать данные периодически, ну и собсно тормозить сколько влезет - не критично же. Та пытались, да. Вспоминается "Закон 404".

Либо вынести на какой-то внешний коллектор, с кешированием статистики. Развлечение на день. На два - с тестированием и дебагом. Нет. Не нужно. А если нужно - выше отписал. Почему - вполне доходчиво озвучил выше ronin_zp. Как я уже говорил "у вас столько нет абонентов". В противном случае таких вопросов не возникало бы. Увеличение количества юзеров на десятки тысяч не происходит ВНЕЗАПНО и спонтанно. И все ньюансы вылезающие при обслуживании абонбаз больше "средних", люди с ними работающие как-бы знают изначально. Намекну - проблемы там совсем другие. Для этого, есть специализ

Хотя бы как-то так Угу. Основываясь на личных наблюдениях, постоянном бенчмарканьи и профайлинге, а также постоянном общением с провайдерами разного пошиба? Могу вполне себе заванговать циферку текущей прочности stargazer-а в комплекте с ubilling-ом в районе 50к с отключенными каунтерами. В живую наблюдал в районе тридцатки - все путем там. Без ubilling-a в его текущем упоротом виде, и без smp capable cap_nf там вообще тормозить нечему, так что не вижу, чем с его точки зрения должны отличаться 30 и скажем 100к юзеров.

Много. Действительно много. У вас столько нет. И да, от подсчета трафика при помощи cap_nf в текущем виде, придется отказаться уже где-то при 15-20к.