Utiliser mysqldump dans un travail cron sans mot de passe root

Si je me connecte avec le mot de passe root sur ma boîte, je peux simplement taper

mysqldump --all-databases et j'obtiendrai le "Dump" attendu.

J'ai configuré un travail dans cron.daily pour l'exécuter et le vider sur un lecteur de sauvegarde. Le problème que j'ai est que, bien que l'utilisateur s'exécute en tant que root, j'obtiens le message suivant

mysqldump: Erreur obtenue: 1045: Accès refusé pour l'utilisateur 'root' @ 'localhost' (en utilisant le mot de passe: NO)

lorsque vous essayez de vous connecter. Je ne veux pas coder en dur le mot de passe root de la base de données mysql dans le script (qui le ferait).

Étant donné que je peux simplement taper "mysqldump" sur la ligne de commande dans mon shell bash, il doit y avoir un moyen de se déplacer en utilisant le paramètre -u. J'ai déjà #! / Bin / bash en haut du script.

Qu'est-ce que je manque ici pour que cela ne demande pas le mot de passe root à la base de données?

Pour vous connecter au serveur mysql, vous devez fournir des informations d'identification. Vous pouvez les spécifier dans un fichier de configuration, les transmettre via la ligne de commande ou simplement créer un compte qui ne nécessite pas d'informations d'identification.

Bien sûr, l'option sans mot de passe ne doit jamais être utilisée, la ligne de commande de passage n'est pas géniale car quiconque peut exécuter ps peut voir la ligne de commande.

L'option recommandée consiste à créer un fichier de configuration mysql avec les informations d'identification, puis à protéger ce fichier avec des autorisations de système de fichiers afin que seul votre utilisateur de sauvegarde puisse y accéder.

Vous pouvez vous connecter au serveur mysql lorsque vous êtes connecté de manière interactive en tant que root semble suggérer que vous n'avez pas de mot de passe root défini ou que vous avez un fichier de configuration qui n'est pas trouvé par votre script. Si vous avez un .my.cnf, vous devrez peut-être le pointer manuellement. Si votre compte root n'a pas de mot de passe, je vous encourage fortement à le corriger.

Mise à jour (2016-06-29) Si vous exécutez mysql 5.6.6 ou une version ultérieure, vous devez consulter l' outil mysql_config_editor qui vous permet de stocker les informations d'identification dans un fichier crypté. Merci à Giovanni de m'en avoir parlé.

La sécurité ne doit pas se faire par l'obscurité. Si vous avez peur que quelqu'un ait accès à votre compte root, peu importe si le mot de passe mysql de root est stocké dans le script, car toutes vos données sont disponibles dans les vidages mysql ou les fichiers de base de données. Alors, la vraie question est ce que vous essayez de protéger?

Si vous ne voulez pas que les autres obtiennent un mot de passe qui leur permettra de modifier les données de votre base de données, vous devrez créer un utilisateur avec les autorisations appropriées .

Si vous ne voulez pas que ce mot de passe mysql soit vu par un compte local, à l'exception des autorisations de fichier de jeu de racine sur ce script à 0700 et le propriétaire à root.

Votre utilisation du shell peut le faire car vous avez un shell pour l'exécuter, c'est-à-dire lorsque vous vous connectez, tous vos scripts shell de votre profil sont exécutés.

Cron n'a pas de tels luxes. Lorsqu'il se connecte (en tant que root), il se connecte avec un shell par défaut. Cela empêche quiconque de se connecter à distance, mais cela signifie également qu'aucun script de connexion automatique n'est exécuté.

Vous pouvez définir un shell pour que cron s'exécute sous, modifier la crontab et ajouter les variables SHELL et HOME, par exemple.

SHELL=/bin/bash
HOME=/root

s'ils ne sont pas définis, alors cron s'exécutera avec le shell et le répertoire personnel spécifiés dans / etc / passwd (qui ne sont probablement rien, peut-être / bin / sh).

Si vous voulez voir l'environnement dans lequel cron s'exécute, ajoutez un travail cron qui exporte env dans un fichier, par exemple:

$crontab -e
* * * * * env > /tmp/crontabenv.log
:wq

Si le script est exécuté par root, vous pouvez créer un fichier /root/.my.cnf avec les autorisations 600 et le contenu suivant:

[client]
user = DBUSERNAME
password = DBPASSWORD

(où vous entrez bien sûr votre nom d'utilisateur et votre mot de passe MySQL).

Ce fichier sera automatiquement lu par n'importe quel outil de ligne de commande mysql, s'il est exécuté en tant que root. Plus besoin de le fournir sur la ligne de commande. Les 600 autorisations le protègent contre les regards indiscrets.

Cron peut être très frustrant à déboguer. Lorsque les tâches cron s'exécutent, aucun environnement n'est défini comme vous le tenez pour acquis avec un shell.

Conseils pour cron:

• utiliser des chemins complets vers tout - "ECHO = / bin / echo", etc: (définir des variables en haut pour le rendre plus facile)
• définissez MAILTO, de sorte que vous recevez un e-mail de chaque travail (ou que les travaux redirigent stderr / stdout vers un fichier)

Si votre utilisateur root peut le faire à partir du shell, cron devrait pouvoir le faire. Assurez-vous de spécifier explicitement le fichier de configuration à utiliser sur la ligne de commande.

Bien que plusieurs de ces réponses soient utiles, plusieurs prêtent à confusion car l'utilisateur root unix et l'utilisateur root mysql ne sont pas les mêmes et n'ont fondamentalement aucune relation autre qu'ils utilisent tous les deux le nom de connexion 'root'. C'est peut-être évident, mais il semble que certaines réponses confondent les deux.

Ce qui pourrait être une option utile (peut-être existe-t-elle?) Pour mysqld serait d'autoriser des programmes clients tels que mysql ou mysqldump etc fonctionnant en tant que root unix à accéder à root @ localhost de mysqld sans mot de passe sans avoir à stocker le mot de passe de root @ localhost (mysql) dans un fichier my.cnf ou similaire.

Je sais que cela rend un peu nerveux mais le raisonnement est que n'importe qui s'exécutant en tant que racine unix locale (sur le serveur mysqld) peut contourner la sécurité de mysqld de toute façon, assez facilement. Et avoir un my.cnf avec le mot de passe root mysqld 7x24 ou même créer / supprimer un my.cnf avec le mot de passe root mysql (d'où vient ce mot de passe?) À la volée (par exemple, pour faire un mysqldump) fait me nerveux.

Cela nécessiterait une certaine infrastructure et une réflexion car il faudrait faire confiance à mysql / mysqldump / etc pour transmettre à mysqld qu'il croit vraiment qu'il est géré par un compte root unix local.

Mais par exemple, limiter uniquement à la socket Unix de mysqld, aucun TCP, pourrait au moins être une option fortement recommandée de cette option. Cela pourrait établir que le client fonctionne localement, ce qui n'est probablement pas tout à fait suffisant. Mais cela pourrait être le début d'une idée. Peut-être que l'envoi d'un descripteur de fichier sur un socket Unix pourrait être un autre élément (google si cela ressemble à un discours fou.)

PS Non, je ne vais pas essayer de réfléchir ici comment tout cela pourrait fonctionner sur un système d'exploitation non-unix, alors que l'idée se traduit probablement par d'autres systèmes d'exploitation.