Перейти до

stg-2.407-rc1


Рекомендованные сообщения

дистр: CentOS 5 (RH), скрипты использую из rpm из соседнего одноименного топика, запускаю все по средствам SysV-init:

[root@stg db_backups]# ls /etc/rc.d/rc3.d/|egrep "post|star|rad|pptp"
S64postgresql
S87stargazer
S88radiusd
S89pptpd

по сути все по очереди, только на практике получается, как я писал... А какие есть варианты запуска по зависимостям?

База на postgresql - за 5 дней работы - 200Мб (решил писать дет.статистику только пометровки, что бы меньше была).

Кстати, а по какому принципу потом "чистить" таблицу дет.статистики, да и вообще базу, что бы "мусор" не хранить и не сломать базу,

к примеру как у Вас за 6 мес. данные?

Да и после того последнего рестарта, не вставились правила в фаервол у одно юзера "всегда онлайн", сняли/пославили флаг - вставились - глюк?

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 237
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Когда у абонента ip-адрес не совпадает с указанным на сервере - ключик начинает материться с такой скоростью, что закрыть его стандартными средствами не получается. Приходиться убивать его в процессах

собирал с помощью ./build сделал make clean и результат тотже. кроме того аналогичный результат при сборке sgconf, sgauth, rscriptd, convertor ... собрался только rlm_stg   проблемы в системы - мал

2010-11-30 15:58:37 -- Admin 'admin', 127.0.0.1: User 'test': 'credit' parameter changed from '0.000000' to '10000.000000'.

Posted Images

дистр: CentOS 5 (RH), скрипты использую из rpm из соседнего одноименного топика, запускаю все по средствам SysV-init:

[root@stg db_backups]# ls /etc/rc.d/rc3.d/|egrep "post|star|rad|pptp"
S64postgresql
S87stargazer
S88radiusd
S89pptpd

по сути все по очереди, только на практике получается, как я писал... А какие есть варианты запуска по зависимостям?

База на postgresql - за 5 дней работы - 200Мб (решил писать дет.статистику только пометровки, что бы меньше была).

Кстати, а по какому принципу потом "чистить" таблицу дет.статистики, да и вообще базу, что бы "мусор" не хранить и не сломать базу,

к примеру как у Вас за 6 мес. данные?

Да и после того последнего рестарта, не вставились правила в фаервол у одно юзера "всегда онлайн", сняли/пославили флаг - вставились - глюк?

С RedHat/CentOS никогда не работал, по этому по зависимостям не подскажу.

Чистить дет. статистику можно как угодно, она в самом Strargazer'е не используется.

Ссылка на сообщение
Поделиться на других сайтах

По поводу правил: файрвол расположен на одном сервере с биллингом или используется rscriptd?

на одном, разаботало после того, как снял/установил флаг "всегда онлайн"

Ссылка на сообщение
Поделиться на других сайтах

вот такое вот случается иногда по непонятным причинам, если использовать старый конфигуратор (проверялось на 3х ПК).

post-1382-1277187843,9096_thumb.jpg

Проходит само как то (возможно после подключения новым). Глючит с 1.88.9. А вот с 1.91.9 в это время работает нормально.

Ссылка на сообщение
Поделиться на других сайтах

вот такое вот случается иногда по непонятным причинам, если использовать старый конфигуратор (проверялось на 3х ПК).

post-1382-1277187843,9096_thumb.jpg

Проходит само как то (возможно после подключения новым). Глючит с 1.88.9. А вот с 1.91.9 в это время работает нормально.

Это проблема самого конфигуратора.

Ссылка на сообщение
Поделиться на других сайтах

А что то будет решатся в новой версии с консольным конфигуратором? Проблема все та же виснет и в месте с ним ядро проца улетает на 100% (Linux 2.6.26-2-amd64 debian-lanny)

Ссылка на сообщение
Поделиться на других сайтах

А что то будет решатся в новой версии с консольным конфигуратором? Проблема все та же виснет и в месте с ним ядро проца улетает на 100% (Linux 2.6.26-2-amd64 debian-lanny)

Чесно говоря, ни разу такого не наблюдал. Если повторяется регулярно - прошу прислать бектрейсы отладочной сборки в момент проявления бага. Получить их можно так:

$ gdb /path/to/stargazer
(gdb) attach <pid_of_stargazer>
...
(gdb) thread apply all bt
(gdb) quit

И прислать выхлоп мне на мыло: faust@stg.dp.ua. Попробую разобраться.

Ссылка на сообщение
Поделиться на других сайтах

Я из-за этого отказался от рассылки сообщений через КК, хотя...

speedfire87, посмотрите, может это скрипт какой-то висит, который задействует конфигуратор.

Ссылка на сообщение
Поделиться на других сайтах

Чесно говоря, ни разу такого не наблюдал. Если повторяется регулярно - прошу прислать бектрейсы отладочной сборки в момент проявления бага. Получить их можно так:

$ gdb /path/to/stargazer

(gdb) attach <pid_of_stargazer>

...

(gdb) thread apply all bt

(gdb) quit

 

ни понимаю что с эти все делать? как это все запустить, могу лишь сказать то что в пред идущей версии все работало отлично а в новой не работает вообще, к прмеру отправить сообщение пользователю ввожу в консоли он тупо виснет, пере собрал конфнфигуратор из новой версии тоже самое, я думаю не у меня одного такое же .

Ссылка на сообщение
Поделиться на других сайтах

ни понимаю что с эти все делать? как это все запустить, могу лишь сказать то что в пред идущей версии все работало отлично а в новой не работает вообще, к прмеру отправить сообщение пользователю ввожу в консоли он тупо виснет, пере собрал конфнфигуратор из новой версии тоже самое, я думаю не у меня одного такое же .

Такс. Я в этой версии конфигуратор не ломал, только ремонтировал. Проверь что у тебя от старой версии плагинов не осталось. И библиотек. И опиши свою конфигурацию. Патчи никакие на исходники не накладывал?

Ссылка на сообщение
Поделиться на других сайтах

Я в панике вчера весь вечер просидел и толку ноль, сегодня пере собрал кнфигуратор все работает на ура ) madf риспект тебе, спасибо что помогаешь )

Ссылка на сообщение
Поделиться на других сайтах

Еще есть маленький бажок у меня в скрипте onchange

if [ "$param" = "tariff" ]; then

/etc/stargazer/plugins/sgconf/sgconf set -s 127.0.0.1 -p 5555 -a ******* -w ****** -u $login -m 'Уважаемый пользователь, ваш тариф '$oldValue', был изменен на '$newValue

fi

скрипт уведомления если система загрузится полностью сама без перезапусков стг текст не отправляется как только перегружу под рутом стг все работает, проблема именно в русском языке если вкинуть к примеру инглишь все пхнет, если кто в курсе как это можно поменять?

Ссылка на сообщение
Поделиться на других сайтах

Я в панике вчера весь вечер просидел и толку ноль, сегодня пере собрал кнфигуратор все работает на ура ) madf риспект тебе, спасибо что помогаешь )

Я то что, оно само ведь прошло. Жаль, конечно, что не удалось причину зунать.

Ссылка на сообщение
Поделиться на других сайтах

Еще есть маленький бажок у меня в скрипте onchange

if [ "$param" = "tariff" ]; then

/etc/stargazer/plugins/sgconf/sgconf set -s 127.0.0.1 -p 5555 -a ******* -w ****** -u $login -m 'Уважаемый пользователь, ваш тариф '$oldValue', был изменен на '$newValue

fi

скрипт уведомления если система загрузится полностью сама без перезапусков стг текст не отправляется как только перегружу под рутом стг все работает, проблема именно в русском языке если вкинуть к примеру инглишь все пхнет, если кто в курсе как это можно поменять?

sgconf пытается сконвертировать текст из текущей локали. Возможно что общесистемно локаль не установлена. Попробей сделать export LANG=<your_locale> перед вызовом конфигуратора.

Ссылка на сообщение
Поделиться на других сайтах

Вопрос глупый но как это сделать ?

Как-то так:

if [ "$param" = "tariff" ]; then
export LANG=en_US.UTF-8
/etc/stargazer/plugins/sgconf/sgconf set -s 127.0.0.1 -p 5555 -a ******* -w ****** -u $login -m 'Уважаемый пользователь, ваш тариф '$oldValue', был изменен на '$newValue
fi

(ес-сно, вместо en_US.UTF-8 подставить свою локаль).

Ссылка на сообщение
Поделиться на других сайтах

люди хелп:

СТГ беспорядочно сам переставляет userdata# местами,

даже когда его никто не трогает, вот пример:

[root@stg stargazer]# grep eric111 /var/log/stargazer.log
2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata0' parameter changed from '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F' to '256'.
2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata1' parameter changed from '' to '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F'.
2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata8' parameter changed from '10.9.8.12' to ''.
2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata9' parameter changed from '256' to '10.9.8.12'.
2010-06-30 07:59:52 -- Admin 'executor', 127.0.0.1: User 'eric111': 'cash' parameter changed from '10.000000' to '60.000000'. Card: AAE - 84366558 IP: 10.9.8.12
2010-07-01 00:00:01 -- Admin '@stargazer', 0.0.0.0: User 'eric111': 'cash' parameter changed from '60.000000' to '11.000000'. Subscriber fee charge
2010-07-01 00:00:05 -- Admin '@stargazer', 0.0.0.0: User 'eric111': 'freeMb' parameter changed from '0.000000' to '0.000000'. Prepaid traffic
2010-07-01 11:27:34 -- Admin 'virus', 10.9.6.32: User 'eric111': 'userdata0' parameter changed from '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F' to '256'.
2010-07-01 11:27:34 -- Admin 'virus', 10.9.6.32: User 'eric111': 'userdata1' parameter changed from '' to '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F'.
2010-07-01 11:27:34 -- Admin 'virus', 10.9.6.32: User 'eric111': 'userdata8' parameter changed from '10.9.8.12' to ''.
2010-07-01 11:27:34 -- Admin 'virus', 10.9.6.32: User 'eric111': 'userdata9' parameter changed from '256' to '10.9.8.12'.
2010-07-01 11:33:49 -- Admin 'executor', 127.0.0.1: User 'eric111': 'userdata1' parameter changed from '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F' to '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F|'.
[root@stg stargazer]#

заметил, что при конвертировании с файлов - сразу попереставлял местами как видно из лога.

Собственно, 2 извечных классических вопроса: "кто виноват? И что делать?"

(где и что править?)

А то как-то руками неприкольно сидеть и клацать N-ое кол-во раз. Да и в продакшне некошерно выхватывать такое...

Можно конечно заливать дамп с предыдушего "слива" базы, но "истина дороже" : )

Ссылка на сообщение
Поделиться на других сайтах

люди хелп:

СТГ беспорядочно сам переставляет userdata# местами,

даже когда его никто не трогает, вот пример:

[root@stg stargazer]# grep eric111 /var/log/stargazer.log
2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata0' parameter changed from '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F' to '256'.
2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata1' parameter changed from '' to '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F'.
2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata8' parameter changed from '10.9.8.12' to ''.
2010-06-15 14:41:10 -- Admin 'kesha', 10.9.2.2: User 'eric111': 'userdata9' parameter changed from '256' to '10.9.8.12'.
2010-06-30 07:59:52 -- Admin 'executor', 127.0.0.1: User 'eric111': 'cash' parameter changed from '10.000000' to '60.000000'. Card: AAE - 84366558 IP: 10.9.8.12
2010-07-01 00:00:01 -- Admin '@stargazer', 0.0.0.0: User 'eric111': 'cash' parameter changed from '60.000000' to '11.000000'. Subscriber fee charge
2010-07-01 00:00:05 -- Admin '@stargazer', 0.0.0.0: User 'eric111': 'freeMb' parameter changed from '0.000000' to '0.000000'. Prepaid traffic
2010-07-01 11:27:34 -- Admin 'virus', 10.9.6.32: User 'eric111': 'userdata0' parameter changed from '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F' to '256'.
2010-07-01 11:27:34 -- Admin 'virus', 10.9.6.32: User 'eric111': 'userdata1' parameter changed from '' to '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F'.
2010-07-01 11:27:34 -- Admin 'virus', 10.9.6.32: User 'eric111': 'userdata8' parameter changed from '10.9.8.12' to ''.
2010-07-01 11:27:34 -- Admin 'virus', 10.9.6.32: User 'eric111': 'userdata9' parameter changed from '256' to '10.9.8.12'.
2010-07-01 11:33:49 -- Admin 'executor', 127.0.0.1: User 'eric111': 'userdata1' parameter changed from '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F' to '00:22:B0:51:04:1C|00:23:CD:B3:AE:7F|'.
[root@stg stargazer]#

заметил, что при конвертировании с файлов - сразу попереставлял местами как видно из лога.

Собственно, 2 извечных классических вопроса: "кто виноват? И что делать?"

(где и что править?)

А то как-то руками неприкольно сидеть и клацать N-ое кол-во раз. Да и в продакшне некошерно выхватывать такое...

Можно конечно заливать дамп с предыдушего "слива" базы, но "истина дороже" : )

Жаждаю подробностей. Какая версия, какое хранилише используется? Я так понимаю все эти изменения делает какой-то скрипт? Может это он бочинит?

И чем конвертировалось?

Ссылка на сообщение
Поделиться на других сайтах

версия одноименная с темой данного топика,

хранилище postgresql.

Изменения делают потом с конфигуратора, есть конечно php-статистика, но она только читает с базы, изменения напрямую пишет в свои таблицы, те что использует STG изменяем через sgconfig.

os: CentOS 5

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

 

PS если нужно я даже могу как-то мотивировать устранение данного бага, что бы пооперативнее было, а то уже переполз на данный rc в продакшн - страдает качество сервиса...

Ссылка на сообщение
Поделиться на других сайтах

Еще, какая версия конфигуратора использовалась?

Наблюдалась ли эта проблема с конфигуратором предыдущей версии?

Ссылка на сообщение
Поделиться на других сайтах

Что такое "внезапный стоп"?

жесткий ребут.

 

Еще, какая версия конфигуратора использовалась?

Наблюдалась ли эта проблема с конфигуратором предыдущей версии?

гуевый ("виндовый"): 1.91.9

консольный: с пакета "Sgconf version: 1.08.9"

 

меня смущает то, что по словам пользователя eric111 - "сбилось" у него все после 00-00 до этого все работало четко.

А ночью никто не работал конфигуратором и не лазил к сервер -> следовательно что-то не так в логике сервера

Ссылка на сообщение
Поделиться на других сайтах

Что такое "внезапный стоп"?

жесткий ребут.

 

Еще, какая версия конфигуратора использовалась?

Наблюдалась ли эта проблема с конфигуратором предыдущей версии?

гуевый ("виндовый"): 1.91.9

консольный: с пакета "Sgconf version: 1.08.9"

 

меня смущает то, что по словам пользователя eric111 - "сбилось" у него все после 00-00 до этого все работало четко.

А ночью никто не работал конфигуратором и не лазил к сервер -> следовательно что-то не так в логике сервера

С каким именно конфигуратором проявлялась проблема?

С логикой работы сервера все нормально т.к. он не использует эти данные. Совсем.

Может у вас в 00:00 жесткий рестарт сервера по -9?

Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...