Использование mysqldump в работе cron без пароля root

Если я войду в систему с паролем root, я могу просто напечатать

mysqldump --all-database и я получу ожидаемый "дамп".

Я настроил задание в cron.daily для запуска и выгрузки его на резервный диск. У меня проблема в том, что, хотя пользователь работает от имени пользователя root, я получаю следующее сообщение

mysqldump: получена ошибка: 1045: доступ запрещен для пользователя 'root' @ 'localhost' (с использованием пароля: НЕТ)

при попытке подключения. Я не хочу жестко кодировать пароль root базы данных mysql в скрипте (кто бы).

Учитывая, что я могу просто набрать «mysqldump» в командной строке в моей оболочке bash, нужно каким-то образом обойти использование параметра -u. У меня уже есть #! / Bin / bash в верхней части скрипта.

Чего мне не хватает здесь, чтобы заставить это не запрашивать пароль root для базы данных?

Для подключения к серверу mysql необходимо предоставить учетные данные. Вы можете указать их в файле конфигурации, передать их через командную строку или просто создать учетную запись, которая не требует учетных данных.

Конечно, опция no-password никогда не должна использоваться, командная строка pass-by не очень хороша, потому что любой, кто может запустить ps, может увидеть командную строку.

Рекомендуемый вариант - создать файл конфигурации mysql с учетными данными в нем, а затем защитить этот файл с разрешениями файловой системы, чтобы только ваш резервный пользователь мог получить к нему доступ.

Вы можете войти на сервер mysql при интерактивном входе в систему как пользователь root, кажется, говорит о том, что у вас либо не установлен пароль root, либо у вас есть файл конфигурации, который не найден вашим скриптом. Если у вас есть файл .my.cnf, вам может потребоваться указать его вручную. Если в вашей учетной записи root не установлен пароль, я настоятельно рекомендую вам это исправить.

Обновление (2016-06-29) Если вы работаете с mysql 5.6.6 или более поздней версии, обратите внимание на инструмент mysql_config_editor , который позволяет хранить учетные данные в зашифрованном файле. Спасибо Джованни за упоминание об этом мне.

Безопасность не должна быть достигнута через безвестность. Если вы боитесь, что кто-то имеет доступ к вашей учетной записи root, не имеет значения, хранится ли в скрипте пароль mysql root, поскольку все ваши данные доступны в дампах mysql или файлах базы данных. Итак, настоящий вопрос в том, что вы пытаетесь защитить?

Если вы не хотите, чтобы другие получали пароль, который позволит им изменять данные в вашей базе данных, вам необходимо создать пользователя с соответствующими разрешениями .

Если вы не хотите, чтобы пароль mysql был виден какой-либо локальной учетной записи, кроме root, установите права доступа к файлу для этого сценария равными 0700 и владельцем для root.

Использование вашей оболочки может сделать это, потому что у вас есть оболочка для ее запуска, т.е. при входе в систему запускаются все ваши сценарии оболочки в вашем профиле.

Крон не имеет такой роскоши. Когда он входит (как root), он входит в систему по умолчанию. Это предотвращает вход в систему удаленно, но также означает, что сценарии автоматического входа не выполняются.

Вы можете установить оболочку для запуска cron, отредактировать crontab и добавить переменные SHELL и HOME, например.

SHELL=/bin/bash
HOME=/root

если они не установлены, то cron будет работать с оболочкой и домашним каталогом, указанными в / etc / passwd (которые, вероятно, ничего, возможно, / bin / sh).

Если вы хотите увидеть, что среда cron работает как, добавьте задачу cron, которая экспортирует env в файл, например:

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

Если скрипт запускается пользователем root, вы можете создать файл /root/.my.cnf с разрешениями 600 и следующим содержимым:

[client]
user = DBUSERNAME
password = DBPASSWORD

(где вы вводите имя пользователя и пароль MySQL, конечно).

Этот файл будет автоматически прочитан любым инструментом командной строки mysql, если он запущен от имени пользователя root. Больше не нужно указывать это в командной строке. 600 разрешений защищают его от посторонних глаз.

Cron может очень расстраивать отладку. Когда выполняются задания cron, они не имеют установленной среды, которую вы воспринимаете как само собой разумеющееся в оболочке.

Советы для cron:

• используйте полные пути ко всему - "ECHO = / bin / echo" и т. д. (определите переменные вверху, чтобы было проще)
• установите MAILTO, чтобы вы получали электронное письмо от каждого задания (или чтобы задания перенаправляли stderr / stdout в файл)

Если ваш пользователь root может сделать это из оболочки, cron должен это сделать. Убедитесь, что вы явно указали файл конфигурации для использования в командной строке.

Хотя некоторые из этих ответов полезны, некоторые вводят в заблуждение, потому что root-пользователь unix и root-пользователь mysql не совпадают и, по сути, не имеют никакого отношения, кроме того, что оба используют логин «root». Может быть, это очевидно, но, похоже, некоторые ответы объединяют их.

Что может быть полезным вариантом (возможно, существует?) Для mysqld, это разрешить клиентским программам, таким как mysql или mysqldump и т. Д., Работающим от имени пользователя root, получать доступ к root @ localhost mysqld без пароля без необходимости хранить пароль root @ localhost (mysql). в файле my.cnf или аналогичном.

Я знаю, что это немного нервирует, но причина в том, что любой, работающий как локальный (для сервера mysqld) корень unix, может в любом случае легко обойти безопасность mysqld. А наличие my.cnf с паролем root mysqld 7x24 или даже создание / удаление my.cnf с паролем root mysql (откуда этот пароль взялся?) На лету (например, для выполнения mysqldump) заставляет меня нервничать.

Это потребовало бы некоторой инфраструктуры и размышлений, потому что нужно было бы доверять mysql / mysqldump / etc для передачи mysqld, что он действительно верит, что он запускается локальной учетной записью root unix.

Но, например, ограничение только unix-сокетом mysqld, без TCP, может помочь, по крайней мере, как настоятельно рекомендуемый вариант этой опции. Это может установить, что клиент работает локально, хотя этого, вероятно, недостаточно. Но это может быть началом идеи. Возможно, отправка файлового дескриптора через сокет Unix могла бы быть другой частью (Google, если это звучит как сумасшедший разговор)

PS Нет, я не собираюсь прямо сейчас рассуждать о том, как все это может работать в не-Unix операционной системе, хотя эта идея, вероятно, переводится на другие ОС.