Перейти до

sm_root

Маглы
  • Всього повідомлень

    20
  • Приєднався

  • Останній візит

Сообщения додав sm_root

  1. У нас NASов 10 шт., то что обновлять версии выше 44,5 нельзя знаю, точно дело не в этом, да и не обновляли микротики. Биллинг ни к одному из NASов на данный момент не коннектится при ресете.

     

    При нажатии кнопки "расширенная настройка микротика" в логах на НАСах видно, что биллинг успешно залогинелся на микрот, проблема именно в "ресете".

     

    p.s. про кучаген знаю, но сейчас надо понять в чем проблема, чтобы поскорее решить.

  2. Нашел в 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

  3. Появились проблемы с работой биллинга. Перестали работать 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
     

    failed stargazer.jpg

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

    image_2020-10-24_120043.png

  5. Такая же ошибка, как в топик старте. При создании пользователя произошел какой то глюк и один пользователь создался раз 20. По совету из этой темы пробовали удалить 

    http://IP/billing/?module=annihilation&username=175010463

     

    удалилось где то 15 учеток, остальные остались и больше не удаляются.

     

    Как можно от них избавиться? 

     

    Что означает выделение черным цветом? Раньше такого не видел.

     

    image_2020-10-24_110850.png

  6. Получается биллинг все таки "читатель", раз смотрит движение средств по начислением абон.платы, верно?

    Но, разве вам не интересно, что там происходило с юзерами и на что матюкался старгейзер? Нет?

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

  7. Я отключил 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)
     

  8. 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:

     

  9. Отделил СУБД 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 `Текущий ме�..`')

     

    При этом сами значения устанавливаются.

     

    Находил похожие проблемы на форуме у тех, кто обновлял биллинг, но я биллинг не обновлял. 

  10. UPD сам разобрался. Тему оставлять или удалять на рассмотрение модераторов.

    Напишу в чем была проблема, может кому то поможет.

    крашанулась таблица в базе weblogs, с которой и берутся данные для кнопки "подробно". крашануться могла по причинам: сбой в сети, в хдд, в файловой системе, неожиданный ребут.

    Исправление в консоли:

    mysqlcheck -u root -p --auto-repair --all-databases

  11. Перестала работать кнопка "Подробно" у всех абонентов. При нажатии выдает ошибку:

     

    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

  12. Когда не получается, то что делаешь по мануалу, то да, иногда тыкаюсь наугад, тестовая среда ведь на то и тестовая.

     

    Цитата

    для таких тестов очевидно нужно добавить нас с ипишкой локалхоста

     

    Выше я так же и сделал, или вы не то имели ввиду?

    Вот скриншот, что здесь не так?

    1.jpg

  13. Создали сервер доступа 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


     

  14. Преамбула:

    Версия 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


     

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