Usando mysqldump no cron job sem senha root

Question

Se eu fizer login com a senha de root na minha caixa, posso simplesmente digitar

mysqldump --all-databases e recebo o esperado "Dump".

Eu configurei um trabalho no cron.daily para executar e despejar isso em uma unidade de backup. O problema que tenho é que, embora o usuário esteja rodando como root, recebo a seguinte mensagem

mysqldump: Obteve o erro: 1045: Acesso negado para o usuário 'root' @ 'localhost' (usando a senha: NO)

ao tentar se conectar. Eu não quero codificar a senha da raiz do banco de dados mysql no script (quem faria).

Considerando que eu posso apenas digitar "mysqldump" na linha de comando no meu bash shell, deve haver alguma forma de contornar usando o parâmetro -u. Eu já tenho #! / bin / bash no topo do script. / p>

O que estou faltando aqui para conseguir isso para não pedir a senha de root para o banco de dados?

    

Answer 1

Para se conectar ao servidor mysql você deve fornecer credenciais. Você pode especificá-los em um arquivo de configuração, passá-los através da linha de comando ou simplesmente criar uma conta que não requer credenciais.

É claro que a opção sem senha nunca deve ser usada, a linha de comando de passagem não é boa porque qualquer um que pode executar ps pode ver a linha de comando.

A opção recomendada é criar um arquivo de configuração do mysql com as credenciais e, em seguida, proteger esse arquivo com permissões do sistema de arquivos para que apenas o usuário de backup possa acessá-lo.

Você pode fazer login no servidor mysql enquanto estiver logado interativamente, já que o root parece sugerir que você não tem um conjunto de senhas root, ou que você tem um arquivo de configuração que não está sendo encontrado pelo seu script. Se você tiver um arquivo .my.cnf, pode ser necessário apontá-lo manualmente. Se a sua conta root não tiver uma senha configurada, recomendamos strongmente que você corrija isso.

Update (2016-06-29) Se você estiver executando o mysql 5.6.6 ou superior, você deve olhar o ferramenta mysql_config_editor que permite que você armazenar credenciais em um arquivo criptografado. Obrigado ao Giovanni por mencionar isso para mim.

    

Answer 2

A segurança não deve ser feita através da obscuridade. Se você tem medo de que alguém tenha acesso à sua conta root, não importa se a senha mysql do root está armazenada no script, já que você tem todos os seus dados disponíveis no mysql dumps, ou arquivos de banco de dados. Então, a verdadeira questão é o que você está tentando proteger?

Se você não quiser que outros usuários tenham uma senha que permita que eles alterem dados em seu banco de dados, você precisará criar um usuário com permissões adequadas .

Se você não quiser que a senha mysql seja vista por qualquer conta local, exceto as permissões de arquivo script para ser 0700 e proprietário para root.

    

Answer 3

Seu uso de shell pode ser feito porque você tem um shell para executá-lo, ou seja, quando você faz logon, todos os seus scripts de shell em seu perfil são executados.

O Cron não tem esses luxos. Quando ele se conecta (como root), ele fará o login com um shell padrão. Isso impede que qualquer pessoa faça logon remotamente, mas também significa que não há scripts de login automático executados.

Você pode definir um shell para o cron rodar, editar o crontab e adicionar as variáveis SHELL e HOME, por exemplo.

SHELL=/bin/bash
HOME=/root

se estes não estiverem configurados, o cron será executado com o diretório shell e home especificado em / etc / passwd (que provavelmente não são nada, possivelmente / bin / sh).

Se você deseja ver o cron do ambiente em execução, inclua uma tarefa cron que exporte env para um arquivo, por exemplo:

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

    

Answer 4

Se o script for executado pelo root, você poderá criar um arquivo /root/.my.cnf com as permissões 600 e o seguinte conteúdo:

[client]
user = DBUSERNAME
password = DBPASSWORD

(onde você insere seu nome de usuário e senha do MySQL, é claro).

Este arquivo será lido automaticamente por qualquer ferramenta de linha de comando mysql, se for executado como root. Não há mais necessidade de fornecê-lo na linha de comando. As 600 permissões protegem contra olhares indiscretos.

    

Answer 5

O Cron pode ser muito frustrante para depurar. Quando as tarefas agendadas são executadas, elas não têm um ambiente definido como o aceito por um shell.

Dicas para o cron:

• use caminhos completos para tudo - "ECHO = / bin / echo", etc: (defina variáveis no topo para facilitar)
• define MAILTO, para que você receba um email de cada tarefa (ou faça com que as tarefas redirecionem stderr / stdout para um arquivo)

Se o seu usuário root puder fazê-lo a partir do shell, o cron deverá ser capaz de fazê-lo. Certifique-se de especificar explicitamente o arquivo de configuração para usar na linha de comando.

    

Answer 6

Embora várias dessas respostas sejam úteis, várias são confusas porque o usuário root unix e o usuário root do mysql não são os mesmos e basicamente não possuem nenhum outro relacionamento além de ambos usarem o nome de login 'root'. Talvez isso seja óbvio, mas parece que algumas respostas combinam as duas.

O que pode ser uma opção útil (talvez exista?) para o mysqld seria permitir que programas cliente como mysql ou mysqldump etc executem como root unix para acessar o root @ localhost do mysqld sem uma senha sem ter que armazenar root @ localhost's ( mysql) senha em um arquivo my.cnf ou similar.

Eu sei que isso deixa alguns nervosos, mas o raciocínio é que alguém rodando como root local (para o servidor mysqld) unix pode ignorar a segurança do mysqld de qualquer forma, muito facilmente. E ter um my.cnf com a senha do mysqld root 7x24 ou até mesmo criar / excluir um my.cnf com a senha do mysql root (de onde vem essa senha?) On the fly (por exemplo, fazer um mysqldump) faz me nervoso.

Isso exigiria alguma infra-estrutura e pensamento, porque seria preciso confiar no mysql / mysqldump / etc para transmitir ao mysqld que ele realmente acredita que está sendo executado por uma conta raiz unix local.

Mas, por exemplo, limitando apenas ao socket unix do mysqld, nenhum TCP, poderia ajudar, pelo menos como uma opção strongmente recomendada desta opção. Isso poderia estabelecer que o cliente está rodando localmente, o que provavelmente não é o suficiente. Mas poderia ser o começo de uma ideia. Talvez o envio de um descritor de arquivos por um soquete unix possa ser outra peça (google, se isso soa como conversa maluca).

P.S. Não, não vou tentar debater aqui como isso pode funcionar em um sistema operacional não-unix, pois a ideia provavelmente se traduz em outros sistemas operacionais.