Alferov

Валиться не должен. По крайней мере я у себя не замечаю проблем. Пока не замечаю )) Зарекаться не буду. Может запросы неверно составляются?

странно как то видеть сначала это: потом рекомендацию почитать стандарт, где все(!!!) написано а потом опять вопрос: Если нет понимания как работает радиус, то зачем вообще заморачиваться этим? В Вашем случае вариантов ровно два. 1. почитать таки RFC. 2. ничего не делать. В любом случае считаю необоснованными любые обиды по причине "отсутствия мануала". Документации в инете полно. Как в первозданном виде, так и переводы RFC. Обижаться надо на себя - за лень! С чего Вы решили, что кто то будет Вам читать лекции по радиусу? Я так понимаю, мы тут биллинг обсуждаем, а не лик

А чего там описывать то? Это ж стандартный радиус. Почитай RFC.

Прошу рассмотреть возможность добавления mschapv2. Без нее плохо. (((

1. Файл /includes/user_menu.php, строка 68 вместо: <a href=\"cards_dealer.php\"> сделать: <a href=\"dealer.php\"> 2. А версию модуля mysql из лога сервера (при запуске) можно посмотреть??? 3. подумаю

http://v-lan.ru/projects/stargazer-2.4/

Чего то не понял я. Это о чем??? Я считаю, что тарифами должен рулить один админ. Если дать на это права многим, то начнется разброд и шатание. Зачем это надо то? Вопросы, касающиеся денег нельзя отдавать на откуп всем подряд. ИМХО. В общем сделаю так. Добавлю в таблицу с тарифами поле, в которое будет писаться: 0 - не показывать в списке 1 - показывать в списке. И без всяких там групп и прочих усложнений. По поводу webmoney. Прикрутить несложно, но... как клиент будет платить, если у него нет доступа в инет???

Точно... от своих прятался. Поправлю. )) 1. Файл script.js, строка 20, scrollbars выставить в YES 2. Согласен. Сам с тем же столкнулся. Осталось решить каким образом это реализовать. а) Либо регулировать группами (проверять к какой группе относится юзер и решать: отдавать или не отдавать тарифы по этому признаку) б) Либо выносить в какой нить файл (можно в config.php) массив тарифов, которые нельзя показывать. 3. Есть такое дело. В следующей версии поправлю. Много всего надо будет править. Наверное сделаю всю БД в KOI8-R. А то как то вразнобой все. СТГ в кои8 пишет. stg-web в

+1

Все правильно. Авторизатор ведь не передает дополнительные направления в connect. Отдает только 10 штук, а должен отдать больше, вот стг и вылетает, не дождавшись.

Вот почему! Я же написал - ЭТО ТОЛЬКО ДЛЯ STG-WEB!!! Причем для уже пропатченного СТГ.

Да.

http://local.com.ua/forum/index.php?showto...=90entry63151

Только для stg-web!!! Модуль store_mysql v0.66 only for stg-web здесь: mod_store_mysql_0.66(Alf)_FOR_STG-WEB.tar.gz

Повторяю для танкистов. Модуль store_mysql НЕ ПРОПАТЧЕН! Распакуй и скомпилируй модуль store_mysql v0.63 из архива с stg-web!!!!! p.s. как слышно меня, прием?!

Это оф.разработка. Я просто тестирую. Думаю стоит подождать релиза. Бету не имеет смысл раздавать. п.с. не альферов, а алферов. Мягкий знак лишний.

Сутки эксплуатации - полет нормальный. Никаких нареканий пока нет. Тьфу 3 раза. ))

я бы назвал это RC Что то при остановке стг в корку вывалился один раз.

FreeBSD 5.4 Mysql - 4.0.26 STG - последняя сборка store_mysql 0.65 (принцип работы: connect-query-answer-disconnect) пользователей - 212 (AlwaysOnline) Час эксплуатации - полет нормальный. Увеличения нагрузки не замечаю. Наблюдаем дальше.

Посмотреть конечно надо исходники, но думаю не будет каких то больших проблем. Наличие константы DIR_NUM подразумевает ее использование во всех функциях, связанных с обработкой направлений. А это значит, что изменении этой константы должно привести к нужному результату. Другое дело, что в коде могут быть косяки. И вполне возможно где то перепутаны DIR_NUM и USERDATA_NUM. По крайней мере один такой случай я уже встречал. Резюме: увеличение DIR_NUM скорее всего приведет к реальному увеличению кол-ва направлений после соответствующих изменений в структуре БД (в части тарифов и статистики пол

Естественно. Все файлы (тарифы, стата юзеров) надо править на предмет добавления еще 5 направлений. Либо менять структуру БД, если используется store_mysql

Еще раз (не помню уже в какой) повторю: читай доки!!! Модуль mysql явно непропатченный стоит.

шансы 50/50 - это как? Оборвется либо не оборвется? ))) Выскажу и свое имхо. Уверен, что дампы - это то самое зло, уйти от которого и было целью при создании модуля. Мы уже проходили все проблемы с файлами, потерей данных и пр. Вы же предлагаете вернуться к этому же. Вариантов решения проблемы на сегодня два. 1. Полностью переделать схему работы с mysql-сервером по принципу "connect - query - answer - disconnect". Здесь возможны варианты. Можно, например, формировать очередь из запросов и выполнять запросы в БД с какой то периодичностью. Однако это тоже чревато потерей данных в случ

Ну веб-сайты как то без allow_persistent работают же. И нет у них проблем с соединением/отсоединением. А запросов там поболе будет, ведь так?

1. в следующей версии доделаю 2. Ясно. В принципе есть подозрение (почти уверенность), что при создании юзера (неважно из веб-морды или из виндового конфигуратора) СТГ не пишет данные в базу по причине обсуждаемого в соседнем топике бага самого модуля. А вот при коннекте этого юзера видимо запрос в БД все-таки прорывается каким то образом. И СТГ в этот момент все и записывает. И начало сессии и данные нового юзера. Можно проверить. Создать пользователя, посмотреть - появились ли его данные, и если нет, попробовать через консоль mysql-сервера снять соединение с STG. В этом случае stg тут ж