mysql - глюк или фича?

[alibek]

В приватной сети есть сервер mysql (точнее mariadb).

На этом сервере есть служебная БД db и к ней пользователь user.

Ранее к БД обращался хост host1.zone.tld (10.1.128.12), на сервере учетная запись была прописана как user@host1.zone.tld.

Теперь понадобилось обращаться из другого места (10.1.144.4).

Чтобы не усложнять, первую учетную запись изменил на user@10.1.128.% и добавил еще одну user@10.1.144.%. И заодно выключить ресолвинг имен (включил опцию skip-name-resolve).

И все сломалось.

 

Вообщем, что я не делал, под учеткой user подключиться к БД не получалось, пока ресолвинг имен был выключен.

Как только комментировал опцию skip-name-resolve, старый хост 10.1.128.12 начинал подключаться, но новый хост 10.1.144.3 все равно не работал.

Включал опцию skip-name-resolve обратно — и подключиться не мог никто.

 

А потом, методом тыка, удалил учетки и создал их заново. И все заработало.

Теперь не могу понять, это какой-то баг в mysql-сервере или я какие-то моменты упускаю.

[st_re]

Как включали выключали опцию скип ресолв ? если не через изменение my.cfg (или где там они у Вас) и перезапуск mysql то делалось ли после создания юзера еще и FLUSH PRIVILEGES ?

 

и сравнить 

SHOW GRANTS FOR `user`@`host1.zone.tld`;

SHOW GRANTS FOR `user`@`10.1.128.%`;

SHOW GRANTS FOR `user`@`10.1.144.%`;

[alibek]

Изменение конфига, перезапуск mysql. flush после изменения прав (и пользователей) делался.

 

В 01.08.2022 в 16:07, st_re сказал:

и сравнить

Сейчас вывод одинаковый.

Как было тогда — уже не узнать.

Но в GUI (я использовал HeidiSQL) пользователи и права доступа были совершенно одинаковы.

[YuryD]

 Ну хз, можно и flush tables еще попробовать. Ятд, что оно ко всем таблицам применяется, возможно и к системным. Еще одна идея - при создании нового юзера пароль шифруется новым методом (о чем я наплакался при смене версий и гребаным old_passwd). Про поводу сравнить - ну восстановитесь из бакапа и проверьте....

[st_re]

А в логе что ?

[YuryD]

В 01.08.2022 в 18:58, st_re сказал:

А в логе что ?

 В логе чего ? Логи mysql-server как правило пустотелы, ибо каждый чих хранить себе дороже... Логи клиента тоже малоинформативны, если они вообще есть....

[st_re]

ну так включить то надо, если чтото нихт арбайтн

[alibek]

В логах сервера ничего. В логах клиента тоже ничего полезного, ошибка 1045, нет доступа для пользователя user@10.1.144.3.

И бэкап восстанавливать и проверять тоже не тянет.

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

 

В 01.08.2022 в 16:57, YuryD сказал:

Еще одна идея - при создании нового юзера пароль шифруется новым методом

Возможно. Сервер и база достаточно старые, обновлялась неоднократно.

[jffulcrum]

В 01.08.2022 в 14:58, alibek сказал:

первую учетную запись изменил на user@10.1.128.% и добавил еще одну user@10.1.144.%. И заодно выключить ресолвинг имен (включил опцию skip-name-resolve)

В общем, даже @localhost может приводить к проблемам при skip-name-resolve в 5.х версиях. Не выключайте ресольвинг или не используйте @ имена, базовые правила.