nightfly

молодец, прочитали наконец выше, что следует сделать перед обновлением? Кстати как, за ваш заказ, сумашедшие деньги "до первых чисел октября" собрали уже, не?

Это кстати я не вас вспомнил - была ситуация с пересчитыванием на счетах/калькуляторах, по блокнотику + "вспоминанием" по памяти что это за абонент и сколько там денег должно было быть и куда. Что-то под кило абонентов так, поштучно. У вас еще все хорошо в этой жизни. Радуйтесь

2 samsung Стучите что-ли, попробуем вам что-то придумать. 2 logic При внедрениях я уже и не такое видел , поверьте - это еще очень хороший вариант. В любом случае хотя бы без записок в блокнотиках и деревянных счетов

Между и вобще не вижу никакой взаимосвязи. Не вижу проблем просто из онконекта просто устанавливать флаги активности пользователя а кроном ежесуточно колбасить доп. сервисы. Это светит как минимум убиранием тяжелой логики из скриптов инициализации пользователей. На нормальных количествах абонентов это может оказаться очень полезным решением.

нету там его, файрбьорд же

Тем более глупость. Больным местом вайфая является пакетная производительность железок, а не какие-то астральные "сессии" в текущем контексте. В любом случае абонент заплатил за то, чтобы быть "качком" и если провайдер не может выдержать вот такого одного "качка", то на лицо проблема организации инфраструктуры самого провайдера, либо неверный подход к построению уровня доступа для CPE, а не проблемы конечного абонента. Это даже не смешной мизер. Мне интерестно не случится ли с вами эпилептический припадок, если вы увидите "от полумилиона" connections на каждом из экземпляров nat-а?

Небольшой соцопрос. Закрадывается желание немного изменить модель разработки, чтобы улучшить фидбек и ровность релизных версий в дальнейшем. А также немножечко сократить частоту релизов как таковых. Сейчас, как не сложно заметить, релизы выходят довольно часто в силу существующей модели: "пишем-пишем -> релиз -> ловим баги -> фиксим баги -> пишем-пишем -> релиз -> опять что-то сломалось.." и так далее по-кругу. Что влечет за собой текущее положение вещей. Что планируется изменить: дать возможность самым экстремальным либо нетерпеливым, либо страждущим обновляться не

Ну никто не запрещает рисовать setup рулесы, отдельно по портам, прямо из OnConnect или оттуда же основываясь на каких-то CF полях из профиля пользователя, чтобы обеспечить визуальность. Только смысла в этом нету никакого - операции типа шейпа-ната более pps чем "сесионно" зависимы, а городить statefull решение будет какраз в контексте экономии ресурсов NAS бесперспективно. Докрутить памяти кернелспейсу намного проще и эффективнее. А если самоцель, как я подозреваю, просто "сэкономить" интернеты от пользователей - дык еще проще им просто их отключить. Они деньги за интернет платят что-ли

Почитайте про keep-state, например.

Обновиться до 0.3.4 по дороге не забудьте. Там много мажорных изменений которые требуют фидбека, и собственно это единственный поддерживаемый релиз на сегодняшний день.

какой модуль захвата используется в stargazer?

У меня сейчас эпилептический припадок будет. Эти ваши линуксы не перестают радовать

Ubilling 0.3.4 rev 2060 Изменения в структуре БД, см дамп. alter.ini: новая опция TB_LABELED добавляющая подписи к иконкам alter.ini: новая опция ARPING_EXTRA_OPTIONS описывающая дополнительные опции для arping alter.ini: новая опция CATV_HP_MODE включающая альтернативный рендер для списка пользователей КТВ alter.ini: новая опция DISCOUNTS_ENABLED включающая поддержку скидок alter.ini: новая опция DISCOUNT_PERCENT_CFID определяющая ID доп. поля устанавливающего процент скидки alter.ini: новая опция DISCOUNT_OPERATION устанавливающая тип операции под которым будет осуществляться работа с

Да, это описано в FAQ Приблизительно правильно. Все что вам нужно от PHP по минимум это вот такой конфиг: magic_quotes_gpc = Off magic_quotes_runtime = Off magic_quotes_sybase = Off date.timezone="Europe/Kiev" больше там может ничего не быть. А вот это очень даже даром вы попытались сделать. Об этом тоже сказано в FAQ =) Для начала загляните на такого пользователя в "Черная магия" -> "Проверка целосности" Для начала давайте попробуем отдебужить по наивному. Тыкаете "SQL консоль" -> "PHP консоль" и исполняете там следующее: $login_q="SELECT `login

Ну при ресете он должен сохранять свое предыдущее состояние. Именно по этому по дефолту ресет использует "Down".

Не, сами пользуемся, отморозков предостаточно На будущее планирую убить двух зайцев - сделать управляемой опицю ресета и заодно рассматривать ее в AlwaysOnline ипостасии как хотфикс проблемы до 2.409.

...И при этом Ubilling настоятельно рекомендует использовать BSD системы для своей работы. Для случаев если нужно организовать уровень доступа на каком-то внешнем NAS есть эпический rscriptd. Как еще где-то пол сотни сетей использующих Ubilling на разношерстных линуксах забив на неродность системы. Вон тот же Спайдер, например. Однозначно. Поэтому по-умолчанию пользователя стоит гасить не "отключенностью" а ВсегдаОнлайном или Морозильником, как рекомендовалось раньше. Ресеты зовутся для практически по каждому чиху, для надежности сохранения актуальности пользовательского состоян

Что значит "не работает"? Если в логе старгейзера пользователю выставляется отвал - значит он отвалился. Если же этого фактически не произошло - значит это проблема того, что нарисовано в OnConnect/OnDisconnect.

Ну вобще-то так и выглядит вырубание при помощи "Отключен". Другой вопрос, что штатная операция reset() может последовательно вызывать down 1/0 и накрывать предыдущее значение. Она вызывается как минимум при: смене тарифа, смене MAC, смене IP, собственно тыканьи на "Ресет", изменении оверрайда скорости а также при изменениях CF и тегов если включены соответствующие опции в alter.ini. В таких случаях следует вырубать пользователя при помощи либо "ВсегдаОнлайн" либо при помощи "Замораживалки".

Таких сервісів багато, наприклад ще можу згадати https://www.skydns.ru/ або http://www.scrubit.com/ - ті ж яйця тільки в профіль. Можна наприклад налаштувати собі dns forwarder на такі сервіси і абонентам з відповідним сервісом наприклад "дитячі інтернети" видавати власне його зразу з допомогою DHCP. Вся механіка для цього вже є.

При всем уважении, я не рекомендую называть этот бродком, сетевыми вообще. "Сетевая" на данный момент существует аж одна - это 82576.

Не должно быть. По сути NAT далеко не настолько трудоемкая задача. Максимум, что там может кончиться это доступная ядру память. Смотрим в vmstat и если что крутим KVA_PAGES, vm.kmem_size и соответственно буфера. К сожелению статистика ipfw nat show очень скудная, но если вы не видите там шестизначных цифр - все должно быть вполне нормально, даже по дефолту. При невырубленных чексумах и ТСО у нас в свое время просто захлопывались физические сетевухи и не подымались до down/up. Уход в ребут уже недобрый симптом намекающий на извечные проблемы с тунельными соединениями и сколько помниться кр

Кстати да, "-rxcsum -txcsum -tso" практически объязательны на данный момент. libalias их очень не любит.

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

Такое хоронить нужно а не абонентов там держать. http://dadv.livejournal.com/139170.html#cutid1