Utilizzo di mysqldump nel processo cron senza password di root

Se accedo con la password di root sulla mia casella, posso semplicemente digitare

mysqldump --all-database e otterrò l'atteso "Dump".

Ho impostato un lavoro in cron.daily per eseguirlo e scaricarlo su un'unità di backup. Il problema che ho è che sebbene l'utente stia eseguendo come root ricevo il seguente messaggio

mysqldump: errore ottenuto: 1045: accesso negato per l'utente 'root' @ 'localhost' (utilizzando la password: NO)

quando si tenta di connettersi. Io non voglio codificare la password di root database mysql nello script (che sarebbe).

Considerando che posso semplicemente digitare "mysqldump" nella riga di comando nella mia shell bash ci deve essere un modo per aggirare usando il parametro -u. Ho già #! / Bin / bash nella parte superiore dello script.

Cosa mi manca qui per ottenere questo per non chiedere la password di root al database?

Per connettersi al server mysql è necessario fornire le credenziali. Puoi specificarli in un file di configurazione, passarli tramite la riga di comando o semplicemente creare un account che non richiede credenziali.

Ovviamente l'opzione senza password non dovrebbe mai essere utilizzata, la riga di comando pass-by non è eccezionale perché chiunque può eseguire ps potrebbe essere in grado di vedere la riga di comando.

L'opzione consigliata è quella di creare un file di configurazione mysql con le credenziali al suo interno e quindi proteggere quel file con le autorizzazioni del filesystem in modo che solo l'utente di backup possa accedervi.

La possibilità di accedere al server mysql durante l'accesso interattivo come root sembra suggerire che non si dispone di una password di root impostata o che si dispone di un file di configurazione che non viene trovato dallo script. Se si dispone di un file .my.cnf, potrebbe essere necessario puntarlo manualmente. Se il tuo account di root non ha una password impostata, ti consiglio vivamente di risolverlo.

Aggiornamento (29/06/2016) Se si esegue mysql 5.6.6 o versioni successive, è necessario esaminare lo strumento mysql_config_editor che consente di archiviare le credenziali in un file crittografato. Grazie a Giovanni per avermelo detto.

La sicurezza non dovrebbe essere fatta attraverso l'oscurità. Se hai paura che qualcuno abbia accesso al tuo account root, non importa se la password mysql di root è memorizzata nello script, poiché hai tutti i tuoi dati disponibili in dump mysql o file di database. Quindi, la vera domanda è: cosa stai cercando di proteggere?

Se non si desidera che altri ottengano una password che consentirà loro di modificare i dati nel database, è necessario creare un utente con le autorizzazioni appropriate .

Se non si desidera che la password mysql venga visualizzata da alcun account locale, ad eccezione delle autorizzazioni per i file di root impostati su quello script, sia 0700 e il proprietario su root.

L'utilizzo della shell può farlo perché si dispone di una shell da cui eseguirla, ovvero quando si accede, vengono eseguiti tutti gli script della shell nel profilo.

Cron non ha tali lussi. Quando accede (come root) accederà con una shell predefinita. Ciò impedisce a chiunque di accedere in remoto, ma significa anche che non sono stati eseguiti script di accesso automatico.

È possibile impostare una shell in cui eseguire cron, modificare il crontab e aggiungere le variabili SHELL e HOME, ad es.

SHELL=/bin/bash
HOME=/root

se questi non sono impostati, cron verrà eseguito con la shell e la directory home specificate in / etc / passwd (che probabilmente non sono nulla, possibilmente / bin / sh).

Se vuoi vedere l'ambiente in cui cron è in esecuzione, aggiungi un processo cron che esporta env in un file, ad esempio:

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

Se lo script viene eseguito da root, è possibile creare un file /root/.my.cnf con autorizzazioni 600 e il seguente contenuto:

[client]
user = DBUSERNAME
password = DBPASSWORD

(dove inserisci il tuo nome utente e password MySQL ovviamente).

Questo file verrà automaticamente letto da qualsiasi strumento da riga di comando mysql, se viene eseguito come root. Non è più necessario fornirlo sulla riga di comando. Le 600 autorizzazioni lo proteggono da occhi indiscreti.

Cron può essere molto frustrante per il debug. Quando i lavori cron vengono eseguiti, non hanno un ambiente impostato come da te dato per scontato con una shell.

Suggerimenti per cron:

• usa percorsi completi per tutto - "ECHO = / bin / echo", ecc: (definisci le variabili in alto per renderlo più facile)
• impostare MAILTO, in modo da ricevere un'e-mail da ciascun lavoro (o fare in modo che i lavori reindirizzino stderr / stdout su un file)

Se l'utente root può farlo dalla shell, cron dovrebbe essere in grado di farlo. Assicurati di specificare esplicitamente il file di configurazione da utilizzare nella riga di comando.

Sebbene molte di queste risposte siano utili, molte sono confuse perché l'utente root unix e l'utente root mysql non sono uguali e fondamentalmente non hanno relazioni diverse da quelle che usano entrambi il nome di accesso 'root'. Forse è ovvio, ma sembra che alcune risposte confondano i due.

Quale potrebbe essere un'opzione utile (forse esiste?) A mysqld sarebbe quella di consentire a programmi client come mysql o mysqldump ecc. In esecuzione come root unix di accedere a root @ localhost di mysqld senza password senza dover memorizzare la password di root @ localhost (mysql) in un file my.cnf o simile.

So che rende nervoso, ma il ragionamento è che chiunque esegua come root unix locale (al server mysqld) può aggirare la sicurezza di mysqld comunque, abbastanza facilmente. E avere un my.cnf con la password di root mysqld 7x24 o persino creare / eliminare un my.cnf con la password di root mysql (da dove viene quella password?) Al volo (ad esempio, per fare un mysqldump) mi rende nervoso.

Richiederebbe qualche infrastruttura e pensiero perché si dovrebbe fidare di mysql / mysqldump / etc per trasmettere a mysqld che crede davvero che sia gestito da un account root unix locale.

Ma per esempio limitare al solo socket unix di mysqld, nessun TCP, potrebbe aiutare, almeno come opzione fortemente raccomandata di questa opzione. Ciò potrebbe stabilire che il client è in esecuzione localmente anche se probabilmente non è abbastanza. Ma potrebbe essere l'inizio di un'idea. Forse l'invio di un descrittore di file su un socket unix potrebbe essere un altro pezzo (cercalo su Google se sembra un discorso folle).

PS No, non ho intenzione di fare un brainstorming proprio qui su come qualcosa di tutto ciò potrebbe funzionare su un sistema operativo non unix, anche se l'idea si traduce probabilmente in altri sistemi operativi.