madf

а в исходниках всё ещё ждём Допиливаю rc3

Менять железо, очевидно.

А чего ему от сторма паниковать-то? Тормозить - да, может. Но в панику ударяться...

Там очень мало информации. Надо подцепться к этой машинке по COM-порту и смотреть что он в эту консоль напишет в момент возникновения проблемы. 90% что проблема в железе.

Вот. Я тоже думаю, что должнжо же быть что-то предусмотрено. А какие штатные средства? Думаю что вот эти: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html Клиентская библиотека MySQL предоставляет C API, а не C++, поэтому я не знаю, как его можно написать "совсем на C++". std::string, как я заметил, там используется. Ну во первых есть mysql++ (я когда-то давно планировал ее использовать для написания этого плагина), а во вторых... Поменьше использовать указателей и строк типа char *. В общем, пиши как знаешь, а я если что помогу. Согласен. Давай самую последнюю. ... Итого, резюмирую текущий план работ: Нормальный реконнект (решит проблемы с падениями) "Прочный" (robust) код (предсказуемая реакция на ошибки) НФ-3 для схемы БД (+ переход на InnoDB и транзакции) prepared statements автоматическое (или автоматизированное) обновление схемы БД Структуру берешь из rc2 (00-base-00.postgresql.sql), накатываешь на нее первый апдейт (00-alter-01.postgresql.sql - лежит там-же) и второй (01-alter-02.postgresql.sql - во вложении). Это, правда, для postgresql но отличий не так много. Так-же во вложении файлик stg-db-structure.sql - это дамп сруктуры одним файлом. Но т.к. это дамп - читать его несколько сложнее чем рукописный. В pdf-нике с документацией есть ERD для Firebird и пояснения ко всем таблицам. Там структура более старая, но похожа на то что есть. Чуть позже выложу ERD в формате dia для текущей структуры. К файликам добавил расширение txt, а то не давало загрузить. 01-alter-02.postgresql.sql.txt stg-db-structure.sql.txt

Я думаю это скорее вопрос по LVS чем по MySQL. Я про LVS только читал, но думаю что возможно оставить на каждом узле статически сконфигурированную "серую" подсеть как раз для таких нужд. Будет. Когда - не знаю, но будет.

У нас как-то 3 дня работало без БД пока я этого не заметил. И ничего, сильно не натекло Чтоб не текло можно хранить в бинарном файлике данные при достижении порога записей/обьема. У нас БД хранится в памяти полностью, и пишутся журналы. Упала база - подымаем дампы, потом журналы и погнали. Правда у нас немного другого класса биллинг, но думаю писать журналы работы в файлик который потом подымать при реконнекте в случае если он есть - вполне реализуемо. А тем более если это биллинг - ни одна запись не должна потеряться. Соответственно - это мастхев. Да, как вариант это возможно, но не думаю что целесообразно. 3 дня лежачей БД - это крайний случай, обычно это обнаружевается раньше и быстро исправляется. И то даже в этом случае все нормально в памяти уместилось.

У нас как-то 3 дня работало без БД пока я этого не заметил. И ничего, сильно не натекло

Простите, а зачем изобретать "очередной велосипед"? Не проще допилить уже существующий модуль к стандартному радиусу? А все частный задачи (типа с номером интрефейса) делать внешними скриптами при коннекте клиента. Связка stg-pptpd позволяет намного больше чем связка stg-freeradius-pptpd. Двухсторонний обмен, все-таки.

тобишь тихонько повиснуть в надежде что мускуль перестанет огорчатся и вернется? а данные в это время он куда должен девать? В памяти хранить. Он сейчас так и делает, просто для Firebird нет реконнекта, а для MySQL он криво сделан и часто тупо падает.

Да, так и есть. Недосмотрел.

Старожилы форума знают что я постоянно ворчу на MySQL

А вы попробуйте бенчмаркнуть выборку по одной табличке где скажем 50М записей или по табличке где 500к - думаю разницу очень хорошо прочувствуете =) Размазывание данных разной степени используемости, по разным табличкам - неплохой перфоменс ход, и называется нормализацией. Хотя детальная статистика которая там пишется черти-как и у 99.99% нормальных людей - отключена, она в этом модуле далеко не самая глобальная проблема. Не "нормализацией" а "секционированием". Т.к. по сути это денормализация. Вместо того чтобы пороть такую чушь, просто почитайте для начала сами о лицензировании/двойном лицензировании mysql. Prepared Statements тут не будут иметь особого эффекта. Разве что при записи детальной статистики и данных о трафике - там идет пачка однотипных запросов. Я по этому поводу думал, в будущем, пересмотреть подходы к работе с БД. Все-таки изначально все ориентировалось на работу с файлами.

На сколько я помню, так было раньше. Потом MySQL стал нормальным GPL. Правда, в виду покупки Oracle'ом, я бы поостерегся.

Я, как постоянный пользователь этого модуля, знакомый с C, C++ и MySQL, мог бы взяться за его поддержку. В этой теме я бы хотел услышать от пользователей, что хотелось бы видеть нового и какие ошибки хотелось бы поправить. То, что бросилось в глаза мне, когда я читал код: Не используются "prepared statements" Результаты запросов преобразовывются из строки Нет механизма автоматической конвертации схемы БД из предыдущих версий Отдельно хотелось бы обсудить таблицы detailstat_MM_YYYY и logs_MM_YYYY, которые же нифига не вписываются в 3-НФ?! Попробуй потом их проанализировать одним SQL запросом. Или всем пофик?. Я догадываюсь, что сделано это было, видимо, с целью увеличения производительности, поскольку таблицы эти довольно тяжелые. Но кто-нибудь в действительно проверял, насколько это быстрее работает, чем одна большая таблица? В конце концов "эффективно масштабироваться" - забота СУБД. 1. Большинство падений в модуле вызвано тем что не происходит проверка кода возврата функций. 2. Страшная система реконнектов: фактически, при каждом запросе соединение с базой устанавливается заново. 3. Структура БД, кажется, даже НФ1 не соответствует (ее просто скопировали с файлового модуля). 4. detail_stats_MM_YYYY - это такое "ручное секционирование", закат Солнца вручную. Есть более правильные штатные средства секционирования. 5. Модуль написан в большей степени на C чем на C++. Вот от этих пяти пунктов хотелось бы избавиться. Предлагаю придерживаться той структуры БД которая используется в mod_store_firebird и mod_store_postgresql. В PostgreSQL более "свежая" структура. Могу дать даже еще более свежую, к оторой я наконец-то решил нормально проблему хранения текущих данных о трафике и помесячных (скорее всего я пока не буду включать ее в rc3 и релиз, но у меня на работе она успешно работает).

Тогда схема такая: на одном из компов настраивается маршрутизация и устанавливается InetAccess. Остальные ходят через него без авторизатора. Получается что все компы будут работать под одним аккаунтом.

Версия Stg v. 2.407-rc2. Вывод отправил вам на почту. По поводу мониторов. На рабочем сервере стг начал не запускатся при старте, а запускался только вручную, причем не всегда. В итоге собрал дебаг версию и запустил. В выводе что-то говорилось о мониторах и стг вис. После удаления файлов мониторов запускался нормально. Версия STG на которой это происходило - кажется 2.407-rc1. В итоге вернулся обратно на стабильную 2.406. TO Alexey Osipov: Надеюсь на вашу помощь, может помогу чам смогу, обращайтесь. На почту ответил. Проблема в MySQL. По поводу файлов мониторинга - проблема явно была в чем-то другом. Мониторинг никак не может блокировать запуск.

Почему об этом не написано в README, на сайте или ещё в каком-нибудь очевидном месте? Возможно, я займусь. http://madf.dyndns.org/trac/projects/stg лежит. Не пора ли на внешний хостинг? Если займешься - отлично. Тут уже один форумчанин пытался что-то сделать с ним. den68, если не ошибаюсь. А то я постоянно колебаюсь: оставить модуль или выкинуть его. Да, лежал. Провайдер в последнее время что-то шалит постоянно. Про хостинг кода давно думаю, но из известных мне ни один меня не устраивает. SourceForge вообще не рассматриваю, он за последние лет 5 становился все хуже и хуже. Гуглокод не дружит с Git. Gitorius какой-то непонятный. С GitHub вообще толком не работал.

В старой версии такого не было с этим пользователем. Еще в старой версии стг иногда не запускался. Решаю проблему удалением мониторов. И еще один баг в конфигураторе: Если в пароле присутствует '\' он не сохраняется в базу. Не копал, может есть инъекция. Конфигурация: Linux ubuntu 2.6.32-21-generic mysql Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (i486) using readline 6.1 Какая конкретно версия Stargazer'а? Что там с незапуском и какое отношение к запуску имеют файлы мониторинга? По поводу \' - я давно уже говорю о том что плагин для MySQL использовать не рекомендуется. Написан он сторонними разработчиками и плохо. Поддерживать его толком некому. По падению: запустите, пожалуйста, stargazer из-под gdb: $ gdb /usr/sbin/stargazer ... (gdb) r Потом воспроизведите падение и сделайте следующее: (gdb) thread apply all bt Вывод отпишите сюда или мне на почту: faust@stg.dp.ua

Если кратко - нет. Но возможны варианты. Про роутер уже озвучили. Можно сделать маршрутизацию на одном из этих компьютеров.

done. То интернета небыло дома, то меня, но сегодня пару минут назад закоммитил. В git уже есть.

похоже на то только чуть по другому - в СТГ пользователь не авторизирован, просто не отрабатывает скрипт OnDisconnect О таких проблемах слышу впервые. Может ошибка в скрипте?

Сделал установку и получение creditExpire по -E в sgconf. Правда, дома пропал инет, и в git еще не внес. Отправил почтой. Часа через полтора-два, как доеду домой, внесу $ LD_LIBRARY_PATH=../../lib ./sgconf Sgconf version: 1.08.9 ... To set credit expire use: sgconf set -s <server> -p <port> -a <admin> -w <admin_pass> -u <user> -E <credit_expire_date> To get credit expire use: sgconf get -s <server> -p <port> -a <admin> -w <admin_pass> -u <user> -E ... $ LD_LIBRARY_PATH=../../lib ./sgconf set -s 127.0.0.1 -p 5555 -a admin -w 123456 -u test -E '2011-03-05' Ok $ grep Expire /var/stargazer/users/test/conf CreditExpire=1299283200 $ LD_LIBRARY_PATH=../../lib ./sgconf get -s 127.0.0.1 -p 5555 -a admin -w 123456 -u test -E creditExpire=2011-03-05 Ok

Да, известная штука. Планируем использовать ее вместе с зераклированием трафика после перевода NAS'ов на L3-свитчи. Я даже код этой софтинки глядел

Вообще говоря, пару раз наблюдал странный баг: если авторизованному абоненту сменить IP то он иногда так и остается авторизованным навсегда. Но до причин пока не докопался. Такого плана проблемы?