Были уже багрепорты. Воспроизводится просто. Удаляем у пользователя тариф, без удаления услуги передачи трафика. Перегружаем ядро и лицезреем verificator.log. Может я не прав и сначало надо всё же удалять услугу передачи трафика, а потом тариф, хотя как-то не логично. Скажите как правильно?Может я чего не понял, но после прочтения
Цитата:
11. исправлена ошибка, в результате которой при удалении сервисной связки не помечались как удаленные записи в таблицах dtagg_iptraffic, dtagg_periodic, dtagg_hotspot и dtagg_telephony, что приводило к некритическому нарушению логической целостности базы данных (mantis id 879, 880);
я думал, что этого быть не должно... Что бы это значило?
Одно из двух: или эти записи остались со старых сборок или где-то что-то при исправлении указанных проблем не учли. Если есть гарантированный способ воспроизведения пишите багрепорт.
UTM5 5.2.1-005
Создай симлинк
Правда теперь другое выскочило
Цитата:
# /usr/local/etc/rc.d/utm5_core.sh start
Starting utm5_core
/libexec/ld-elf.so.1: Shared object "libssl.so.5" not found, required by "utm5_core"
Код: Выделить всё
# ls -l /usr/lib | grep libssl.so.5
lrwxr-xr-x 1 root wheel 20 Dec 8 13:16 libssl.so.5 -> /usr/lib/libssl.so.4
- Lex
- NetUP Team
- Сообщения: 623
- Зарегистрирован: Ср мар 09, 2005 12:12
- Откуда: НетАП
- Контактная информация:
Официальных багрепортов по этой проблемы с момента релиза не было.MoHaX писал(а):Были уже багрепорты. Воспроизводится просто. Удаляем у пользователя тариф, без удаления услуги передачи трафика. Перегружаем ядро и лицезреем verificator.log. Может я не прав и сначало надо всё же удалять услугу передачи трафика, а потом тариф, хотя как-то не логично. Скажите как правильно?
Проверил, действительно, если просто удалять тарифную связку, проблема возникает. Зарегистрировал проблему (mantis id 974), хотя было бы лучше, если бы багрепорты писались не на форуме, а в установленном порядке.
А еще ядру биллинга противопоказаны клиенты, сидящие за NATом, особенно если их много и все натятся в один внешник, у меня в ядре путаются сессии и деньги с карточек улетают не тому, кто активировал. Приходится разруливать руками. Я в прошлом году написал программку, которая определенной последовательностью запросов выбивает одинаковый id сессии, передавая две совершенно разных пары логин/пароль. Отправил ее в NetUP. Там сказали, что проблема не воспроизводится. Зато ее корень воспроизводится. Если ключ сессии формируется из IP адреса клиента и времени начала сессии с точностью до секунды, то если обе сессии будут инициированы в одну и ту же секунду, ключ выйдет одинаковым, и что из этого будет, я уже знаю. И так оно и осталось до версии 5.2.1-003. Мы обновились и по сей день наступаем на эти грабли. Потому кто использует NAT, не преобразующий адреса один в один, имейте это в виду. Как решение пойдет туннель до биллинга либо веб-интерфейс где-нибудь до NAT. Скоро так и сделаю, потому что не дело это.
MoHaX, спасибо, помогло.
При запуске ругается на "Unable to fetch license", но utm5_core запускается
#umt5.cfg
database_charset=latin1
как же запустить радиус?
или я вообще нетуда полез...
При запуске ругается на "Unable to fetch license", но utm5_core запускается
# Starting utm5_core
?Debug : Dec 18 13:39:17 Rehash: Rehash manager started
Notice: Dec 18 13:39:17 ModMap: Sub-Module 'rehash' inserted...
Notice: Dec 18 13:39:17 UTM5 Config: Processing config file: /netup/utm5/utm5.cfg
?Debug : Dec 18 13:39:17 ModMap: Module <rehash> exist
Notice: Dec 18 13:39:17 ModMap: Sub-Module 'config' inserted...
?Debug : Dec 18 13:39:17 ModMap: Module <config> exist
?Debug : Dec 18 13:39:17 ModMap: Module <rehash> exist
Notice: Dec 18 13:39:17 ModMap: Sub-Module 'logger' inserted...
*CRIT : Dec 18 13:39:18 UTM5 DBA: db verificator find critical error(s), see /netup/utm5/log/verificator.log for details
*ALERT : Dec 18 13:39:19 ModMap: Checking license: Unable to fetch license...
*ALERT : Dec 18 13:39:19 ModMap: liburfa-hotspot plugin not loaded ! License not found.
Core fingerprint: 5a3d4504e139f439d4b1843e83588872
License Level: Code[1]
# ps ax | grep utm
18957 p0 S 0:00.00 /bin/sh /netup/utm5/bin/safe_utm5_core start
18959 p0 S< 0:01.90 /netup/utm5/bin/utm5_core
и я могу зайти через админку, там проблем не обнаруживаю.debug.log писал(а):.....
?Debug : Dec 18 14:02:04 BusPeriodic: periodic type discount_flow for 4077
?Debug : Dec 18 14:02:04 BusPeriodic: 2556 events remain
?Debug : Dec 18 14:02:04 BusPeriodic: first event time_t 1198019852
?Debug : Dec 18 14:02:04 BusPeriodic: i am going to wait for 40528 sec...
?Debug : Dec 18 14:02:04 : Start sending email to <root@localhost> using relay <>
?Debug : Dec 18 14:02:04 : Sending email. Data <UTM5 DBA: db verificator find critical error(s), see /netup/utm5/log/verificator.log for details
>
?Debug : Dec 18 14:02:05 : Finish sending email to <root@localhost> using relay <>
#umt5.cfg
database_charset=latin1
как же запустить радиус?

Да, всё так, но было бы хорошо, что бы вообще таких ошибок небыло. Есть подозрение, что именно из-за этого трафик вдруг начинает считаться на пользователя с id 0 (пользователь не определен). Вот как поведёт себя система, когда трафик будет подходить под эту не закрытую сервисную связку, а она в свою очередь не привязана ни к одно из пользователей?MoHaX, сделал предлагаемые изменения
Цитата:
# mysql -uroot UTM5 < /netup/utm5/log/verificator.log
после рестарта utm ошибок больше нет.
MoHaX, не сталкивался, думаю трафик будет попадать в нулевой класс трафика tc_class(0) ... или вообще не выводится.
В поиске несмог найти ничего похожего...
Вобщем возникла проблема на связке mpd4+utm5_radius
utm5-2.1.005 FreeBSD 6.2
Со стороны клиента - выдает ошибку неверного логина-пароля, хотя таковая исключается.
Гдето видел что проблема была в несовместимости кодировок в базе, посему даные аутентификации считывались некоректно, но как проверить...
Кто-то сталкивался с подобным?
В поиске несмог найти ничего похожего...
Вобщем возникла проблема на связке mpd4+utm5_radius
utm5-2.1.005 FreeBSD 6.2
radius.log писал(а):?Debug : Dec 21 16:38:41 AuthServer: User <user_login> connecting
?Debug : Dec 21 16:38:41 AuthServer: Session for sessionid <user_login> not found in <192.168.0.1> cache
?Debug : Dec 21 16:38:41 RADIUS DBA: Info for login <user_login> found. type <1>
?Debug : Dec 21 16:38:41 AuthServer: Auth scheme: CHAP
?Debug : Dec 21 16:38:41 AuthServer: CHAP: Challenge size: 27
?Debug : Dec 21 16:38:41 AuthServer: CHAP: Authorized user <user_login>
Warn : Dec 21 16:38:41 AuthServer: Unable to claim IP: No such file or directory
?Debug : Dec 21 16:38:41 AuthServer: Calling fill radius attributes for NAS. Attr storage size <0>
Notice: Dec 21 16:38:41 AuthServer: Login incorrect <user_login> from NAS <192.168.0.1> CLID <*> Calling-station <000ae450de92>
Notice: Dec 21 16:38:41 AuthServer: Authorization failed for user <user_login>
?Debug : Dec 21 16:38:41 AuthServer: Auth reply: RPacket:
Code: 3; ID: 213
<Vendor: 0; Attr: 18>[21]: 417574686f72697a6174696f6e206661696c65642e
........
конфиг радиуса использую рабочий, также и mpd.conf - рабочий. Если надо могу и их выложить.mpd.log писал(а):
Dec 21 16:39:12 ws3 mpd: [pppoe770] AUTH: Auth-Thread started
Dec 21 16:39:13 ws3 mpd: [pppoe770] AUTH: Trying RADIUS
Dec 21 16:39:13 ws3 mpd: [pppoe770] AUTH: RADIUS returned undefined
Dec 21 16:39:13 ws3 mpd: [pppoe770] AUTH: ran out of backends
Dec 21 16:39:13 ws3 mpd: [pppoe770] AUTH: Auth-Thread finished normally
Dec 21 16:39:13 ws3 mpd: [pppoe770] CHAP: ChapInputFinish: status failed
Dec 21 16:39:13 ws3 mpd: Reply message: Login incorrect
Dec 21 16:39:13 ws3 mpd: [pppoe770] CHAP: sending FAILURE len:15
Dec 21 16:39:13 ws3 mpd: [pppoe770] LCP: authorization failed
Dec 21 16:39:13 ws3 mpd: [pppoe770] LCP: parameter negotiation failed
Dec 21 16:39:13 ws3 mpd: [pppoe770] LCP: state change Opened --> Stopping
Dec 21 16:39:13 ws3 mpd: [pppoe770] AUTH: Cleanup
Dec 21 16:39:13 ws3 mpd: [pppoe770] LCP: SendTerminateReq #64
Dec 21 16:39:13 ws3 mpd: [pppoe770] LCP: LayerDown
Dec 21 16:39:13 ws3 mpd: [pppoe770] LCP: rec'd Terminate Ack #64 (Stopping)
Dec 21 16:39:13 ws3 mpd: [pppoe770] LCP: state change Stopping --> Stopped
Со стороны клиента - выдает ошибку неверного логина-пароля, хотя таковая исключается.
Гдето видел что проблема была в несовместимости кодировок в базе, посему даные аутентификации считывались некоректно, но как проверить...
Кто-то сталкивался с подобным?
-
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
У вас в логе сервер англицским по фоновому пишет, что авторизовал юзверя, но не смог получить IP от ведра биллинговой системы.
Вот это описано в факах. Из-за этого не авторизует. Не помогут ФАКи - обращайтесь к разрабам.
Замечено, радиус нетапа не сильно дружит с multihomed компами.
По крайней мере у меня ошибка эта была.
Посему - радиус на фрях я бы отселил на отдельную машину с единственным интерфейсом. И чтоб даже виртуальные интерфейсы на ней не поднимались.
Код: Выделить всё
Warn : Dec 21 16:38:41 AuthServer: Unable to claim IP: No such file or directory
Замечено, радиус нетапа не сильно дружит с multihomed компами.
По крайней мере у меня ошибка эта была.
Посему - радиус на фрях я бы отселил на отдельную машину с единственным интерфейсом. И чтоб даже виртуальные интерфейсы на ней не поднимались.
Проапгрейдил до 005, и получил неработающий Веб.
причем с банальной ошибкой:
Info : Dec 25 00:15:47 RPCConn: Connection from: 127.0.0.1:46536
Info : Dec 25 00:15:47 RPCConn<apol1@192.168.1.4>: Access granted to <apol1@192.168.1.4> (UID: 11)
Info : Dec 25 00:15:47 RPCConn<apol1@192.168.1.4>: Connection terminated by peer
?Debug : Dec 25 00:15:47 RPCConn<apol1@192.168.1.4>: Session stored for UID 11 and IP 401a8c0
?Debug : Dec 25 00:15:47 RPCConn<apol1@192.168.1.4>: Session closed...
Info : Dec 25 00:15:47 RPCServer@0.0.0.0: Client connecting: 127.0.0.1:46537
Info : Dec 25 00:15:47 RPCConn: Connection from: 127.0.0.1:46537
Notice: Dec 25 00:15:47 RPCConn: Service <@127.0.0.1> is connecting
ERROR : Dec 25 00:15:47 RPCConn: Bad Service username: from <@127.0.0.1>.
Info : Dec 25 00:15:47 RPCConn: Access rejected to <127.0.0.1:46537>
?Debug : Dec 25 00:15:47 RPCConn: Session closed...
----
говорить про SElinux не надо отключен на корню.
до апдейта все пахало на ура.
Веб обновлен так же как и все остальное файло
система RH El5 ssl 98b.
Куда копать?
про права на файло говорить не надо щас поставил все 777
хотя простите до 005 апдейта все пахало то?
почему веб не видити конфига или не шлет своей логин, вот в чем вопрос.
---------
Прошу прощения сам дурак
нашел в чем трабл.
причем с банальной ошибкой:
Info : Dec 25 00:15:47 RPCConn: Connection from: 127.0.0.1:46536
Info : Dec 25 00:15:47 RPCConn<apol1@192.168.1.4>: Access granted to <apol1@192.168.1.4> (UID: 11)
Info : Dec 25 00:15:47 RPCConn<apol1@192.168.1.4>: Connection terminated by peer
?Debug : Dec 25 00:15:47 RPCConn<apol1@192.168.1.4>: Session stored for UID 11 and IP 401a8c0
?Debug : Dec 25 00:15:47 RPCConn<apol1@192.168.1.4>: Session closed...
Info : Dec 25 00:15:47 RPCServer@0.0.0.0: Client connecting: 127.0.0.1:46537
Info : Dec 25 00:15:47 RPCConn: Connection from: 127.0.0.1:46537
Notice: Dec 25 00:15:47 RPCConn: Service <@127.0.0.1> is connecting
ERROR : Dec 25 00:15:47 RPCConn: Bad Service username: from <@127.0.0.1>.
Info : Dec 25 00:15:47 RPCConn: Access rejected to <127.0.0.1:46537>
?Debug : Dec 25 00:15:47 RPCConn: Session closed...
----
говорить про SElinux не надо отключен на корню.
до апдейта все пахало на ура.
Веб обновлен так же как и все остальное файло
система RH El5 ssl 98b.
Куда копать?
про права на файло говорить не надо щас поставил все 777
хотя простите до 005 апдейта все пахало то?

---------
Прошу прощения сам дурак

нашел в чем трабл.