Cayz

Стоит в Edge core ES-3510MA, сгорели трансиверы в грозу на 2х коммутаторах.

Севастополь. Небо чернющее, в землю втыкаются разряды. Страшно блин.

Мой "хинт" перестает работать, когда начинается новый месяц . Вот другой фикс в конфигураторе, вроде как 3 месяца без глюков http://depositfiles.com/ru/files/i70bbmh2g, при этом в сервере можно всё вернуть обратно. Ну там на самом деле проблема на стороне плагина. Точнее даже на стороне самого Stargazer'а Может это и проблема, но у меня получилось, что не проблема, а на оборот. Использовал эту фичу с обновлением по другому, теперь любые изменения аккаунтов в таблице обновлятся сразу после изменения, нет необходимости давить кнопку refresh. Очень кстати удобно.

Мой "хинт" перестает работать, когда начинается новый месяц . Вот другой фикс в конфигураторе, вроде как 3 месяца без глюков http://depositfiles.com/ru/files/i70bbmh2g, при этом в сервере можно всё вернуть обратно.

Я тоже с этим столкнулся, там совсем чуть чуть в коде поменять, сработает только при использовании помесячной абонки, для размазанной мне не нужно было вот и не правил. Косяк, когда fullfee=yes и заморозка, до этого снималась абонка с замороженного. в общем тут фикс: файл user.cpp //----------------------------------------------------------------------------- void USER::ProcessDayFee() { STG_LOCKER lock(&mutex, __FILE__, __LINE__); double passiveTimePart = 1.0; if (!settings->GetFullFee()) { passiveTimePart = GetPassiveTimePart(); } else { if (passive) retur

Воспроизводилась ситуация на на сервере 2.406, конфигуратор 1.91.9. debian5-amd64. Воспроизводилась именно на оригинальных исходниках без каких либо изменений. Подключен модуль conf_sg - 1шт(просто я где-то писал, что заюзал несколько, но перед тем как на форум об этом писать затестил на стандартной конфигурации). Сбор трафика осуществлял cap_nf. Конфигуратор один на админском компе. Деньги,предоплаченный и счётчики не обновляются windows-конфигураторе при "быстром обновлении", точнее обновляются только те, которые изменялись конфигуратором уже после того, как в конфигураторе было получен пол

В новом stargazere ускорена работа конфигуратора, а точнее ускорен процесс обновления, за счёт того, что контролируется время последнего изменения отдельных свойств юзера. В процессе обмена сервера и widows-конфигуратора, последний сообщает серверу дату последнего обновления, а сервер в свою очередь передаёт только те данные, которые изменились с момента последнего обновления. За счёт этого ускоряется процесс - его я обозвал "быстрое обновление". Но проблема в том, что те данные которые изменились не конфигуратором, а самим сервером, например снятие денег за трафик или изменение счётчиков траф

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

А оказалось что можно Закомпилил модуль, назвал conf_sg2 Ему свою конфу в сгконф и оно поехало!!! Круто!!! madf, как думаешь, при одновременном использовании двух mod_conf_sg приколов неожиданных никаких не будет?

По скорости всё норм, примерно на запрос и установку параметров 0.17 сек - а этого очень даже достаточно. Даже при нескольких потоках вроде как сносно, пока кто-то работает, осстальные переждут. Но вот WIN32 конфигуратор в это время не вхож в общую струю. Если бы можно было подключить более одного модуля конфигуратора с разными портами к старгейзеру, один для консольного, второй для виндового, было бы супер. А так конечно все идеи сразу отпадают.

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

В общем неосилил. Но не беда приделал rlm_perl+sgconf, в общем то получилось то, чего хотел, даже несколько больше... madf, есть вопрос.... Я вот решил юзером раздать динамические IP, открывая для себя возможности freeradius и rlm_perl, оказалось что реализовать не сложно, при коннекте радиус дёргает sgconf и сообщает новый IP. Не напряжно ли будет для ядра stg, менять IP с такой периодичностью, особенно при старте сервера например, когда все хотят воткнуться в pptp, а их иногда около полтысячи бывает? Просто на реальных зверьках тестить как-то стрёмно.

приеду в понедельник попробую потыкаться, может ещё что нибудь придумаю.

Походу не в тот раздел написал), это к разработке больше относится... В общем ситуация такая... Я не пишу на C и C++, но думаю что читать могу), хотя не факт что правильно, в общем что я пронаблюдал... В модулях таких как chap, pap и возможно в других, но не рылся особо предусмотрены проверки в плане того что пришло в функцию и прочее, например в authorize, в качестве параметра типа REQUEST. В rlm stg проверки небыло, я потыкался, добавил перед обращениям к структуре проверки, если то что надо не пришло, return RLM_MODULE_NOOP; вроде в передаваемом request что-то есть, какие-то данные пере

Debian 5, amd-64. stg-2.406, пробовал freeradius 1.1.3 и 1.1.8 собранные из сырцов radiusd.conf prefix = /usr/local exec_prefix = ${prefix} sysconfdir = ${prefix}/etc localstatedir = ${prefix}/var sbindir = ${exec_prefix}/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct confdir = ${raddbdir} run_dir = ${localstatedir}/run/radiusd log_file = ${logdir}/radius.log libdir = ${exec_prefix}/lib pidfile = ${run_dir}/radiusd.pid #user = nobody #group = nobody max_request_time = 30 delete_blocked_requests = no cleanup_delay = 5 max_requests =