Page 1 of 2
Mysql backup failed
Posted: Thu Jun 06, 2013 4:30 am
by XakRu
Вчера выкроил время, чтобы заглянуть на сервер. Прошелся скриптом от mysqltuner.
Тот мне показал что есть доступ к учетке рута в мускуле без пароля, я все учетки эти запаролил. Сегодня получаю ошибки о том что не получилось создать бэкап.
Пароль рута в мускуле сменил и измененный вписал в конфигурационный файл весты. Как быть? Открытый доступ оставлять нехорошо ведь?
Re: Mysql backup failed
Posted: Thu Jun 06, 2013 5:33 am
by skid
Пустые записи действительно остаются, но зайти на сервер root-м без паролья не выйдет. Маппинг будет идти либо на учетку root@localhost, для которой стоит пароль, либо на root@%, которой нет по умолчанию.
В любом случае такие записи лучше не осталвять. Мы добавили в установщик команду
Code: Select all
mysql -e "DELETE FROM mysql.user WHERE user='' or password='';"
Спасибо
Re: Mysql backup failed
Posted: Thu Jun 06, 2013 7:11 am
by XakRu
там была также запись
[email protected] без пароля
но, я сменил пароль, записал /usr/local/vesta/conf/mysql.conf больше нигде.
т.к. пароль рута сменил и графики теперь ругаются. бэкапы не отрабатываются.
где еще сменить?
Re: Mysql backup failed
Posted: Thu Jun 06, 2013 7:57 am
by skid
При попытке подключения с 127.0.0.1, хост будет определен как localhost и соответсвенно без пароля не получится зайти.
Что касается бэкапов, то панель использует пароль только из файла /usr/local/vesta/conf/mysql.conf. Есть две возможные причины почему не работают бэкапы:
1) Ошибка в коде панели. Пока я не смог воспроизвести ситуацию. Проверьте работает создание/удаление баз данныз или нет?
2) Пароль в /usr/local/vesta/conf/mysql.conf не совпадает с актуальным. Проверить пароль можно командой
Re: Mysql backup failed
Posted: Thu Jun 06, 2013 2:30 pm
by XakRu
создание/ удаление работает корректно.
Но вот бэкапы нет
Пароль менялся через mysql_secure_installation.
Потом перезапустил мускуль.
А причиной всего этого был тест mysqltuner.pl Он проводил тест без запроса пароля. Меня это удивило.
А команда
впускало без пароля.
Сейчас получаю ошибку в логах бэкапа
Code: Select all
-- DB --
2013-06-06 05:10:12 mysql some_database
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Error: Connection failed
Дальше бэкап ничего не далет, т.е. стопорится.
После смены пароля столкнулся с проблемой что мускуль начинает плодиться, а точнее mysql_safe процессы.
Code: Select all
Version: '5.5.31-cll' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Atomicorp
130531 23:45:11 [Warning] IP address '218.93.205.140' could not be resolved: Name or service not known
130601 7:57:20 [Warning] IP address '66.199.146.70' could not be resolved: Name or service not known
130602 9:10:55 [Warning] IP address '173.208.202.182' could not be resolved: Name or service not known
130603 19:43:50 [Warning] IP address '218.8.245.123' could not be resolved: Name or service not known
130604 7:01:41 [Warning] IP address '118.119.254.21' could not be resolved: Name or service not known
130604 7:25:05 [Warning] IP address '173.208.240.203' could not be resolved: Name or service not known
130605 13:30:10 [Warning] IP address '222.73.86.69' could not be resolved: Name or service not known
130605 14:57:00 [Note] /usr/libexec/mysqld: Normal shutdown
130605 14:57:00 [Note] Event Scheduler: Purging the queue. 0 events
130605 14:57:00 InnoDB: Starting shutdown...
130605 14:57:02 InnoDB: Shutdown completed; log sequence number 951248779
130605 14:57:02 [Note] /usr/libexec/mysqld: Shutdown complete
130605 14:57:02 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
130605 14:57:03 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130605 14:57:03 [Note] libgovernor.so not found
130605 14:57:03 [Note] Plugin 'FEDERATED' is disabled.
130605 14:57:03 InnoDB: The InnoDB memory heap is disabled
130605 14:57:03 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130605 14:57:03 InnoDB: Compressed tables use zlib 1.2.3
130605 14:57:03 InnoDB: Using Linux native AIO
130605 14:57:03 InnoDB: Initializing buffer pool, size = 128.0M
130605 14:57:03 InnoDB: Completed initialization of buffer pool
130605 14:57:03 InnoDB: highest supported file format is Barracuda.
130605 14:57:03 InnoDB: Waiting for the background threads to start
130605 14:57:04 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130605 14:57:04 [Note] libgovernor.so not found
130605 14:57:04 [Note] Plugin 'FEDERATED' is disabled.
130605 14:57:04 InnoDB: The InnoDB memory heap is disabled
130605 14:57:04 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130605 14:57:04 InnoDB: Compressed tables use zlib 1.2.3
130605 14:57:04 InnoDB: Using Linux native AIO
130605 14:57:04 InnoDB: Initializing buffer pool, size = 128.0M
130605 14:57:04 InnoDB: Completed initialization of buffer pool
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
130605 14:57:04 InnoDB: Retrying to lock the first data file
130605 14:57:04 InnoDB: 5.5.31 started; log sequence number 951248779
130605 14:57:04 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130605 14:57:04 [Note] - '0.0.0.0' resolves to '0.0.0.0';
130605 14:57:04 [Note] Server socket created on IP: '0.0.0.0'.
130605 14:57:04 [Note] Event Scheduler: Loaded 0 events
130605 14:57:04 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.31-cll' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Atomicorp
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
и полмиллиона строк
Code: Select all
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
я в прямом смысле.
мускуль оказывается еще был открыт во внешку. =)
Логи крона
Code: Select all
Jun 6 14:45:01 CentOS-63-64-minimal CROND[16303]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 14:50:01 CentOS-63-64-minimal CROND[20381]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 14:50:01 CentOS-63-64-minimal CROND[20380]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 6 14:55:01 CentOS-63-64-minimal CROND[24005]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:00:01 CentOS-63-64-minimal CROND[27711]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:00:01 CentOS-63-64-minimal CROND[27710]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-queue backup)
Jun 6 15:00:01 CentOS-63-64-minimal CROND[27712]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 6 15:01:01 CentOS-63-64-minimal CROND[28776]: (root) CMD (run-parts /etc/cron.hourly)
Jun 6 15:01:01 CentOS-63-64-minimal run-parts(/etc/cron.hourly)[28776]: starting 0anacron
Jun 6 15:01:01 CentOS-63-64-minimal run-parts(/etc/cron.hourly)[28785]: finished 0anacron
Jun 6 15:01:01 CentOS-63-64-minimal run-parts(/etc/cron.hourly)[28776]: starting awstats
Jun 6 15:01:01 CentOS-63-64-minimal run-parts(/etc/cron.hourly)[28795]: finished awstats
Jun 6 15:01:01 CentOS-63-64-minimal run-parts(/etc/cron.hourly)[28776]: starting freshclam
Jun 6 15:01:03 CentOS-63-64-minimal run-parts(/etc/cron.hourly)[28818]: finished freshclam
Jun 6 15:05:01 CentOS-63-64-minimal CROND[31839]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:10:01 CentOS-63-64-minimal CROND[3038]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:10:01 CentOS-63-64-minimal CROND[3039]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 6 15:15:01 CentOS-63-64-minimal CROND[6662]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:20:01 CentOS-63-64-minimal CROND[10739]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:20:01 CentOS-63-64-minimal CROND[10740]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 6 15:25:01 CentOS-63-64-minimal CROND[14364]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:30:01 CentOS-63-64-minimal CROND[18019]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-queue backup)
Jun 6 15:30:01 CentOS-63-64-minimal CROND[18020]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:30:01 CentOS-63-64-minimal CROND[18021]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 6 15:35:01 CentOS-63-64-minimal CROND[22677]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:37:42 CentOS-63-64-minimal crond[1560]: (CRON) STARTUP (1.4.4)
Jun 6 15:37:42 CentOS-63-64-minimal crond[1560]: (CRON) INFO (running with inotify support)
Jun 6 15:40:01 CentOS-63-64-minimal CROND[1676]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:40:01 CentOS-63-64-minimal CROND[1677]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jun 6 15:45:01 CentOS-63-64-minimal CROND[1884]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:50:01 CentOS-63-64-minimal CROND[2075]: (admin) CMD (sudo /usr/local/vesta/bin/v-update-sys-rrd)
Jun 6 15:50:01 CentOS-63-64-minimal CROND[2076]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Далее рестарт сервера......
Re: Mysql backup failed
Posted: Thu Jun 06, 2013 7:33 pm
by skid
Команда, которую вы привели неточная
mysql -u root -H127.0.0.1
Большая H задает вывод в формате html
хост задается через маленькую эйч
Для удобства работы в консоли, во время установки панели, в файл
/root/.my.cnf добавляется сгенерированный пароль. Это позволяет пользоваться командами mysql, mysqladmin, mysqlcheck, mysqldump и mysqltuner.pl без ввода пароля. Тем не менее пароль установлен и без него зайти нельзя, как удаленно, так и локально.
Если вы можете входить на сервер использую консольную команду mysql без ввода пароля, значит пароль, сохраненный в /root/.my.cnf все еще актуален. Обновите /usr/local/vesta/conf/mysql.conf и проверьте бэкапы снова.
Re: Mysql backup failed
Posted: Thu Jun 06, 2013 9:15 pm
by XakRu
Да, в команде на форуме опечатался. в консоли всё верно. Уставший был.
сегодня получил письмо, что сервера предоставляющие управление виртуальными или выделенными серверами были скомпрометированы и был найден бэкдор. Всем кто имеет сервера на Hetzner необходимо приепринять жесткие ограничения и мониторить активность на сервере. Проушу принять к сведению. ПРошу прощения, еесли не туда пишу
Re: Mysql backup failed
Posted: Thu Jun 06, 2013 9:57 pm
by skid
Да, действительно. На
хабре появился топик с последними новостями.
Re: Mysql backup failed
Posted: Fri Jun 07, 2013 6:40 am
by XakRu
вчера решил внести изменения в my.cnf.
Странный итог, потерлись бд после рестарта мускуля.
Выполнял конечно я всё с выключенным сервисом.
Отдельно спасибо за восстановление из бэкапа. Замечательная вещь, очень удобно реализовано. Нажал кнопочку, жди, бд восстанавливается. =)
В итоге вернул всё как было в my.cnf
Настройки касались innodb
Re: Mysql backup failed
Posted: Fri Jun 07, 2013 7:07 am
by XakRu
как оказалось бд порушились из-за того что раскомментил
#innodb_data_home_dir = /var/lib/mysql
#innodb_data_file_path = ibdata1:10M:autoextend