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) return; } double f = tariff->GetFee() * passiveTimePart; if (f == 0.0) return; double c = cash; printfd(__FILE__, "login: %8s Fee=%f PassiveTimePart=%f fee=%f\n", login.c_str(), tariff->GetFee(), GetPassiveTimePart(), f); property.cash.Set(c - f, sysAdmin, login, store, "Subscriber fee charge"); ResetPassiveTime(); } //-----------------------------------------------------------------------------

Воспроизводилась ситуация на на сервере 2.406, конфигуратор 1.91.9. debian5-amd64. Воспроизводилась именно на оригинальных исходниках без каких либо изменений. Подключен модуль conf_sg - 1шт(просто я где-то писал, что заюзал несколько, но перед тем как на форум об этом писать затестил на стандартной конфигурации). Сбор трафика осуществлял cap_nf. Конфигуратор один на админском компе. Деньги,предоплаченный и счётчики не обновляются windows-конфигураторе при "быстром обновлении", точнее обновляются только те, которые изменялись конфигуратором уже после того, как в конфигураторе было получен полный список пользователей. IsInetable() - я использовал именно для того, сервер посылал в ответе баланс и предоплаченный трафик только для юзеров, у которых оно может изменяться по причине расходования трафика, а проверку на время последнего изменения выпилил. По поводу конфигуратора, в запросе на обновление он посылает результат выполнения GetLastUserUpdateTime(); Исходя из названия я и предположил что это именно дата последнего обновления, а не обращения, а в глубину не лазил. p.s. Раз уж пришлось лезть в исходники конфигуратора, немного оптимизировал процесс приёма данных. При 1727 юзерах, удалось сократить время "полного" обновления где-то на 25%(с 12 секунд до 9). Вроде как не много, но если кому надо вот код (у себя тестил, багов вроде нет, но я полностью ручаться не могу) NetUnit.cpp: int NETTRANSACT::RxDataAnswer() { int n = 0; int ret; char bufferS[1024]; char buffer[8]; answerList.clear(); EnDecryptInit(password, strlen(password)); while (1) { ret = recv(outerSocket, bufferS, 1024, 0); if (ret <= 0) { closesocket(outerSocket); strcpy(errorMsg, RECV_DATA_ANSWER_ERROR); return st_recv_fail; } int k=0; while (k<=(ret-8)) { Decrypt(buffer, &(bufferS[k])); SetProgressBar(0); for (int j = 0; j < 8; j++) { if (buffer[j] == 0) { for (int l=j;l<8;l++) buffer[l]=0; answerList.push_back(buffer); // Конец посылки if (RxCallBack) RxCallBack(&answerList); SetProgressBar(1); return st_ok; } } answerList.push_back(buffer); k+=8; } } } //---------------------------------------------------------------------------

В новом stargazere ускорена работа конфигуратора, а точнее ускорен процесс обновления, за счёт того, что контролируется время последнего изменения отдельных свойств юзера. В процессе обмена сервера и widows-конфигуратора, последний сообщает серверу дату последнего обновления, а сервер в свою очередь передаёт только те данные, которые изменились с момента последнего обновления. За счёт этого ускоряется процесс - его я обозвал "быстрое обновление". Но проблема в том, что те данные которые изменились не конфигуратором, а самим сервером, например снятие денег за трафик или изменение счётчиков трафика, не попадают под эту струю и не передаются. И посмотреть сколько у кого денег или предоплаченного и т.п. не выходит, т.к. данные старые. Если очистить таблицу в конфигураторе, то он обновит все данные - это я и назвал "полным обновлением" и пришлось кнопочку вывести в перёд, для удобного пользования. Сервер я тоже поковырял, сделал, чтобы деньги и предоплаченный трафик для активных (IsInetable())пользователей обновлялся не зависимо от даты последнего изменения, теперь всё и быстро и цифры правильные. p.s. я с новым сервером несколько часов парился пытаясь понять почему cap_nf не считает трафик, хотя netflow на порту есть, перерыл кучу всего, а проблемы на самом деле не оказалось просто так был задуман процесс обновления. в parser.cpp (строка в районе 401) if (u->property.cash.ModificationTime() > lastUserUpdateTime) поменял на if (u->IsInetable()) и то же самое для freeMb

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

А оказалось что можно Закомпилил модуль, назвал 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 что-то есть, какие-то данные передаются, но не все, некоторые поля просто NULL. Вот когда они NULL и к ним идёт обращение(обращение к членам, ссылка на которые NULL, думаю правильно выразился) - и получается segfault. По крайней мере при таком варианте через authorize пролетает без вопросов возвращает noop, и debug об этом пишет. При вызове radtest, та же ситуация повторилась в post-auth, тоже проверку добавил, но от этого не легче - ничего всё равно не работает так как ожидается, зато нет segfault-ов. Мне думается, что раз функции вызываются и работают, то скорее всего дело не совсем в разрядности системы... хотя хз... Сейчас у меня это добро находиться на отдельном тестовом компе (debian amd-64), если есть возможность и желание посмотреть и изучить ситуацию, то дам на неё ssh доступ. Особенно буду благодарен и рад, если проблема решится, так как мои 4,5-летние ВПН-костыли морально устарели, задолбали и оч. хочется их заменгить на нормальную auth систему. спасибо.

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 = 1024 #bind_address = * #port = 0 listen { ipaddr = * port = 0 type = auth } listen { ipaddr = * port = 0 type = acct } hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions = yes log_stripped_names = no log_auth = no log_auth_badpass = no log_auth_goodpass = no usercollide = no lower_user = no lower_pass = no nospace_user = no nospace_pass = no security { max_attributes = 200 reject_delay = 1 status_server = no } client 127.0.0.1 { secret = 123456 shortname = localhost } thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { ### STG stg{ local_port = 6667 server = localhost port = 6666 password = 123456 } pap { encryption_scheme = crypt } chap { authtype = CHAP } mschap { } } # Instantiation instantiate { stg } authorize { stg chap mschap } # Authentication. authenticate { stg Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } } accounting { stg } session { } post-auth { stg } При попытке подключения VPN radiusd в лог пишет такое: Wed Oct 7 18:57:58 2009 : Error: Discarding duplicate request from client localhost:41179 - ID: 66 due to unfinished request 0 Если слушать tcpdump-ом localhost, то видно, что radiusclient обращается к freeradius, но на порту 6666 тихо, rlm_stg не хочет разговаривать с stg сервером. Если запустить radiusd -X, то radius# radiusd -x Starting - reading configuration files ... Using deprecated naslist file. Support for this will go away soon. rlm_stg: stg_init() Module: Loaded stg rlm_stg: stg_instantiate() Module: Instantiated stg (stg) Module: Loaded PAP Module: Instantiated pap (pap) Module: Loaded CHAP Module: Instantiated chap (chap) Module: Loaded MS-CHAP Module: Instantiated mschap (mschap) Initializing the thread pool... Listening on authentication *:1812 Listening on accounting *:1813 Ready to process requests. ,но но только стоит попытаться подключить VPN получается так: Initializing the thread pool... Listening on authentication *:1812 Listening on accounting *:1813 Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1:41321, id=70, length=63 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "test" Calling-Station-Id = "10.92.170.8" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 rlm_stg: stg_authorize() Ошибка сегментирования Подскажите плиз как заставить его работать, на какой версии freeradius должно рабоать, на какой системе тестировалось и работало? спасибо