nightfly

Не, сами пользуемся, отморозков предостаточно На будущее планирую убить двух зайцев - сделать управляемой опицю ресета и заодно рассматривать ее в 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

Была вроде во времена 7.1. Некрофилы помнят Не, их разработчикам никто еще не сказал, что оно существует. Далеко не факт, там один и тот же libalias в кернел спейсе отрабатывает. Все зависит от подхода и оптимизации правил в ipfw. pf так любим пионерами, только за то, что есть optimization aggressive.

а можно мне немного поныть?

Таки настроить хоть какое-то подобие авторизации, не?

Ну потыкайте "Rebuild Poller Cache" да и смотрите себе в tail -F log/cacti.log чем оно давиться при опросе. Повисание поллера я видел только два раза, когда пытался увеличивать частоту опроса меньше чем раз в 5 минут, и когда колбаснулся самопальный скрипт мониторинга температуры опрашиваемый тем же поллером.

Да вроде норм все, а чего было то?

net-snmp пересобрали? Полагаю, что нет. То, что cacti полагает, что оно получит данные в нормальном виде - еще ничего не означает. Каунтеры snmpd перепоняться от этого не перестанут. Просвещайтесь: http://www.net-snmp..../IF-MIB_rewrite

Недокументированная фича: при заходе в модуль "Сети", происходит регенерация всех конфигов dhcp и isc-dhcpd перезапускается уже с новыми конфигами.

То-то смотрю распространенные дырки в графичках У вас банально переполняются каунтеры. Если снимаете по snmp с FreeBSD - следует пересобрать net-snmp с включенной опцией WITH_MFD_REWRITES. Также следует удалить все графички и датасорцы для текущего хоста и пересоздать их как In/Out Bits (64-bit counters). Тупое переключение не помогает.

Ога, давайте угадаю - там где дырки должны были быть цифры больше 140-170Мбит/с?

Да, регистрация пользователя, смена пароля, смена IP, все действия с тарифами и внесения денег - производятся не на прямую в базе а посредством вызовов конфигуратора. Возможно у вас в PHP включен safe_mode либо стоят ограничения на вызовы системных команд при помощи system(), shell_exec(), либо еще возможен включенный magic_qotes. Думаю тот же ефект будет наблюдаться и при переключении baseconf в sgconf. Правда? В любом случае там немного вариантов почему PHP скрипту не дают вызвать чесно собранную команду.

Плохо Ну написано же что сделать. Кстати по этому поводу посмотрите вот тут. Нет, не важно по сути. Но таймзону для php выставьте. Руками то-же пробовали выполнить? Собственно оное просто попадает в shellexec(). А да, может не работать, если в этот момент быть соединенным при помощи других конфигураторов.

Для начала можете попробовать исполнить из консоли, руками следующий код: /usr/sbin/sgconf_xml -s localhost -p 5555 -a xxxx -w xxxxxxx -r '<AddUser><login value="testmeuser" /></AddUser>' Если после этого пользователь добавиться, можете попробовать в api/sgconfxml/handlers.php в строке 67 временно изменить executor($string,false); на executor($string,true); Что-бы глазами посмотреть, что же на самом деле пытается выполняться.

Не, его и не должно быть, для baseconf=sgconfxml вполне достаточно да, оно по 5555 по дефолту работает, 8081 используется для чистого xmlrpc. Сейчас подумаю как отдебужить, что там у вас происходит.

У меня сейчас эпилептический припадок случиться.

Потому, что пользователь stargazer на самом деле не зарегистрировался. Это происходит вызовами родных старгейзеровых конфигураторов. Все остальное, типа адресов, мобилочек, и прочего добавляется уже самим убиллингом напрямую в базу. Либо неверно указаны логин, пароль администратора старгейзера, либо не верен путь к конфигуратору sgconf_xml либо последний вообще не собран. Внимательно смотрите, что у вас нарисовано в config/billing.ini и насколько это соответствует реальности.