Application: MySQL server.
# aptitude install mysql-server mysql-client php5-mysql
Конфигурационный файл MySQL находится по адресу "/etc/mysql/my.cnf". Откорректируем ряд параметров и защитим конфигурацию от несанкционированного чтения или изменения:
Для работы на "localhost" сервер MySQL готов уже с настройками "по умолчанию", разве что стоит принудительно указать кодировку схем путём включения директивы "default-character-set=utf8" во все используемые в работе сервера блоки:
.....
[client]
default-character-set=utf8
...
[mysqld]
default-character-set=utf8
....
[client]
default-character-set=utf8
...
[mysqld]
default-character-set=utf8
....
Перезагрузим MySQL для применения внесённых нам изменений в конфигурационных файлах:
# /etc/init.d/mysql restart
Убедится в том, что мы не зря потыкали кнопки, устанавливая кодировку "по умолчанию" можно в командной строке клиента MySQL:
# mysql -h localhost -u root -p
mysql> show variables;
mysql> quit;
mysql> show variables;
mysql> quit;
Вывод вроде следующего покажет нам состояние переменных окружения:
+---------------------------+------------------+
| Variable_name | Value |
+---------------------------+------------------+
....
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| collation_connection | utf8_general_ci |
| collation_database | utf8_general_ci |
| collation_server | utf8_general_ci |
.....
| Variable_name | Value |
+---------------------------+------------------+
....
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| collation_connection | utf8_general_ci |
| collation_database | utf8_general_ci |
| collation_server | utf8_general_ci |
.....
Если в процессе инсталляции сервера MySQL получилось так, что мы не задали пароль для суперпользователя - исправим это. В любом случае, перестраховаться и проверить, что там нам накрутил установщик в смысле создания пользователей не помешает. Пройдем в консоль клиента MySQL и наведем там порядок:
# mysql -h localhost -u root -p
mysql> use mysql;
mysql> select host,user from user;
mysql> use mysql;
mysql> select host,user from user;
Получим нечто вроде следующего:
+-----------+------------------+
| host | user |
+-----------+------------------+
| 127.0.0.1 | root |
| localhost | root |
| localhost | debian-sys-maint |
+-----------+------------------+
| host | user |
+-----------+------------------+
| 127.0.0.1 | root |
| localhost | root |
| localhost | debian-sys-maint |
+-----------+------------------+
Мы видим несколько записей, описывающих свойства одного и того же супер-пользователя "root" для хостов, фактически являющихся синонимами "localhost" и являющихся избыточными. Так же, мы наблюдаем запись "debian-sys-maint", которая лично мне не нравится. Наведем порядок:
mysql> delete from user where host='127.0.0.1' and user='root';
При взгляде на привилегии пользователя СУБД "debian-sys-maint", где явно видно, что ему разрешено буквально все, грустнеется. Пароль этого пользователя указан в специфичном для Debian конфигурационном файле управления СУБД "/etc/mysql/debian.cnf" в открытом виде и уязвимость или небрежность настройки прав пользователей сервера в целом, позволяющая им читать содержимое директории "/etc" делает для нас безопасность пустым звуком. Как "дебиановцы" такое себе позволяют - мне непонятно, испытываю шок и трепет.
Если мы удалим пользователя "debian-sys-maint", то скрипт управления сервером MySQL в "/etc/init.d/mysql" будет возмущаться невозможностью доступа к серверу для получения статуса, перезапуска и тому подобного. Мне это не представляется проблемой вообще, можно откорректировать стартовый скрипт на упрощённый режим работы, но пишут их предположительно умные люди и негоже эту работу так запросто отвергать. Мы не будем удалять этого пользователя, вмешиваясь в схему разработанную и поддерживаемую сборщиками дистрибутива, в существенно подрежем его в правах, оставив лишь функционал запуска и остановки сервера, единственно для чего он нам, собственно, и нужен:
mysql> update user set select_priv='N', insert_priv='N', update_priv='N', delete_priv='N', create_priv='N', drop_priv='N', reload_priv='Y', shutdown_priv='Y', process_priv='Y', file_priv='N', grant_priv='N', references_priv='N', index_priv='N', alter_priv='N', show_db_priv='Y', super_priv='N', create_tmp_table_priv='N', lock_tables_priv='N', execute_priv='N', repl_slave_priv='N', repl_client_priv='N' where user='debian-sys-maint';
После подрезания полномочий скрипт будет просит право на выборку данных с таблиц, но я, искренне не понимая, зачем ему это нужно, предлагаю игнорировать столь завышенные запросы.
Если нам обязательно нужно управление MySQL сервером со стороны, то добавим суперпользователя для удалённого входа с известным нам именем, отличающемся от "root" и сложным паролем:
mysql> grant all privileges on *.* to 'superuser.name'@'%' identified by 'strong.password' with grant option;
Так же, в случае обращений не только с "localhost", нужно в конфигурационном файле MySQL "/etc/mysql/my.cnf" указать на то, что нужно прослушивать ещё какие либо интерфейсы, например:
....
[mysqld]
bind-address = 0.0.0.0
....
[mysqld]
bind-address = 0.0.0.0
....
Забытый пароль проще всего восстановить, при возможности доступа в консоль MySQL, обновлением содержимого ячейки:
mysql> update user set password=password('user.password') where host='host.name' AND user='user.name';
После работы с привилегиями озаботимся некоторым повышением уровня сохранности данных.
В обязательном порядке включаем ведение "бинарного" журнала событий обновления баз данных MySQL. В случае "пропажи" или серьёзного повреждения файлов базы данных на фоне "внезапно" сильно устаревших резервных копий у нас будет шанс восстановить информацию из этих самых журналов с помощью утилиты "mysqlbinlog".
Создаем директорию размещения журнальных файлов:
# mkdir -p /var/lib/mysql/binlog
# chown -R mysql:mysql /var/lib/mysql/binlog
# chmod -R o-rwx /var/lib/mysql/binlog
# chown -R mysql:mysql /var/lib/mysql/binlog
# chmod -R o-rwx /var/lib/mysql/binlog
В конфигурационном файле "/etc/mysql/my.cnf" на первичном сервере MySQL приводим ряд параметров к следующему виду для включения журналирования операций:
....
[mysqld]
....
# Указываем MySQL создавать файлы журнальных логов в специальной директории
log_bin = /var/lib/mysql/binlog/binlog
# Указываем MySQL имя индексного файла состояния системы журналирования
log_bin_index = /var/lib/mysql/binlog/binlog.index
# Указываем MySQL хранить журнальные файлы не менее 120 дней
expire_log_days = 120
# Указываем MySQL максимальный размер отдельного журнального файла
max_binlog_size = 100M
....
[mysqld]
....
# Указываем MySQL создавать файлы журнальных логов в специальной директории
log_bin = /var/lib/mysql/binlog/binlog
# Указываем MySQL имя индексного файла состояния системы журналирования
log_bin_index = /var/lib/mysql/binlog/binlog.index
# Указываем MySQL хранить журнальные файлы не менее 120 дней
expire_log_days = 120
# Указываем MySQL максимальный размер отдельного журнального файла
max_binlog_size = 100M
....
Защитим директории с конфигурациями и данными от несанкционированного доступа:
# chown -R mysql:mysql /etc/mysql
# chmod -R o-rwx /etc/mysql
# chown -R mysql:mysql /var/lib/mysql
# chmod -R o-rwx /var/lib/mysql
# chmod -R o-rwx /etc/mysql
# chown -R mysql:mysql /var/lib/mysql
# chmod -R o-rwx /var/lib/mysql
Перезапускаем сервер:
# /etc/init.d/mysql restart