sm_root
Тип контенту
Профили
Форум
Календарь
Сообщения додав sm_root
-
-
У нас NASов 10 шт., то что обновлять версии выше 44,5 нельзя знаю, точно дело не в этом, да и не обновляли микротики. Биллинг ни к одному из NASов на данный момент не коннектится при ресете.
При нажатии кнопки "расширенная настройка микротика" в логах на НАСах видно, что биллинг успешно залогинелся на микрот, проблема именно в "ресете".
p.s. про кучаген знаю, но сейчас надо понять в чем проблема, чтобы поскорее решить.
-
Нашел в stargazer.log последний удачный запуск stargazer
2020-10-24 12:36:38 -- Stg v. 2.409
2020-10-24 12:36:38 -- Message queue created successfully. msgKey=5555 msgID=65536
2020-10-24 12:36:38 -- Timer thread started successfully.
2020-10-24 12:36:39 -- [store_mysql] MYSQL_STORE: Current DB schema version: 1
2020-10-24 12:36:39 -- Storage plugin: mysql_store v.0.67. Loading successfull.
2020-10-24 12:38:24 -- Users started successfully.
2020-10-24 12:38:24 -- Traffcounter started successfully.
2020-10-24 12:38:24 -- Module 'Stg Configurator v. 2.0' started successfully.
2020-10-24 12:38:25 -- Module 'Always Online authorizator v.1.0' started successfully.
2020-10-24 12:38:25 -- Module 'cap_nf v. 0.4' started successfully.
2020-10-24 12:38:25 -- Stg started successfully.
2020-10-24 12:38:25 -- +++++++++++++++++++++++++++++++++++++++++++++
На текущий момент все останавливается на Storage plugin: mysql_store v.0.67. Loading successfull
-
Появились проблемы с работой биллинга. Перестали работать reset, credit, оплаты. Сервер был полностью перезагружен. При загрузке вышло failed to start stargazer (скрин), но при этом оснастка биллинга открывается, какой то функционал работает, какой то нет. Также сами разделы стали долго открываться, т.е. биллинг работает с тормозами.
В процессах он висит, но на killall stargazer не реагирует. Если повторно запустить /usr/sbin/stargazer start /etc/stargazer , то процессов будет вдвое больше. Ошибок при запуске не выдает.
root@uBilling:/usr/home/ubilling # ps -x | grep stargazer | grep -v grep
940 - Is 0:00.08 /usr/sbin/stargazer
941 - I 0:00.00 stargazer: stg-exec (stargazer)Это все что есть в stargazer.log с момента загрузки системы
/var/log/stargazer.log
2020-12-18 10:14:31 -- Stg v. 2.409
2020-12-18 10:14:31 -- Message queue created successfully. msgKey=5555 msgID=65536
2020-12-18 10:14:31 -- Timer thread started successfully.
2020-12-18 10:14:49 -- [store_mysql] MYSQL_STORE: Current DB schema version: 1
2020-12-18 10:14:49 -- Storage plugin: mysql_store v.0.67. Loading successfull.больше ничего туда не пишет, даже если с пользователем проводишь операции (делаешь reset), лог чистый.
Что предшествовало поломки разобраться не могу, сначала пользователи начали жаловаться, что не работает reset, потом что не могут выставить кредиты.
В /var/log/messages c момента загрузки только это, никаких ошибок. 10.1.9.130 это сервер БД для биллинга.
Dec 18 10:14:31 uBilling cron: login_getclass: unknown class 'ubapi'
Dec 18 10:14:32 uBilling kernel: arp: 10.1.9.130 moved from 00:50:56:81:5f:46 to 00:00:0c:9f:f0:09 on em2
Dec 18 10:14:37 uBilling kernel: arp: 10.1.9.130 moved from 00:00:0c:9f:f0:09 to 00:50:56:81:5f:46 on em2
-
Помог ребут сервера. Я так понял какой то скрипт/процесс завис.
- 1
-
-
Такая же ошибка, как в топик старте. При создании пользователя произошел какой то глюк и один пользователь создался раз 20. По совету из этой темы пробовали удалить
http://IP/billing/?module=annihilation&username=175010463
удалилось где то 15 учеток, остальные остались и больше не удаляются.
Как можно от них избавиться?
Что означает выделение черным цветом? Раньше такого не видел.
-
Получается биллинг все таки "читатель", раз смотрит движение средств по начислением абон.платы, верно?
Но, разве вам не интересно, что там происходило с юзерами и на что матюкался старгейзер? Нет?
Был перенос базы и еще некоторые работы с оборудованием, от этого там скопилось много не нужного. По завершению работ логи "стандартны", ничего криминального.
-
Я отключил STRICT_TRANS_TABLES, большая часть ошибок ушла, но некоторые остались.
mysql> SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> SELECT @@GLOBAL.sql_mode;
+------------------------+
| @@GLOBAL.sql_mode |
+------------------------+
| NO_ENGINE_SUBSTITUTION |
+------------------------+
1 row in set (0.00 sec)
-
при добавлении свитча
wrong data input: INSERT INTO switches (id ,modelid ,ip ,desc ,location ,snmp,geo,parentid) VALUES ('', '5', '10.9.90.81', 'MTSIGMON', 'Фуркат', 'dsfsd80sd','', NULL );
-
stargazer.log весил 80МБ, при переносе базы данных на другой сервер лог засрался паразитными записями и разросся до 700МБ. Из за этого тормозит сам биллинг. Можно ли самостоятельно почистить stargazer.log от подобных записей?
2020-05-02 01:17:37 -- Cannot write stat for user 175000342. 2020-05-02 01:17:37 -- Couldn't save user stat:
-
Осталась ошибка при редактировании полей профиля
wrong data input: INSERT INTO `weblogs` (`id`,`date`,`admin`,`ip`,`event`) VALUES(NULL,'2020-05-07 09:08:29','slava','10.1.6.36','CF SET (175006426) TYPE [3] ON `Ибраим Жам�..`')
-
Можно ли удалить и пересоздать stargazer.log? Сильно разросся.
-
Благодарю. 👍
-
Отделил СУБД MySQL на другой сервер Ubuntu Server 18.04.
На старом сервере версия MySQL Ver 14.14 Distrib 5.6.26, for FreeBSD10.2 (amd64) using EditLine wrapper
На новом сервере версия MySQL Ver 14.14 Distrib 5.7.29, for Linux (x86_64) using EditLine wrapper
В целом все прошло без ошибок, биллинг работает. Но иногда выскакивают ошибки, например при переназачении скорости
wrong data input: INSERT INTO userspeeds (id ,login ,speed) VALUES (NULL , '175001912', '');
Или при внесении данных в поля профиля
wrong data input: INSERT INTO `weblogs` (`id`,`date`,`admin`,`ip`,`event`) VALUES(NULL,'2020-05-05 13:40:06','slava','10.1.6.36','CF SET (175001204) TYPE [17] ON `Текущий ме�..`')
При этом сами значения устанавливаются.
Находил похожие проблемы на форуме у тех, кто обновлял биллинг, но я биллинг не обновлял.
-
UPD сам разобрался. Тему оставлять или удалять на рассмотрение модераторов.
Напишу в чем была проблема, может кому то поможет.
крашанулась таблица в базе weblogs, с которой и берутся данные для кнопки "подробно". крашануться могла по причинам: сбой в сети, в хдд, в файловой системе, неожиданный ребут.
Исправление в консоли:
mysqlcheck -u root -p --auto-repair --all-databases
-
Перестала работать кнопка "Подробно" у всех абонентов. При нажатии выдает ошибку:
Warning: mysql_query(): Unable to save result set in /usr/local/www/apache24/data/billing/api/libs/api.mysql.php on line 234
wrong data input: SELECT * from `weblogs` WHERE `event` LIKE "%175002022%" ORDER BY `date` DESCгде 175002022 л/с абонента. Никаких изменений в конфиги не вносилось.
upd.
также появилась проблема, при снятии дампа базы stg, выходит такая ошибка:
mysqldump: Error 1194: Table 'weblogs' is marked as crashed and should be repaired when dumping table `weblogs` at row: 424642
Operation failed with exitcode 3
-
-
Создали сервер доступа NAS, указали сеть 172.16.0.0/24, IP 127.0.0.1 (пробовали также указывать IP микротик nas), Тип сервер доступ radius.
ЦитатаReady to process requests
(0) Received Access-Request Id 169 from 127.0.0.1:53473 to 127.0.0.1:1812 length 71
(0) User-Name = "1"
(0) User-Password = "src9uhrh"
(0) NAS-IP-Address = 127.0.0.1
(0) NAS-Port = 0
(0) Message-Authenticator = 0xf26d8cc546dcfc10984be38ab6ca87ea
(0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(0) authorize {
(0) [preprocess] = ok
(0) [chap] = noop
(0) [mschap] = noop
(0) [digest] = noop
(0) eap: No EAP-Message, not doing EAP
(0) [eap] = noop
(0) sql: EXPAND %{User-Name}
(0) sql: --> 1
(0) sql: SQL-User-Name set to '1'
rlm_sql (sql): Reserved connection (1)
(0) sql: EXPAND SELECT id, username, attribute, value, op FROM mlg_check WHERE username = '%{SQL-User-Name}' ORDER BY id
(0) sql: --> SELECT id, username, attribute, value, op FROM mlg_check WHERE username = '1' ORDER BY id
(0) sql: Executing select query: SELECT id, username, attribute, value, op FROM mlg_check WHERE username = '1' ORDER BY id
(0) sql: EXPAND SELECT username FROM mlg_groupreply WHERE username = '%{SQL-User-Name}'
(0) sql: --> SELECT username FROM mlg_groupreply WHERE username = '1'
(0) sql: Executing select query: SELECT username FROM mlg_groupreply WHERE username = '1'
(0) sql: User not found in any groups
rlm_sql (sql): Released connection (1)
Need 4 more connections to reach 10 spares
rlm_sql (sql): Opening additional connection (6), 1 of 26 pending slots used
rlm_sql_mysql: Starting connect to MySQL server
rlm_sql_mysql: Connected to database 'stg' on Localhost via UNIX socket, server version 5.6.42, protocol version 10
(0)= notfound
(0) [files] = noop
(0) [expiration] = noop
(0) [logintime] = noop
(0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type
(0) pap: WARNING: Authentication will fail unless a "known good" password is available
(0) [pap] = noop
(0) } # authorize = ok
(0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
(0) Failed to authenticate the user
(0) Using Post-Auth-Type Reject
(0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(0) Post-Auth-Type REJECT {
(0) attr_filter.access_reject: EXPAND %{User-Name}
(0) attr_filter.access_reject: --> 1
(0) attr_filter.access_reject: Matched entry DEFAULT at line 11
(0) [attr_filter.access_reject] = updated
(0) } # Post-Auth-Type REJECT = updated
(0) Login incorrect (No Auth-Type found: rejecting the user via Post-Auth-Type = Reject): [1] (from client NAS-test port 0)
(0) Delaying response for 1.000000 seconds
Waking up in 0.3 seconds.
Waking up in 0.6 seconds.
(0) Sending delayed response
(0) Sent Access-Reject Id 169 from 127.0.0.1:1812 to 127.0.0.1:53473 length 20
Waking up in 3.9 seconds.
(0) Cleaning up request packet ID 169 with timestamp +7
Ready to process requests
-
Преамбула:
Версия Ubilling: 1.0.1 rev 7032
В качестве NAS используется Mikrotik.
Развернуто все в тестовой среде на FreeBSD 12.0. Чистая установка ubilling с дистрибутива без NAS. Создано пару пользователей, тариф, сети. Связка ubilling + mikrotik NAS настроена и работает, у клиента интернет есть, скрипты на NAS отрабатывают.
Задача:
Настроить multigen в тестовой среде, обкатать, сделать это все на продактовой среде.
Проблема:
Делаем строго по мануалу http://wiki.ubilling.net.ua/doku.php?id=multigen
Остановились на шаге
ЦитатаКак проверить все ли хорошо?
При запущенном в одном окне
# radiusd -X
делаем в соседнем что-то вроде
# radtest testlogin testpassword 127.0.0.1 0 dec0071981b1
До данного шага никаких ошибок не было, все настраивалась по мануалу верно.
Собственно сама ошибка при выполнении radtest testlogin testpassword 127.0.0.1 0 dec0071981b1:
Цитатаroot@billing-snt:/home/adm # radtest 1 src9uhrh 127.0.0.1 0 0a386107b303 Sent Access-Request Id 111 from 0.0.0.0:56445 to 127.0.0.1:1812 length 71
User-Name = "1"
User-Password = "src9uhrh"
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "src9uhrh"
Sent Access-Request Id 111 from 0.0.0.0:56445 to 127.0.0.1:1812 length 71
User-Name = "1"
User-Password = "src9uhrh"
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "src9uhrh"
Sent Access-Request Id 111 from 0.0.0.0:56445 to 127.0.0.1:1812 length 71
User-Name = "1"
User-Password = "src9uhrh"
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "src9uhrh"
(0) No reply from server for ID 111 socket 3
root@billing-snt:/home/adm #и ошибка при radiusd -X
ЦитатаReady to process requests
Ignoring request to auth address * port 1812 bound to server default from unknown client 127.0.0.1 port 56445 proto udp
Ready to process requests
Ignoring request to auth address * port 1812 bound to server default from unknown client 127.0.0.1 port 56445 proto udp
Ready to process requests
Ignoring request to auth address * port 1812 bound to server default from unknown client 127.0.0.1 port 56445 proto udp
Ready to process requests
uBilling перестал обращаться к NAS’ам MikroTik
в Питання по Stargazer
Опубліковано:
Пробовали добавлять новый. Безрезультатно.