madf

Да. А с текущими цифрами возможны какие-то грабли ? Мне казалось я всё предусмотрел. Из моих соображений как недостаток можно рассматривать большое число опросов состояния очереди на медленно выполняемых скриптах, мне не известно насколько ресурсо-ёмкая эта операция т.е. возможна доп. нагрузка на систему заметная на слабых машинах хотя у себя я пока такого не заметил. Пауза слишком маленькая - повышение нагрузки на процессор (не забываем что при msgctl происходит переключение контекста!). Пауза слишком большая - увеличение латентности системы при реакции на события. Максимальн

Вопрос про параметры, я так понимаю, касается задержки и длины очереди? Правильных цифр тут быть не может. В 2.408 патч точно не войдет, и в том виде в котором он представлен он вряд ли вообще попадает в кодовую базу. Пока буду искать более правильное решение проблемы.

Я и есть этот разработчик Сборку провожу не из SRPM а прямо из тарболла, по этому SRPM нету. У меня нету опыта работы с RPM-системами, по этому собрал как смог. Если есть желаение - можете помейнтейнить пакет для CentOS. Про сборку ответил в письме.

А он вообще у кого-нибуть есть? Я не видел чтобы кто-то собирал пакеты для qia.

У cap_nf только два параметра, из которых только один полезный. Коллектор отдает данные в биллинг мгновенно, как только они приходят. Данные в InetAccess поступают с некоторой задержкой, равной UserDelay (параметр плагина auth_ia, обычно ставится порядка минуты, но можно уменьшить вплоть до 1 сек). Ваша задержка вызвана логикой работы самого NetFlow и тут ничего не поделаешь. Если планируете использовать NetFlow - смиритесь.

Хотите считать точно и в реальном времени - используйте производительное оборудование. К стати, не увидел ничего плохого в нагрузке в 3-5% и записях tee в файрволе.

В чем проявляется тормознутость "хрени"?

http://stg.dp.ua/doc20/conf_divert.html Только вместо divert в файрволе лучше использовать tee.

Это если продукт - файл, который он качал. А если продукт - доступ к сети Internet то логично рубить даже на 99.5%. Быстрее денег занесет Про "соточку за чирик" согласен, сейчас мало кого волнуют объемы трафика. Нынче стало просто биллинг написать - взял FreeRADIUS, пяток скриптов на шелле, СУБД какую-нибуть завалящую (не будем тыкать пальцем ), CakePHP и зафигачил мега-биллинг.

Ага, while (true==true) { sgconf set ..blabla... -u$user --ud1 $value } тоже типа не запрещено. Но кто сказал что так стоит делать и что это не закончится фигово? А почему фигово? Вот у админа цель была - завесить Stargazer. Начальник ему денег не заплатил, например, вот он и устроил ему такую подлянку. Я не запрещаю устраивать подлянки с помощью Stargazer

В прочем, в ваших словах есть рациональное зерно. Такое изменение порядка загрузки плагинов не должно отразиться на работе, и при этом оно вполне логично. Пожалуй, в 2.408 я пересмотрю порядок загрузки плагинов.

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

Как минимум минус в изменении поведения по умолчанию. Вдруг для кого-то это окажется неприятным сюрпризом? Лучше отдать это в руки человека который выполняет настройку системы - тобишь, вынести в виде необязательных параметров плагинов. Хотя и здесь есть одна заковыка. Большинство плагинов при получении конфигурационной информации как раз и выполняют свою активацию... Но это уже чисто техническая проблема.

Это на тебя так повлияла работа с первыми версиями старика Если что-то не запрещено явно, значит это разрешено. Изменять параметры абона в процессе выполнения скриптов не запрещено - значит будем бороться с проблемами которые это вызывает.

Это не издержки - а полностью логично и закономерно. Если у юзера пакетный тариф 1 гиг и уже скачано 350 мег то при закачке 700 мегового камрипа его не обламает на 98% (и предоплаченый трафик до этого значится пропал даром?), а даст докачать его киношку и посчитает трафик за всю сессию что будет намекать на то что он должен заплатить по оверквоте за тех 50мег. Хотя да - можно сессии хоть раз в минуту скидывать - тогда на скорости в 1 сферический мбит/с оверквота составит ~7мег. Я уже не раз встречал мнение что заводить абонента в долги нельзя. В прочем, у всех разные условия предоставления

Это издержки технологии NetFlow. Если не устраивает - используйте cap_divert.

Я вот, например, всегда лезу в исходники при граблях

Правильный вывод. Эта очередь реализована гдето в ядре ОС - это часть механизма IPC. Можно проверять состояние очереди с помощью msgctl, по в случае если она переполнена все равно не получится ничего сделать. Запрос на выполнение скрипта нужно поставить в очередь, но сделать это невозможно, по этому нить блокируется, что и вызывает описанные выше эффекты. Нужно либо научитья управлять размером очереди, либо добавить промежуточный кольцевой буфер между stargazer core и script executer и управлять уже его размером. Суть решения проста - очередь должна быть достаточно велика чтобы вме

Все очень просто. Так работает NetFlow. softflowd - "сенсор" в терминологии NetFlow - считает трафик и аггрегирует его в потоки ("flow"), которые потом сливает на коллектор, в роли которого выступает Stargazer. Соответственно, информация о трафике доходит до него с задержкой, равной времени жизни одного flow. Это регулируется настройками сенсора, но все равно задержка будет. Есть еще, к стати, и принудительный сброс "потоков", но как его сделать в softflowd я не знаю.

Среди тикетов есть один по реализации ручного управления тем, какие параметры будут передаваться в скрипты On*, как это реализовано для rscriptd. Выполнить его не сложно, но в 2.408 это не попадет.

projects/stargazer/plugins/configuration/sgconfig/stgconfig.cpp, строка 243. Заменить 220 на 10. Аналогичную замену провести в строке 248. Таким макаром вы заставите стартовать плагин конфигуратора раньше плагинов авторизации (у них 70 и 50).

Все таки не смотря на то что Ubilling работает поверх Stargazer - это разные проекты, которыми занимаются разные люди, преследующие разные цели. Так что вероятность того что они окажутся в одном репозитории стремится к нулю Без проблем, наверное, все равно бы не получилось. Система сложная, многокомпонентная, да еще и разрабатывалась изначально под FreeBSD. Не удивительно что под Linux не все проходит гладко. Вот Stargazer, например, изначально разрабатывался под Linux, и его беспроблемная установка и работа под FreeBSD (по крайней мере в большинстве случаев ) - это результат бесчисленных

Скорее для разработчиков подобные "нестыковки" незаметны Я бы беспокоился не про интеграцию с FreeRADIUS а про интеграцию с платежными системами. С FreeRADIUS как раз все просто и прозрачно. В его конфиге прописываются скрипты которые будут проверять данные на этапах аутентификации и авторизации (обычно это прямо SQL, в документации есть примеры) и при необходимости вносить данные в БД при аккаунтинге. Тут важно понять что такое RADIUS и как он работает. К стати, если есть "творческая жилка" то написать свой простенький биллинг на Java будет интересным опытом.

Ну если быть совсем точным, то вместо cap_bpf можно использовать cap_divert и в файрволе добавить правила для tee. А если использовать cap_nf то TCPPort можно не указывать, все равно вы не используете NetFlow-proxy. А так все верно сказано, BPF может пропускать пакеты.

В самом Stargazer это организовать не получится, даже авторизацию по RADIUS (rlm_stg в печальном состоянии). Но выше уже правильно заметили что Ubilling, являющийся надстройкой над Stargazer, покрывает все ваши запросы. А я вот всегда думал что $ ./build && make install $ /usr/sbin/stargazer - это как раз для домохозяек