nightfly

Попробуйте атипичные нейролептики. Рекомендую.

Откуда в ядре netgraph? mpd что-ли используете для подключения к прову? Можно не обращать внимания, всего лишь нотификация о том что сабнеты в одном скоупе ака шаред сабнете. Оставлено для совместимости. Есть очень нехорошие подозрения, что интернет у ваших абонентов пропадает и не подымается при обрывах ppp сессий изза того, что например может дефолтраут уходить в пустоту. Либо потому, что экземпляр НАТа поднят на уже убитом давно интерфейсе. felixio_01 а чего, оно в этих ваших линуксах из коробки не того?

подозреваю что там еще должны быть периодические вопли про "no buffer space avaliable" или "interrupt storm detected on throttling interrupt source" - учитывая сетевую. ок Там должно быть что угодно но только не "весь интернет". 9-я табличка по умолчанию указывает на хосты к которым не нужно производить NAT (читаем локальные ресурсы). Уберите это нафиг оттуда. Соответственно обратное правило ipfw nat следует рисовать по интерфейсу. ок ну допустим. /etc/firewall.conf еще покажите и /etc/rc.conf - подозреваю еще и там творческий подход ЗЫ уехал, вернусь в

Такого не бывает, потому что не бывает. вывод после "зависания" в студию: # ifconfig -a (rl,vr,nv - я угадал? ) # tail /var/log/messages # ipfw nat 1 show # ipfw show # ipfw table 2 list # ipfw table 9 list # netstat 1 # top -SHPb Тогда ясно зачем нужна ресетилка. И нет - так не должно быть. В норме вообще не стоит и не нужно лезть в консоль в процессе ежедневной експлуатации ubilling-а.

Тоесть уже не актуально За скриптовыми подпорками будущее!

У-у-х как занятно, почти как ng_netflow

Сами ждем, приходится одновременно поддерживать около 6-ти актуальных линеек тарифных планов

смысл?

Мы опередили вашу хотелку где-то на неделю Данная фича уже в разработке. Уйдет в 0.3.2. Потребности правда чуть другие но логика та-же. Хотим дополнить опции TC_TARIFFSALLOWED, TC_TARIFFENABLEDFROM дополнительной опцией TC_EXTENDED подключающей дополнительный конфиг tcdirections.ini следующего вида: Mega-10="Mega-100,Mega-50" Mega-50="Mega-100,Mega-10" Mega-100="Mega-50,Mega-10" Super-50="Mega-10,Mega-50,Mega-100" Думаю очевидно зачем это нужно и все вытекающие из этого плюшки.

Релиз Ubilling 0.3.1 rev 1846 Список изменений - Изменения в структуре БД, см. дамп. - alter.ini: новая опция REMOTEAPI_ENABLED включающая удаленный вызов процедур - alter.ini: новая опция RADIUST_ENABLED включающая поддержку шаблонизации аттрибутов Radius - Модуль «Свитчи»: теперь возможно добавление задач периодического переопроса свитчей при помощи crontab (GET cronping=серийник) - Модуль «События»: теперь поиск по паттерну отображает лимитируемое количество результатов - Модуль «История смертижизни»: теперь отображаються внутренности пользователя в прямом виде. -

Если завернется по причине проблемной прошивки контроллера - кирдык. Таким болеют OCZ массово. Если по истечению лимита записи по ячейкам - уходит в ридонли. Честно говоря за последних два года такого не видел. Скопытилась парочка OCZ Vertex и Intel MLC на первых месяцах использования, по причине подыхания контроллеров. Сейчас на всех десктопах-ноутах торчат SSD от Kingston. Полет нормальный уже несколько лет. З.Ы. В любом случае админы делятся на тех кто делает бекапы и кто УЖЕ делает бекапы. Не пофиг как оно подохнет? З.Ы2. Сложно представить нафига биллинговому серверу ССД. Если у ва

В любом случае вы не должны видеть MAC-и вафельных железок по дороге к абоненту. Особенно если за железкой их висит более одного. DHCP - немаршрутизируемый протокол. ЗЫ давеча строили людям похожую судя по всему схему - два микротика в роли бриджа, с одной стороны биллинги-НАСы, с другой свитчи и дальше витой парой по абонентам. Все работает успешно. ЗЫ2 и в роли точка-мультиточка вполне себе работает - опять же всего-то нужно чтобы раздающая была бриджом.

Стоп, под AP вы понимаете раздающую точку или клиентскую? Если разрающую - то там должен быть прозрачный WDS бридж, нормально бриджащий dhcp реквесты от заассоциированных клиентов. Если клиентскую типа наноса либо СХТ - то либо сделайте из нее бридж, с последующим прописыванием МАС абонентского ПК, либо настройте ее как роутер (что к слову более логично) и тогда регистрируйте по МАС самой точки. В любом случае не вижу никаких глубинных проблем.

Бьюсь в истерике. Нельзя же так.

Это понятно - поскольку не знает оно что выдавать неизвестному МАС. Дык 00:FF:FF:FF:FF - чье? Машины пользователя? АР-шки?

Что значит при "автоматической" смене? Если смена происходит "прям щас" - то для этого есть опция TARIFFCHGRESET которая включена по умолчанию в alter.ini Если смена происходит "со следующего месяца" - просто тыкните опцию ReconnectOnTariffChange=yes в stargazer.conf

Практика говорит, что sgconf_xml по умолчанию отлично уже работает годами Хотя чего, есть оно, тоже работает. Всего-то сделать baseconf = xmlrpc в billing.ini А напрямую из консоли, тем более на таких задачах как установка/снятие единичного флага, удобнее юзать таки sgconf в одну строчку.

Визуально сравните что-ли соответствует ли 00:FF:FF:FF:FF тому что нарисовано в биллинге для абонента 192.168.10.211. А вопли всего лишь намекают на то, что имеется попытка модификации статических arp записей которые подымает биллинг из OnConnect.

DarkSpider Все в почте. Активация тоже в теории должна работать. DarkLan Да. Способов вагон. Смотря зачем нужно. Если при изменении тарифа "в следующем месяце" то можно использовать либо опцию NMCHANGE либо штатную механику stargazer в виде ReconnectOnTariffChange. В случае если требуется ресетнуть абонентов "прям щас и уже" можно свободно воспользоваться консолью разработчика(там еще недавно сохранение шаблонов появилось), пиная при этом $billing->resetuser(логин_юзера); в цикле.Также начиная с 0.3.1 будет доступен вызов ?module=remoteapi&key=серийник&action=reset&para

Там используются вызовы нового API самого Ubilling, для ресета пользователя и перестроения конфигов DHCP Сейчас в разъездах, вернусь в свой город к вечеру, попробую собрать что-то похожее на рабочий вариант.

Небольшой анонс: Как и обещал, к концу недели добил сервис под кодовым именем "фиговина". Предварительно с концепцией можно ознакомиться вот по этой ссылочке. До выхода 0.3.1 осталось немного вылизывания, немного косметики, в основном багфиксы + парочка заказушных штук. Есть все основания полагать, что релиз зарелизиться на следующей неделе.

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

Посмотреть щелкают ли счетчики трафика у активных абонентов. Очевидно же. Ну можно еще попробовать поднять себе, скажем коллектор из flow-tools и глазами посмотреть чего там дампиться.

Ну его хотябы используют

Ой, чойта их так много форков? Ну можно посмотреть отправляет ли он старгейзеру стату с последующим щелканьем каунтеров