Ubuntu-fr

Anozer

MariaDB: debian.cnf erroné et debian-sys-maint absent

Bonjour,

Après de longues recherche sur le web, je viens solliciter votre aide.
J’ai un soucis avec mon installation de MariaDB sur un ubuntu server 16.04, installé en suivant ce tuto.

Tout d'abord logrotate m'a révélé l'erreur suivante:

/etc/cron.daily/logrotate:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
error: error running shared postrotate script for '/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/	mysql/mariadb-slow.log /var/log/mysql/error.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1

En cherchant un peu, je pense avoir trouvé la ligne qui provoque cette erreur dans le fichier /etc/logrotate.d/mysql-server :

mysqladmin --defaults-file=/etc/mysql/debian.cnf flush-logs

En suivant le chemin, je trouve quelque chose d’étrange dans ce fichier de conf /etc/mysql/debian.cnf :

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = root
password = 
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = root
password = 
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Mon mot de passe root n’est pas indiqué dans ce fichier, ce qui explique l’erreur de départ.

Ensuite, en cherchant sur de très nombreux forum, je me rend compte que tout le monde a un utilisateur debian-sys-maint de déclaré dans ce fichier avec un mot de passe créé à l’install. Or non seulement je n’ai pas cet utilisateur dans le fichier, mais je ne l’ai pas non plus dans mysql :

MariaDB [mysql]> SELECT User FROM user;
+------------------+
| User             |
+------------------+
| c1_db1_main_user |
| c1_db1_main_user |
| ispconfig        |
| phpmyadmin       |
| root             |
| roundcube        |
+------------------+

Et là, en tant que néophyte, je suis un perdu. Je pense qu’il faudrait, au choix :
- Regénérer /etc/mysql/debian.cnf pour faire apparaitre le password root
- Recréer debian-sys-maint puis recréer /etc/mysql/debian.cnf pour le faire apparaitre avec son password

Qu'en pensez vous ? Pouvez-vous m’aider à réparer cette situation ?

donut

Re : MariaDB: debian.cnf erroné et debian-sys-maint absent

Essaie :

dpkg-reconfigure mariadb-server

Ou encore :

mysql_secure_installation

---

https://utux.fr (blog perso)

Anozer

Re : MariaDB: debian.cnf erroné et debian-sys-maint absent

Merci pour ta réponse.
Malheureusement, aucune des deux commandes n'a changé quelque chose. Le fichier /etc/mysql/debian.cnf n'a pas été modifié.
J'ai changé son nom pour voir s'il allait être recréé, ce n'est pas le cas.

bruno

Re : MariaDB: debian.cnf erroné et debian-sys-maint absent

C'est normal.
Pour une raison que j'ignore le paquet mariadb-server-10.0 d'Ubuntu ne créé pas l'utilisateur debian-sys-maint lors de son installation et créé un fichier debian.cnf comme celui que tu as indiqué : compte root, mot de passe vide.
La solution la plus simple est de modifier le fichier debian.cnf pour y indiquer le mot de passe du compte root de MySQL.

N.B. : sur Debian 8 le problème ne se pose pas, le script post-installation de mariadb créé bien l'utilisateur debian-sys-maint…

N.B. (2) : les paquets des dépôts spécifiques mariadb semblent également proposer un script de post-installation correct

EDIT
Voici une explication plus complète (voir le fichier /usr/share/doc/mariadb-server-10.0/README.Debian.gz)

Sur Ubuntu MariaDB utilise par défaut la méthode d'authentification par socket Unix et non par mot de passe. L'utilisateur root de mysql n'a donc pas de mot de passe : il est authentifié automatiquement lorsque mysql est invoqué par l'utilisateur root du système. L'utilisateur debian-sys-maint devient inutile dans ses conditions.

Dans de nombreux « tutos » on utilise des manipulations qui consistent à créé un mot de passe pour l'utilisateur root de mysql et donc à désactiver l’authentification par socket Unix pour root. Du coup les scripts de maintenance (logrotate par exemple) ne fonctionnent plus.

La solution que j'ai donné plus haut doit fonctionner (mettre le mot de passe root dans debian.cnf) mais on peut aussi modifier l'utilisateur root de mysql pour réactiver la connexion par socket Unix (plugin unix_socket).

Dernière modification par bruno (Le 29/12/2016, à 12:35)

Anozer

Re : MariaDB: debian.cnf erroné et debian-sys-maint absent

Bonjour Bruno,

Je te remercie pour ces explications très précises.
Il y a un paragraphe à propos de ce plugin dans mon fichier /etc/mysql/mariadb.conf.d/50-server.cnf, mais ce n'est que du commentaire. Il manque une ligne pour activer le plugin. Cela me parait donc cohérent.

Je viens de lire que l'authentification par socket est intéressante pour une question de perf. Mais sur mon petit VPS, je m'en moque.
Etant donné que j'ai du mal à saisir toutes les conséquences de ce changement de comportement de l'utilisateur root, je vais dans un premier temps indiquer mon mot de passe dans le fichier.

Cependant je reste curieux. Le lien vers MariaDB indique comment installer le plugin puis créer un nouvel utilisateur identifié par socket. Mais comment en faire de même pour l'utilisateur root existant ?

Au final, d'après toi, quelle solution te parait la plus intéressante ?

LeoMajor

Re : MariaDB: debian.cnf erroné et debian-sys-maint absent

bonjour,
Sous mysql, c'est surtout grant qui fixe les règles du jeu, les conditions d'accès. Si une des conditions, ne valide pas, pour untel user, dans la policy grant, alors untel user n'a pas accès. Le mot de passe dans une policy grant est un argument parmi les autres, mais n'est pas suffisant à lui tout seul.
il faut que tu vérifies le minimum syndical la table mysql.user

select * from mysql.user ;

la policy grant qui est associée à untel user.

show grants for untel_user@host;

en rédémarrant provisoirement le service, je pense, avec de mémoire --skip-grant-table et éventuellement un truc du genre --skip-network --skip-no-resolve ( à toi de vérifier la syntaxe exacte des paramètres )

pour créer un utilisateur, il y a 2 solutions;
1/ 1a CREATE USER  et compléter avec  2a GRANT
2/ ou renseigner complètement GRANT

si c'est un utilisateur secondaire la database est à créer seulement après, soit par root, soit par l'utilisateur qui a accès.

à remarquer que la réciproque n'est pas vérifiée avec CREATE USER & DROP USER.
CREATE USER  ne peuple pas de tables grant, alors que DROP USER supprime l'enregistrement sous mysql.user et aussi sous grant. Je ne sais pas si c'est encore d'actualité sous le 5.6 5.7 et plus...

Arès je ne comprends pas que MariaDB, n'utilise pas un vocabulaire, des chemins de fichier, qui lui sont propres, plutôt que faire du mimétisme avec mysql-server. Cela à tendance à porter à confusion.
presque obligé de faire des apt-file list paquet, ...
sous ubuntu, pour mysql-server, c'est /etc/mysql/my.cnf, qui est lu.

Dernière modification par LeoMajor (Le 02/01/2017, à 17:58)

bruno

Re : MariaDB: debian.cnf erroné et debian-sys-maint absent

Re,

Personnellement je pense qu'il est préférable de continuer à utiliser le comportement habituel avec l'authentification par mot de passe. Donc renseigner le mot de passe root dans le fichier debian.cnf. C'est d'ailleurs le choix de Debian.

L'utilisation du plugin unix-socket (identification par socket Unix) peut poser d'autres problèmes avec diverses applications (phpmyadmin par exemple).

@LeoMajor : Mariadb est un fork de MySQL, il est donc logique que cela utilise les mêmes fichiers que mysql-server. Et cela facilite grandement la migration de MySQL vers Mariadb pour ceux qui le souhaitent.

Anozer

Re : MariaDB: debian.cnf erroné et debian-sys-maint absent

Bonjour.

Je m'excuse poir ne pas avoir repondu plus tôt.
J'ai pris un VPS pour héberger mon blog et quelques broutilles afin d'apprendre à gérer un serveur. Je me rend compte avec ce problème que je suis incapable de prédire le comportement de toutes les connexions qui dependront de la modification du comportement de mon utilisateur root mysql, comme celle de phpmyadmin par exemple.

Donc, en debut de semaine dernière, j'ai inscrit le mot de passe en dur de le fichier cité précédemment. Celà fonctionne parfaitement depuis.

Je vous remercie pour vos précieuses explications qui m'ont bien éclairé et résolu mon problème.