madf

Все можно обойти таким способом. А по теме - никто не запрещает наваять скрипт, который будет выгреб%#ь данные из файлов или из базы и выводить в Web. А можно просто приобрести модули статистики: http://stg.dp.ua/modules.php

В детальной статистике есть список IP-адресов, посещенных пользователем.

Ну, в системе может быть несколько компиляторов. По долгу службы у меня их 5 штук gcc-config позволяет легко переключаться с одного на другой. А вот тут выложены исходники текущего пред-релиза. Правда, кажется, не в первом посте, а несколько дальше по треду. И там еще были к ним важные исправления в коментах. Они гарантировано компилируются на gcc 4-й ветки. PS: релиз, надеюсь, будет сделан до НГ. Сейчас основной тормоз - отсутствие времени

Можете попробовать собрать с gcc 3-й ветки.

После make clean надо было ./build сделать. В этих версиях еще старая система сборки. К стати, а какая версия gcc установлена?

На снятие абонки еще влияет так называемое время "бездействия". Что это? Это часть учетного периода, которую пользователь бездействовал. Например, был "заморожен". Так как Вы добавили пользователя в середине месяца - он проработал только половину учетного периода. По этому с него снялась половина абонплаты. Чтобы с пользователей всегда снималась полная абонплата в конфиге stg необходимо параметр FullFee установить в yes.

Вот в этом месте не совсем понятна логика работы. Если пароль не правильный, то данные не смогут быть дешифрованы, т.е. и вроде проверять нечего... Зачем же тогда проверять пароль еще раз? Я слабо представляю ситуаию, что структура данных будет расскрыта, а пароль не сопадет... Данные будут дешифрованны в любом случае. Простo при неверном пароле они будут дешифрованны неправильно и в структуре будет бред. Чтобы проверить правильность дешифровки достаточно проверить значение какого-нибуть поля. Например, пароля.

STG - патченный? По первому - даже не знаю что и сказать. Первое что приходит в голову - какие-то бока с установкой компилятора. По второму - проверьте права на каталог include. Сделайте make clean и повторите сборку. В конце концов - распакуйте снова чистые исходники и повторите сборку.

По просьбам пользователей, патч: --- user.cpp 2007-12-16 14:58:31.000000000 +0200 +++ user.cpp_ 2007-12-16 14:58:41.000000000 +0200 @@ -1475,8 +1475,11 @@ { //printfd(__FILE__, "CHG_CASH_NOTIFIER\n"); -user->lastCashAddTime = *const_cast<time_t *>(&stgTime); -user->lastCashAdd = newCash - oldCash; +if (newCash > oldCash) + { + user->lastCashAddTime = *const_cast<time_t *>(&stgTime); + user->lastCashAdd = newCash - oldCash; + } } //----------------------------------------------------------------------------- Побочный эффект - теперь любое

Нужно стереть файл deps. В нем система сборки описывает зависимости каждого объектного модуля по заголовочным файлам. Если предыдущая сборка завершилась с ошибкой - в файле может остаться неверная информация. Его просто нужно удалить.

Нет, это понятно. Тут даже, в принципе, есть намеки на то, откуда берется SIGPIPE. Но товарищ говорит о том, что список обновляется после каждого изменения пользователя. А этого не может быть.

Stargazer постоянно тестируется на Gentoo, FreeBSD, Debian и Ubuntu. На компиляторах начиная с версии 2.95 и до 4.1.2 Приведенная выше ошибка лечится make clean (если это последняя сборка), или ручным удалением deps-файлов

Возможно, вы забыли про NAT?

Так, стоп. Проверил. На версии 1.88.9. Никто ничего не обновляет после изменения пользователя. Пока не нажмешь "обновить". Что я делаю не так? Может, у Вас другая версия?

Прокатит для Linux (хотя, правильнее было сделать алиас). Не прокатит для FreeBSD.

Думаю, будет достаточно закоментировать REFRESH_ENABLER в соответствующих методах.

Поставить в сети асько-сервер можно. Но что это даст? на сколько я знаю, он не масштабируется. То есть, это будет локальная аська без доступа в мир. Поставить в сети Jabber-сервер - уже более здравое решение. Он прекрасно масштабируется и пользователи будут иметь выход в мир. Одна только проблемка: модуль ICQ-агента для Jabber еще более глючной, чем большинство клиентов. Как это уже было сделано и работает: инет раздается через VPN, а аська - через прокси. На сколько я знаю - никаких соксов. Обычный сквид. За подробностями обращатесь к -HS-.

Когда Вы прибиваете конфигуратор в процессе работы (приема данных) один конец сокета аварийно отваливается - отсюда и SIGPIPE. В следующей версии конфигуратора параллельные запросы буду блокироваться программно (на уровне мьютексов или еще как - пока не решено). Возможно, NETTRANSACT станет синглтоном.

Зачем просиш? Переписал бы и выложил. Все бы спасибо сказали. прошу т.к помню сколько сам мучался над этим! прошу из за того что отличный модуль простаивает а писать самому мне не дано - безграмотный + просто не умею это делать + могу пропустить важные аспекты проблемы по неопытности Те-же самые аргументы мне приводил -HS-. А потом взял и написал. Если что - сообщество поправит и дополнит.

Зачем просиш? Переписал бы и выложил. Все бы спасибо сказали.

1. Использовать модуль ipq_cap (для VPN это обязательное условие); 2. Проверить правила iptables чтобы они нормально передавали в очередь пакеты; 3. Проверить rules; 4. Проверить ip-адрес пользователя.

Обрабатывать по очереди.

На каждый параметр отдельно. Не думаю что это можно как-то измеить - ведь передается название параметра, старое значение и новое. И не в хаотичном порядке. Просто их порядок не регламентирован. Не думаю что это столь важно.

Исходные коды проекта открыты - дерзайте!

Но ведь на клиентской стороне сокеты блокируемые! Он должен заблокироваться на коннекте до тех пор пока на сервере не освободится сокет.