Было похожее обсуждение - viewtopic.php?t=1255&highlight=mysqldumpdalex писал(а):да уж. после обновления куча юзеров (без применения улетела в тартарары). так как я ступил и сделал дамп то пришлось еще пару часов ждать его восстановления.
В результате вопрос - как правильнее бекапить восстанавливать базу InnoDB? или может с какими ключами надо играться?
новый билд: 5.1.10-015
обычно представители фирмы на такие жалобы отвечают ( мне лично говорили так пару раз) , что "сначала надо тестировать свежий билд на тестовом серваке"SergKz писал(а):три часа субботнего времени UTM'у под хвост...
а теперь ещё из бэкапа базу восстанавливать чтобы откатиться на 014
ещё пару часов...
мрак какой-то
уфф...
-
shoorickello
- Сообщения: 134
- Зарегистрирован: Ср июн 29, 2005 13:08
Действительно, может быть, "для всех" биллинг развивать не стоит, а только фиксить баги? И развивать только по индивидуальным заказам. Бред какой-то.
Судя по всему, именно это сейчас и наблюдается. Хотя, нет, даже баги не фиксятся - это я про запросы типа "... OR OR OR OR OR OR ..." для выборки правил файрволла. Уже больше полугода об этом говорю, а воз и ныне там. И господа из NetUP старательно игнорируют, либо отписками (советуют прислать базу и т.п., хотя я это делал уже не раз), либо предложением обратиться в поддержку, которая мне не нужна по той простой причине, что функционал, используемый мной, вполне штатный и всё сделано строго по документации.
Судя по всему, именно это сейчас и наблюдается. Хотя, нет, даже баги не фиксятся - это я про запросы типа "... OR OR OR OR OR OR ..." для выборки правил файрволла. Уже больше полугода об этом говорю, а воз и ныне там. И господа из NetUP старательно игнорируют, либо отписками (советуют прислать базу и т.п., хотя я это делал уже не раз), либо предложением обратиться в поддержку, которая мне не нужна по той простой причине, что функционал, используемый мной, вполне штатный и всё сделано строго по документации.
Проверили на последнем билде - создали абонента с двумя тарифами. Включили интернет - в базу ушел правильный запрос:shoorickello писал(а):Действительно, может быть, "для всех" биллинг развивать не стоит, а только фиксить баги? И развивать только по индивидуальным заказам. Бред какой-то.
Судя по всему, именно это сейчас и наблюдается. Хотя, нет, даже баги не фиксятся - это я про запросы типа "... OR OR OR OR OR OR ..." для выборки правил файрволла. Уже больше полугода об этом говорю, а воз и ныне там. И господа из NetUP старательно игнорируют, либо отписками (советуют прислать базу и т.п., хотя я это делал уже не раз), либо предложением обратиться в поддержку, которая мне не нужна по той простой причине, что функционал, используемый мной, вполне штатный и всё сделано строго по документации.
SELECT rule_on,rule_off,router_id FROM firewall_rules WHERE is_deleted='0' AND ((uid='27096' AND uid!='0') OR is_for_all='1' OR (( tariff_id='5' OR tariff_id='6') AND tariff_id!='0'))
видимо у вас есть какая-то особенность в свойствах пользователя. Опишите пожалуйста пошагово как воспроизвести проблему.
-
shoorickello
- Сообщения: 134
- Зарегистрирован: Ср июн 29, 2005 13:08
aospan:
Я точно не знаю, в чём проблема была, но мне кажется, что связано это было с тем, что из нескольких счетов, только к одному был привязан тариф. К остальным же - просто услуга, без тарифа.
Создав тестового пользователя с двумя счетами - один с услугой, другой - с тарифом, я такого же эффекта добиться не смог.
Затем, я удалил счёт с тарифом у реального пользователя, и всё заработало нормально, после выполнения рекомендаций в verificator.log, удаления ручками сервисной связки из таблицы service_links и удаления записи из users_accounts (на это верификатор почему-то не ругался, но ядро не пускало в админку, мотивируя тем, что не может найти этот счёт).
Да, кнопка "Удалить" напротив счёта почему-то не работает. Это из-за того, что база у меня кривая или она в принципе не работает?
Больше я этот эффект вопроизвести не могу, да и не хочется. Если Вам интересно всё-таки исправить ту ошибку, то базу я Вам высылал, могу выслать ещё раз.
Я точно не знаю, в чём проблема была, но мне кажется, что связано это было с тем, что из нескольких счетов, только к одному был привязан тариф. К остальным же - просто услуга, без тарифа.
Создав тестового пользователя с двумя счетами - один с услугой, другой - с тарифом, я такого же эффекта добиться не смог.
Затем, я удалил счёт с тарифом у реального пользователя, и всё заработало нормально, после выполнения рекомендаций в verificator.log, удаления ручками сервисной связки из таблицы service_links и удаления записи из users_accounts (на это верификатор почему-то не ругался, но ядро не пускало в админку, мотивируя тем, что не может найти этот счёт).
Да, кнопка "Удалить" напротив счёта почему-то не работает. Это из-за того, что база у меня кривая или она в принципе не работает?
Больше я этот эффект вопроизвести не могу, да и не хочется. Если Вам интересно всё-таки исправить ту ошибку, то базу я Вам высылал, могу выслать ещё раз.
сейчас запустил 15-й билд - система запустилась. даже жава-мордой подкючаюсь.
однако, настораживают следущие строки в логах:
з.ы повторно выполнил команду
mysql -f utm < reg.sql
та же история.
однако, настораживают следущие строки в логах:
иmain.log писал(а): Info : Oct 03 15:15:44 UTMCtx: License verification for <core:5.1.10-015-linux>
Warn : Oct 03 15:15:44 UTMCtx: License verification failed: no public key found
как это лечить и чем грозит?debug.log писал(а): Info : Oct 03 15:15:44 UTMCtx: License verification for <core:5.1.10-015-linux>
Warn : Oct 03 15:15:44 UTMCtx: License verification failed: no public key found
з.ы повторно выполнил команду
mysql -f utm < reg.sql
та же история.
ещё одна интересная особенность при удалении тарифных планов.
1.открываю окно редактирования пользователя.
2. перехожу на закладку тарифные планы.
3. давлю кнопку удалить.
в итоге получаю:
1. закладка тарификация -> расчетные периоды: плюс один расчетный период, начинающийся с момента удаления тарифа у пользователя. его удаляю путём изменения окончания периода.
2. перезапускаю utm_core
в verificator.log выплёвывается следущее:
если же производить сначала удаление ip-группы (закладка услуги, выбираем услугу, входящую в тарифный план; жмём кнопку редактировать; в окне сервисных связок удалям ip-группу), а потом удаление тарифа, то эффект такой же. хотя, в 11-м билде в verificator.log ничего не выпадало.
1.открываю окно редактирования пользователя.
2. перехожу на закладку тарифные планы.
3. давлю кнопку удалить.
в итоге получаю:
1. закладка тарификация -> расчетные периоды: плюс один расчетный период, начинающийся с момента удаления тарифа у пользователя. его удаляю путём изменения окончания периода.
2. перезапускаю utm_core
в verificator.log выплёвывается следущее:
соответственно, Account 10 - номер аккаунта пользователя, у которого только что был удалён тариф. как бороться с этой ситуацией. чего я делаю не так?-- ERROR Account 10 linked to deleted discount period 1
-- SQL DESC undelete discount period
UPDATE discount_periods SET is_expired=0 WHERE id='1';
если же производить сначала удаление ip-группы (закладка услуги, выбираем услугу, входящую в тарифный план; жмём кнопку редактировать; в окне сервисных связок удалям ip-группу), а потом удаление тарифа, то эффект такой же. хотя, в 11-м билде в verificator.log ничего не выпадало.