madf

А что указано в настройках в параметре FeeChargeType?

На транке разные чудеса могут твориться, тестить лучше в привязке к версии: -alpha, -beta, -rc1 и т.д. О большинстве проблем в транке я и сам знаю потому что сам их создаю

Авторизатор сдох на транке или на альфе? Авториазтор я сейчас активно ломаю. По идее уже доломал.

Те-же яйца только в профиль. Хотя нет, даже еще сложнее, т.к. прийдется отслеживать перекрытие подсетей у юзеров.

Источники энергии нарушающие закон сохранения энергии - в сад! Т.н. "зеленые" источники энергии - огромные начальные затраты, слабая окупаемость, низкий выход энергии. Из "классических" источников на сегодняшний день единственный приемлимый вариант - АЭС. Дешево (не по начальным затратам, конечно), чисто, наукоемко и много. В перспективе - ядерный синтез. Но "... лучше потратить этак миллиардов надцать Общечеловеческих Денежных Единиц на подготовку к Большому Всемирному Буцанию Мячика, нежели немного больше на никому нахрен не нужные эксперименты с каким то там ITER." Солнечные батареи

Бабло и free mb тоже не пишутся моментально.

На текущем этапе это чертовски сложно. Потребует переписать почти все ядро.

Реальность немного сложнее. Прямой доступ к данным статистики позволит быстрее получить данные, но это будут не актуальные, а устаревшие данные. А так - да, прямой доступ к базе.

XML RPC

# Defines fee charging rules. # 0 - classic rules, allow fee charge even cash is negative; # 1 - disallow fee charge if cash value is negative; # 2 - disallow fee charge if there is not enought cash (cash < fee). # Parameter: optional # Value: 0 - 2 # Default: 0 (classic) # FeeChargeType = 0

А де картинко із збоченнями і комбайнами?

Как и СУБД, не так-ли? Проблема в том что SMUX - пассивное звено. Он не может отследить потерю связи. После регистрации на snmp-сервере он только получает запросы и отдает ответы. По этому я даже затрудняюсь представить себе как отслеживать состояние соединения. В прочем, надо почитать стандарт повнимательнее...

Доступность snmpd решается управлением приоритетами запуска дэмонов при старте сервера. Никого ведь не удивляет что Stargazer не стартует если недоступен сервер БД (хотя этот вопрос активно обсуждается)? Даже если шейпа всего два на тариф - их надо добавить в БД, в ядро системы (передача в OnConnect/OnDisconnect), в плагины conf_sg, conf_rpc и remote, в графический и консольный конфигуратор. И при всем этом такие шейпы мало кого устроят. Полноценная реализация должна уметь привязывать шейпы к направлениям, временным интервалам, порогам, переопределять шейпы для конкретного пользователя, подде

Игнор ни в коем случае. Раз админ указал в конфиге smux, значит он ему нужен. А раз необходимый функционал реализовать невозможно (нет коннекта) то и сервер стартовать не должен. А вот переустановку соединения надо сделать, да. Добавить к тарифу поля шейпера не так просто как кажется на первый взгляд.

Добавил пример конфига

Палево! sensors.h поправил, там действительно надо было #ifdef DEBUG .. #endif Cannot connect - а коннектиться-то есть куда? И порт нестандартный... Вот мой конфиг: <Module smux> Port = 199 Server = 10.0.0.1 </Module> Конфиг на стороне snmpd: smuxpeer .1.3.6.1.4.1.38313 smuxsocket 10.0.0.1 В радиусе я, кажется, ничего не менял.

Я его таки нашел и попробовал Зачот. У нас нашел? Или его уже в Киев возят?

Проще попросить nightfly чтобы он дублировал изменения телефонов и адресов в Stargazer.

Zip (Днепропетровск), если не старше 2 суток с момента разлива.

Вот за это - большое человеческое спасибо

Поправил. Это я когда с "зависаниями" конфигуратора боролся недоглядел. На всякий случай еще раз предупреждаю: в git я коммичу даже неработоспособный код. Так что его можно использовать исключительно "на посмотреть". Если он порушит базу на "боевом" сервере - пеняйте на себя

Будем смотреть. Я, вроде, особо ничего там не ломал...

Как именно не работает?

Не глуши мотор, 2.408 на подходе

Шик в том что он позволяет работать непосредственно с протоколом (XML). Он более функциионален. Позволяет, например, управлять тарифами. С другой стороны, он имеет все те-же недостатки что и sgconf. XML-RPC API по функциональности даже немного круче, и не имеет недостатков sgconf. И в чем шик sgconf_xml перед XML-RPC API я ответить затрудняюсь