madf

iptables-dev и libmysql++-dev тут ни к чему.

Вместо string tarifname; tarifname.append(tariffName); и strprintf(&scriptOnConnectParams, "%s \"%s\" \"%s\" \"%f\" \"%d\" \"%s\"\"%s\"", scriptOnDisonnect.c_str(), login.c_str(), inet_ntostring(lastIPForDisconnect).c_str(), (double)cash, id,tarifname.c_str(), dirsStr); проще сделать так: strprintf(&scriptOnConnectParams, "%s \"%s\" \"%s\" \"%f\" \"%d\" \"%s\"\"%s\"", scriptOnDisonnect.c_str(), login.c_str(), inet_ntos

Разве что для файловой базы. У Stargazer'а нет параметра "дата регистрации" как такового.

Только внешними механизмами.

Запрос формирую вот подключая вот эту библиотеку. Если есть варианты попроще, буду рад выслушать. Стандартные функции РНР для работы с XML RPC обьявлены эксперементальными и использовать их не силно хочеться. Ну они хоть и объявлены экспериментальными, но за последние 2 года не менялись. В любом случае оба варианта хороши. А как так получилось что с помощью готового API удалось сформировать некорректный запрос? Ну и хотелось бы пример запроса (хотя, в этом случае, проблема скорее всего в библиотеке libxmlrpc-c).

Некорректно сформировал запрос для метода stargazer.chg_user. Старгазер упал. Чуть позже постараюсь показать сам запрос. Запрос вручную формировал что-ли?! Зачем?! Я не знаю такого языка в котором небыло бы поддержки XML RPC хотя-бы внешними библиотеками.

Да, так и должно быть. Плагин конфигуратора может обрабатывать только одно подключение за раз, по этому если оно уже занято - админка "зависает".

С исходниками Stargazer'а идет библиотека ia.lib - реализация протокола авторизатора на C++. Она используется в консольном авторизаторе sgauth, исходники которого тоже там есть. Еще на сайте есть исходники "классического", виндового авторизатора (для Borland C++): inetaccess.2.61.8.src.rar

Т.е. вручную? Не стоит так делать. Firebird и PostgreSQL использовать стоит.

А как так получилось что у клиента оказался NULL в поле IP? Ну я уже сто раз говорил про стабильность модуля mod_store_mysql и про то что его не стоит использовать. Клиенту можно выставить несколько адресов, разделенных запятой или поставить *. Но в этом случае не будет работать авторизация alwaysOnline. Т.е. обязательно использование InetAccess.

А можно это воспроизвести на отладочной версии, а потом сделать такое: $ cat /var/run/stargazer.pid (запоминаем PID) $ gdb /usr/sbin/stargazer (gdb) attach <pid> (gdb) thread apply all bt (gdb) quit и выхлоп отправить мне на faust@stg.dp.ua (ну или на какой-нибуть patsebin залить и оставить ссылку)?

Увы, отлавливаю. "Будем искать" (с) А можно исправленную версию или патч какой-нибудь? Без проблем: патч А вот тут поподробней, пожалуйста. Ни разу ни у меня ни у товарищей которые пользуют XML-RPC API не удавалось через него уронить Stargazer. Хотелось бы получить рецепт.

Странно, я бы сказал что такое невозможно... Спасибо, исправлено. Да на здоровье

Есть еще одно решение — полная отвязка процедуры выдачи сетевых настроек от мака, и выдача их только лишь на основе Option 82. То есть вне зависимости от мака на порт свитча всегда выдается одно и тоже. Патчи, реализующие такую штуку, обитают на наге. Применима ясное дело только для управляемого доступа. Не надо у меня ничего просить Поиск по нику на launchpad — верный путь обрести и патчи, и готовый деб-пакет. Забыл что ты его на ланчпад выложил Порт на абонента это, конечно, круто, но и не дешево ведь К стати, а зачем патчи? Разве обычной классификации не достаточно?

Т.е. приходит невалидный XML? Я пару раз наблюдал похожее, но тогда оказывались проблемы с сетью. Выло бы интересно посмотреть tcpdump в момент получения неполных данных.

К стати о птичках. Т.е. "перетыкальщиках". Это типа те кто втыкает кабель то в ноут то в комп и проблема в смене MAC? Проблема решена технически. С помощью классификации неизвестные абоны (неизвестные MAC'и) получают адреса и настройки из отдельного пула и при попытке вылезти куда-то в инет попадают на страницу активации оборудования, где им вежливо предлагают ввести свой логин и пароль. Если логин и пароль правильные - MAC попадает в файл лиз и абон, переполучив адрес, продолжает работать. Те кого это не устраивает - покупают роутеры. Ибо нефиг.

Поделюсь своим опытом. В прошлом году, когда я еще работал в провайдере, начальство озадачило наш отдел переводом всей сети (порядка 10к живых абонов) на DHCP + Opton82. Естественно, сразу встала задача подружить как-то DHCP с БД. Рассматривальись 3 варианта: ISC DHCPd, FreeRADIUS и OpenDHCP. ICH DHCPd. С БД не работает принципиально и все просьбы к разработчикам остаются без ответа. FreeRAIDUS. Странная зверушка. Вроде как RADIUS-сервер, но разработчики по неведомому нам желанию их левой пятки прикрутили к нему DHCP (правда, честно написали, что оно экспериментальное и претензии они не прин

По StatWritePeriod пишется только статистика, но не конфиг пользователя. madf, поправь меня, если я не прав? Раньше писалось и то и другое, но потом я от єтого начал активно избавляться чтобі уменьшить количество транзакций в базе. Конфиг меняется не часто, нет смысла его постоянно писать. Так что да, ты совершенно прав.

Внимательно просмотрел stargazer.conf и мануал, ничего не нашел связанного с указанием прав пользователей на каталог /var/stargazer... Это настройки плагина хранилища, они лежат в /etc/stargazer/conf-enabled.d/store_files.conf (если, конечно, этот плагин используется). А он не используется! Эпично Если все данные хранятся в СУБД то /var/stargazer не нужен совсем. Естественно там ничего не меняется. Ну можно просто не выключать Internet в скриптах. Абоненты даже с отрицательным балансом будут иметь доступ.

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

Гм. А в /var/log/stargazer.log что-то есть интересное? Ошибки какие-нибуть? Это сразу после установки таке? Вносились ли правки в конфиги? И какая версия Stargazer'а?

А зачем? "Тяжелые" скрипты?

упс. про команды както профтыкал. буду ждать следующего висяка. количевство процесов поставил 2 может для всех клиентов отключить ведение детальной статистики? тогда нагрузка должна упасть феноменально (пс. мускульная база стабильно в своей директории делает гайковие файли типа мускул001-бин, как_то так, може изза излишней нагрузки)) ... Где 2 поставил? Отключение ведения детальной статистики уменьшит нагрузку на БД, но никак не отразится на "висяках" если они происходят в плагине конфигуратора.

Конфигуратор может "завесить" только сам себя. По крайней мере в 2.407 точно. Авторизатор вообще не может никого завесить. А как по поводу тех команд что я писал выше? По поводу количества процессов. Если ExecutersNum равен 1 или вообще не указан то должно быть ровно 2 процесса: stargazer и stg-exec. В случае если stargazer падает по SIGSEGV то stg-exec остается висеть в процессах и убить его можно только по -9. И еще, то что MySQL обеспечивает работу разных сайтов ровным счетом ничего не значит. Разные задачи, разные нагрузки, разные базы.

При alwaysOnline возможно указать только один IP. Также невозможно указать в качестве IP '*'.