Andrei Опубликовано 29 ноября, 2023 · Жалоба Кто как подчищает старые неактуальные данные из БД ЛанБиллинга? Что можно удалить без последствий? А то при бэкапах базы размер начинает удручать. Если посмотреть размер таблиц, то ТОП выглядит так: SELECT table_name AS "Table Name",ROUND(((data_length + index_length) / 1024), 2) AS "Size in (KBytes)" FROM information_schema.TABLES WHERE table_schema = "radius" ORDER BY (data_length + index_length) DESC; +-----------------------+------------------+ | Table Name | Size in (KBytes) | +-----------------------+------------------+ | auth_hist20191224 | 25232.00 | | auth_hist20200121 | 21136.00 | | vg_blocks | 20048.00 | | auth_hist20200402 | 10240.00 | | auth_hist20200209 | 4048.00 | | auth_hist20230816 | 3600.00 | | auth_hist20230817 | 3536.00 | | auth_hist20230815 | 3536.00 | | auth_hist20230818 | 3376.00 | | auth_hist20230703 | 3296.00 | | auth_hist20231010 | 3040.00 | | auth_hist20201008 | 3040.00 | | auth_hist20231005 | 3024.00 | | auth_hist20231012 | 3008.00 | | auth_hist20231018 | 3008.00 | | auth_hist20230704 | 3008.00 | | auth_hist20231015 | 3008.00 | SELECT table_name AS "Table Name",ROUND(((data_length + index_length) / 1024), 2) AS "Size in (KBytes)" FROM information_schema.TABLES WHERE table_schema = "billing" ORDER BY (data_length + index_length) DESC; +--------------------------------------------+------------------+ | Table Name | Size in (KBytes) | +--------------------------------------------+------------------+ | rentcharge | 832736.00 | | day | 769456.00 | | user00220211215 | 488539.83 | | user00220211216 | 472928.49 | | user00220211214 | 436599.45 | | user00220211217 | 410322.61 | | user00220211213 | 372322.04 | | user00220211229 | 355030.24 | | user00220230802 | 334701.17 | | user00220230718 | 329134.05 | | user00220211208 | 319522.85 | | user00220211210 | 314003.63 | | user00220211209 | 307724.62 | | user00220211206 | 294726.70 | | user00220230711 | 291849.03 | | user00220211207 | 289203.86 | | user00220211228 | 267626.16 | | user00220211220 | 247772.71 | | user00220230823 | 242006.19 | | user00220211221 | 241221.03 | Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Urs_ak Опубликовано 30 ноября, 2023 · Жалоба Я могу про auth_hist* сказать, т.к. спрашивал поддержку о том, что - можно ли их удалять без последствий ? Ответ был, что auth_hist* содержит историю авторизаций и можно удалить до нужного момента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 30 ноября, 2023 · Жалоба 7 часов назад, Urs_ak сказал: auth_hist* содержит историю авторизаций и можно удалить до нужного момента. Т.е. просто DROP TABLE для кучи таблиц? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 30 ноября, 2023 · Жалоба 8 часов назад, Urs_ak сказал: Я могу про auth_hist* сказать, т.к. спрашивал поддержку о том, что - можно ли их удалять без последствий ? Ответ был, что auth_hist* содержит историю авторизаций и можно удалить до нужного момента. Аналогично, только я для staff_history_dynamic ~71,781,789 строк 16.2 ГБ делал: DELETE FROM `staff_history_dynamic` WHERE timefrom < '2017-06-30 00:00:00'; каждый раз с диапазоном в месяц Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Urs_ak Опубликовано 30 ноября, 2023 · Жалоба 2 часа назад, Andrei сказал: Т.е. просто DROP TABLE для кучи таблиц? Да Я вот так сделал по годам: mysql -As -uroot -p -e 'show tables like "auth_hist2019%"' radius > clean_db.txt for i in `cat clean_db.txt`; do echo "drop table $i;" ; done > clean_db_2.txt mysql -As -uroot -p radius < clean_db_2.txt и ничего страшного не произошло Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 3 декабря, 2023 · Жалоба Еще можно старые сессии радиус-агента почистить, например: DELETE FROM `billing.day` WHERE timefrom < '2019-01-01 00:00:00'; И потом надо прогнать mysqlcheck -o ? Иначе ведь размер базы не меняется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 9 января · Жалоба Коллеги, кто на какой версии биллинга остановился? Что из сборок достаточно стабильное? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Urs_ak Опубликовано 9 января · Жалоба Так вроде же типа нельзя останавливаться, иначе потом апгрейды сложнее будут проходить. Кто-то писал тут на форуме давно, что старается каждый год-два обновляться. Но это геморрой на несколько недель, с попыткой проверить не сломалось ли что. Поэтому у нас 2.0.38 пока. Но мы ничего сложного не используем (тарифы/услуги хитрые и т.п.). Могу только отметить, что тут есть подсветка разным цветом пользователь/учетная запись (отключенные так-сяк, заблокированные). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 9 января · Жалоба У нас 2.0 сборка 031. Перед НГ общались с разработчиками и менеджер настоятельно рекомендовала обновиться на последнюю сборку - 046. 34 минуты назад, Urs_ak сказал: иначе потом апгрейды сложнее будут проходить. Мы обновлялись с 16й сборки до 31й, вроде без проблем. Но если что-то правили в ЛК (у нас там интегрированы переходы на внешние платежные системы), то при обновлении это всё похерится. Надо бэкапить ЛК и потом расставлять вручную всё на свои места. Ну и про сторонние интеграции они сразу говорят , что их будете переносить самостоятельно, даже если покупаете у разработчика услугу апгрейда на новую версию "под ключ". У нас такое есть. Ну и немаловажно: у нас 31я сборка стоит на 9м дебиане, а он разработчиками в новых сборках не поддерживается, надо 10 или 11. Так что еще и ОС обновлять надо будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 10 января · Жалоба 19 часов назад, Urs_ak сказал: Так вроде же типа нельзя останавливаться, иначе потом апгрейды сложнее будут проходить. Кто-то писал тут на форуме давно, что старается каждый год-два обновляться. Но это геморрой на несколько недель, с попыткой проверить не сломалось ли что. Поэтому у нас 2.0.38 пока. Да, в курсе, оно понятно, что лучше чаще обновляться, но опыт с этим софтом говорит об обратном, работает - не трогай! Но это не пугает. Благо, есть запасной сервер с ключём где можно протестировать обновление, да и вообще посмотреть новый софт. 18 часов назад, Andrei сказал: У нас 2.0 сборка 031. Перед НГ общались с разработчиками и менеджер настоятельно рекомендовала обновиться на последнюю сборку - 046. Мы обновлялись с 16й сборки до 31й, вроде без проблем. Но если что-то правили в ЛК (у нас там интегрированы переходы на внешние платежные системы), то при обновлении это всё похерится. Надо бэкапить ЛК и потом расставлять вручную всё на свои места. Ну и немаловажно: у нас 31я сборка стоит на 9м дебиане, а он разработчиками в новых сборках не поддерживается, надо 10 или 11. Так что еще и ОС обновлять надо будет. Посмотрим, что там нового наваяли, как оно будет с нашими переделками состыковаться и будем вообще решать, нужно оно или нет. Естественно, ставить под свежую ось. Но есть еще такой опыт как просто перенос базы под новую инсталляцию, под наши условия. Да, надо понимать, что делаешь и для чего, читать нюансы при переходе от версии к версии и вообще, потому как есть изменения в базе и прочее. Но у нас есть уже опыт в этом направлении и таки, это даже лучше и быстрее чем просто обновлять через update.sql, практически без косяков. Короче, все решаемо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 30 января · Жалоба Пренес админку на другой сервер(архив/разархив), но почему то отображаться стала на английском. Всегда четко все переезжало. Думал, может от локали зависит, пробовал менять , не помогает, не пойму. Что может еще повлиять, было у кого такое? Верcия 2.0-14 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 31 января · Жалоба Может быть тут надо переключить язык интерфейса: Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 31 января · Жалоба У меня версия старее, там нет такого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wed Опубликовано 1 февраля · Жалоба Попробуйте кеши везде почистить. где-то в самом биллинге есть кеш ЛК, и в браузере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 1 февраля · Жалоба Да, кеши чистил, не помогло. Изначально решил перенести на 11 Deb. Установлен был РНР 5.6, но пормудохавшись, ничего путного не вышло, циклическая перезагрузка страницы в клиентском разделе + на английском админка. Решил вернуться к 14 убунте ибо изначально на ней работало, все заработало как надо "из коробки", но там устанавливилась РНР 5.5. В итоге вернувшись на свежий дистриб дебиана установил репозиторий с поддержкой рнр 5.5 и все "взлетело" как надо, пока придется на нем посидеть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 13 февраля · Жалоба В 01.02.2024 в 14:27, No_name сказал: В итоге вернувшись на свежий дистриб дебиана установил репозиторий с поддержкой рнр 5.5 и все "взлетело" как надо Тоже вылезла проблема, которая похоже связана с php Внезапно перестал работать вход в личный кабинет. При попытке войти пишет: Exception Failed to download wsdl В логе апача [Tue Feb 13 10:55:31.091377 2024] [:error] [pid 9234] [client 188.130.171.67:10123] exception.Exception Exception: Failed to download wsdl in /usr/share/lanbilling/phpclient/client/extensions/soap/SOAP_RemoteWSDL.php:90 Stack trace: #0 /usr/share/lanbilling/phpclient/client/extensions/soap/SOAP_LBClient.php(18): SOAP_RemoteWSDL->__construct(Object(LB\\HTTP\\Client), Array, Object(SOAPLoggers)) #1 /usr/share/lanbilling/phpclient/client/extensions/LANBilling.php(161): SOAP_LBClient->__construct() #2 /usr/share/lanbilling/phpclient/framework/YiiBase.php(224): LANBilling->__construct() #3 /usr/share/lanbilling/phpclient/framework/base/CModule.php(393): YiiBase::createComponent(Array) #4 /usr/share/lanbilling/phpclient/framework/base/CModule.php(530): CModule->getComponent('lanbilling') #5 /usr/share/lanbilling/phpclient/framework/base/CApplication.php(168): CModule->preloadComponents() #6 /usr/share/lanbilling/phpclient/components/Application.php(11): CApplication->_construct(Array) #7 /usr/share/lanbilling/phpclient/framework/YiiBase.php(132): Application->_construct(Array) #8 /usr/share/lanbilling/phpclient/components/LBStart.php(152): YiiBase::createApplication('Application', Array) #9 /usr/share/lanbilling/phpclient/client/public/api.php(30): LBStart->run(Array) #10 {main}REQUEST_URI=/lbweb-client/--- [Tue Feb 13 10:55:31.091407 2024] [:error] [pid 9234] [client 188.130.171.67:10123] soap Failed to download wsdl (Server responded with status 404) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 13 февраля · Жалоба Странно, что внезапно. Судя по 404 то проблеме в сервере. Кто там что делал? Или с клиента запрос неверный стал уходить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 13 февраля · Жалоба 1 час назад, No_name сказал: Кто там что делал? В том-то и дело, что ничего не делали. Сервак стоит в виртуалке. На хост-системе могли что-то делать, но не в виртуалке. Первое упоминание ошибки "Failed to download wsdl" в логе apache2 встречается 9 февраля: [Fri Feb 09 10:23:18.583694 2024] [:error] [pid 6864] [client 85.140.117.175:35156] soap Failed to download wsdl (Server responded with status 404), referer: http://www.alfa-tele.ru/ [Fri Feb 09 10:23:18.583807 2024] [:error] [pid 6864] [client 85.140.117.175:35156] exception.Exception Exception: Failed to download wsdl in /usr/share/lanbilling/phpclient/client/extensions/soap/SOAP_RemoteWSDL.php:90Stack trace:#0 /usr/share/lanbilling/phpclient/client/extensions/soap/SOAP_LBClient.php(18): SOAP_RemoteWSDL->__construct(Object(LB\\HTTP\\Client), Array, Object(SOAPLoggers))#1 /usr/share/lanbilling/phpclient/client/extensions/LANBilling.php(161): SOAP_LBClient->__construct()#2 /usr/share/lanbilling/phpclient/framework/YiiBase.php(224): LANBilling->__construct()#3 /usr/share/lanbilling/phpclient/framework/base/CModule.php(393): YiiBase::createComponent(Array)#4 /usr/share/lanbilling/phpclient/framework/base/CModule.php(530): CModule->getComponent('lanbilling')#5 /usr/share/lanbilling/phpclient/framework/base/CApplication.php(168): CModule->preloadComponents()#6 /usr/share/lanbilling/phpclient/components/Application.php(11): CApplication->__construct(Array)#7 /usr/share/lanbilling/phpclient/framework/YiiBase.php(132): Application->__construct(Array)#8 /usr/share/lanbilling/phpclient/components/LBStart.php(152): YiiBase::createApp lication('Application', Array)#9 /usr/share/lanbilling/phpclient/client/public/api.php(30): LBStart->run(Array)#10 {main}REQUEST_URI=/lbweb-client/api.php?HTTP_REFERER=http://www.alfa-tele.ru/---, referer: http://www.alfa-tele.ru/ [Fri Feb 09 10:23:18.583825 2024] [:error] [pid 6864] [client 85.140.117.175:35156] soap Failed to download wsdl (Server responded with status 404), referer: http://www.alfa-tele.ru/ В логе ядра за 9 февраля ничего подозрительного нет, но за сутки до этого: 08.02.2024 09:22:26.940640 ERROR LWP910 [src/radius.cpp:2593] Billing error: Lost connection to MySQL server during query 08.02.2024 09:22:26.941088 WARNING LWP917 [src/radius_session.cpp:553] Out-of-order packet with Acct-Delay-Time = 5, difference = 5. Time corrected 08.02.2024 09:22:26.942440 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:27.931604 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:28.931790 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:29.932327 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:30.937753 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:31.941839 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:32.954659 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:33.954663 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:34.955200 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:35.956951 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:36.957794 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:37.957916 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:38.958417 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:39.959161 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:40.959156 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:41.961271 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:42.961479 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:43.963364 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:44.349526 ERROR LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:] 08.02.2024 09:22:44.963919 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:45.352097 ERROR LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:] 08.02.2024 09:22:45.963897 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:46.352705 ERROR LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:] 08.02.2024 09:22:46.968506 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:22:47.373931 ERROR LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:] 08.02.2024 09:22:47.972915 ERROR LWP907 [src/radius.cpp:1899] 0: ... 08.02.2024 09:23:04.130350 ERROR LWP908 [src/radius.cpp:2438] Exception while Flushing: Can't connect to MySQL server on '127.0.0.1' (111) 08.02.2024 09:23:04.486500 ERROR LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:] 08.02.2024 09:23:05.040346 ERROR LWP907 [src/radius.cpp:1899] 0: 08.02.2024 09:23:05.040676 ERROR LWP909 [src/radius.cpp:1087] RoutinesThread error: 0: 08.02.2024 09:23:05.141552 ERROR LWP908 [src/radius.cpp:2438] Exception while Flushing: Can't connect to MySQL server on '127.0.0.1' (111) 08.02.2024 09:23:05.487247 ERROR LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:] 08.02.2024 09:23:06.046518 ERROR LWP909 [src/radius.cpp:1087] RoutinesThread error: 0: 08.02.2024 09:23:06.046636 ERROR LWP907 [src/radius.cpp:1899] 0: ... 08.02.2024 09:28:10.333539 ERROR LWP909 [src/radius.cpp:1087] RoutinesThread error: Can't connect to MySQL server on '127.0.0.1' (111) 08.02.2024 09:28:10.334328 ERROR LWP920 [src/blocks.cpp:199] Exception while Blocker: [0:] 08.02.2024 09:29:17.893283 WARNING LWP917 [src/radius_session.cpp:553] Out-of-order packet with Acct-Delay-Time = 5, difference = 5. Time corrected 08.02.2024 09:35:11.799695 WARNING LWP909 [src/radius.cpp:1137] Session expired. User-Name: 'beleckiy', Session-ID: '0/0/1/4_0000000000060C83' И судя по логам хост-системы в это время 8 февраля проходил rebuild raid-массива. 1 час назад, No_name сказал: Или с клиента запрос неверный стал уходить? А вот тут не понял вопрос. Клиент просто открывает стартовую страницу входа в ЛК. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 13 февраля · Жалоба 1 час назад, Andrei сказал: Exception while Flushing: Can't connect to MySQL server on '127.0.0.1' Что с базой она доступна хотя бы из консоли? 1 час назад, Andrei сказал: А вот тут не понял вопрос. Клиент просто открывает стартовую страницу входа в ЛК Просто у нас клиентски вход и база на разных серверах. Да и что там с логированием в новых версиях, в случаях с варнингом происходит, не знаю. Потому и спросил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 13 февраля · Жалоба 3 часа назад, No_name сказал: Что с базой она доступна хотя бы из консоли? Конечно. И админка работает совершенно нормально. Мы и не знали об этой проблеме с ЛК, пока клиенты не пожаловались на невозможность зайти в ЛК, ЛК, база и админка - всё на одном сервере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 13 февраля · Жалоба В общем похоже, что дело не в ЛанБиллинге, а просто в файлухе: В /var/log/kernel.log: Feb 13 18:38:00 debian9lb kernel: [3383680.583435] EXT4-fs error (device sda1): ext4_iget:4508: inode #3806891: comm LBcore: bad extra_isize (35945 != 256) Feb 13 18:38:00 debian9lb kernel: [3383680.588212] EXT4-fs error (device sda1): ext4_iget:4508: inode #3806891: comm LBcore: bad extra_isize (35945 != 256) и т.д. В dmesg тоже: [Tue Feb 13 20:21:03 2024] EXT4-fs error (device sda1): ext4_iget:4508: inode #3806891: comm LBcore: bad extra_isize (35945 != 256) Надо как-то почекать файловую систему, но проблема в том, что чекать придется бутовый диск виртуалки. А его надо размонтировать чтобы почекать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 13 февраля · Жалоба 7 часов назад, Andrei сказал: И судя по логам хост-системы в это время 8 февраля проходил rebuild raid-массива. А с рейдом то всё окей? Ребилд просто так не начинается, сравните файловую с бекапом, может там уже частично мусор, а не данные. Да прибудет с Вами святой Бекапий! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 13 февраля · Жалоба 1 час назад, bike сказал: А с рейдом то всё окей? Сейчас с рейдом все ОК. Ребилд начался потому что один из дисков почему-то вывалился из рейда, но потом сразу подхватился обратно. smart на нем посмотрели - все в норме. Грузанулись с live-iso, почекали файловую систему, сказано было "все ОК, починилось", виртуалка стартовала, база данных на месте, но личный кабинет не работает с теми же симптомами. Завтра спросим саппорт - может какие бинарники надо из бэкапа достать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 14 февраля · Жалоба решение: # смотрим установленные пакеты lb dpkg -l | grep lb # проверка checksum в /var/lib/dpkg/info ls -l /var/lib/dpkg/info/lb* sudo apt install debsums sudo debsums lbcore --changed #... показала, что /usr/local/billing/api3.wsdl missing # так же можно проверить и все пакеты lb: sudo debsums --change lbweb-client lbarcd lbcore lbweb-admin lbweb-common lbucd # Итого, если проверять всё, то список измененных или отстутствующих файлов выглядит так: sudo debsums --changed debsums: missing file /etc/billing.conf.LBarcd.sample (from lbarcd package) debsums: missing file /usr/local/billing/LICENSES (from lbcore package) debsums: missing file /usr/local/billing/api3.wsdl (from lbcore package) /usr/local/billing/lib/python3.6/lib/python3.6/site-packages/pip/_vendor/certifi/cacert.pem /usr/local/billing/lib/python3.6/lib/python3.6/site-packages/requests/cacert.pem /usr/local/billing/lib/python3.6/lib/python3.6/site-packages/requests/certs.py /usr/local/billing/mysql/update_pre.sql debsums: missing file /etc/billing.conf.LBinet.sample (from lbinet package) debsums: missing file /etc/billing.conf.LBircd.sample (from lbircd package) debsums: missing file /etc/billing.conf.LBphone.sample (from lbphone package) debsums: missing file /etc/billing.conf.LBucd.sample (from lbucd package) /usr/share/lanbilling/phpclient/admin/public/.htaccess /usr/share/lanbilling/phpclient/client/components/payment/ckassa/Payment_CKassa_Pay.php /usr/share/lanbilling/phpclient/client/config/settings.php /usr/share/lanbilling/phpclient/client/controllers/PaymentController.php /usr/share/lanbilling/phpclient/client/views/menu/config.php /usr/share/lanbilling/phpclient/client/views/payment/form.php /usr/share/lanbilling/phpclient/client/views/payment/promised/form.php /usr/share/lanbilling/phpclient/client/views/site/login.php Восстановили из дистрибутива файл /usr/local/billing/api3.wsdl и личный кабинет заработал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 14 февраля · Жалоба Заодно и https сделайте на ваш клиентский раздел раз он в интернет смотрит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...