Solution
Alors, voici les manipulations que j’ai faites pour résoudre mes problèmes au final :
- Je me suis rendue compte que mon utilisateur mysql root n’avait pas les droits nécessaires pour accéder aux autres bbd existantes, il n’avait les droits que sur la bdd mysql, donc :
mysql -u root -p
UPDATE mysql.user SET Grant_priv='Y', Super_priv='Y' WHERE User='root';
FLUSH PRIVILEGES;
GRANT ALL ON *.* TO 'root'@'localhost';
Là, c’est bon, l’utilisateur root a accès à tout (on peut le vérifier avec show databases;
…J’avais supprimé mon application OpenSondage sur laquelle je n’avais rien pour tester de réinstaller et avant les opérations ci-dessus, ça ne marchait pas à cause d’insuffisance de droits de l’utilisateur root. Maintenant tout va bien, j’ai pu réinstaller normalement.
- Mais pour mes app Nextcloud et Wordpress, c’est une autre histoire. J’ai plein de données dessus que je ne veux pas perdre. Même si j’ai des sauvegardes d’avant la migration, je n’ai pas trop confiance en une possible restauration alors je veux réparer ça sans supprimer les appli et les réinstaller. C’est là que je constate, en faisant un
SELECT * FROM mysql.user;
, que je n’ai plus mes utilisateurs wordpress et nextcloud dans la table (c’est une perte lors de la migration?? à vrai dire je ne sais pas quand/comment ça a pu arriver…). Alors je décide de les recréer manuellement :
insert into user (Host, User, Password, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv, Execute_priv, Repl_slave_priv, Repl_client_priv, Create_view_priv, Show_view_priv, Create_routine_priv, Alter_routine_priv, Create_user_priv, ssl_type, ssl_cipher, x509_issuer, x509_subject, max_questions, max_updates, max_connections, max_user_connections) values('localhost','nextcloud','','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','','','','','0','0','0','0');
insert into user (Host, User, Password, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv, File_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv, Execute_priv, Repl_slave_priv, Repl_client_priv, Create_view_priv, Show_view_priv, Create_routine_priv, Alter_routine_priv, Create_user_priv, ssl_type, ssl_cipher, x509_issuer, x509_subject, max_questions, max_updates, max_connections, max_user_connections) values('localhost','wordpress','','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','N','','','','','0','0','0','0');
- Cependant, il faut encore retrouver les mots de passe de ces utilisateurs :
- Pour wordpress, il se situe dans
var/www/wordpress/wp-config.php
- Pour nextcloud, il se situe dans
var/www/nextcloud/config/config.php
Et ensuite, pour chaque utilisateur crééé en étape 2 (nextcloud et wordpress dans mon cas), il suffit de lancer les commandes suivantes avec le mot de passe trouvé précédemment :
update mysql.user set password=PASSWORD("**userpassword**") where User='**username**';
GRANT ALL PRIVILEGES ON dbname.* TO 'username'@'localhost' IDENTIFIED BY 'userpassword' WITH GRANT OPTION;
- Les appli ont accès à leur base, ça fonctionne bien côté utilisateur. Mais côté admin, je ne peux toujours pas accéder aux logs des apps ni faire de mise à jour. Les erreurs lors des mises à jour sont toujours des trucs du type
Source path '\''/etc/fail2ban/filter.d/wordpress.conf'\'' does not exist
Du coup j’ai créé les fichiers à la main :
touch /etc/fail2ban/jail.d/wordpress.conf
touch /etc/fail2ban/filter.d/wordpress.conf
C’est donc ce que j’ai fais pour Wordpress et la mise à jour a pu se dérouler avec succès ensuite. ça a alors résolu le pb d’accès aux logs (qui disait “le service php5-frm est inconnu”). Il fallait la mettre à jour pour qu’elle soit bien compatible avec php7 et suite à la migration Yunohost 3 + Stretch
J’ai répété la même chose pour les autres appli touch /etc/fail2ban/filter.d/nextcloud.conf
… etc etc, et tout est à présent bien à jour et fonctionnel.
OUF, je crois que j’ai maintenant un environnement bien fonctionnel avec Yunohost 3 + Debian 9 sur mon Raspberry PI 3. Youpi!!!
J’espère que ma solution va en aider certains. (désolée si je raconte ici des choses évidentes pour certains, à mon niveau ce n’était pas évident). Merci encore à la super communauté de Yunohost!! J’en découvre toujours un peu plus grâce à vous.
+++