1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
* MYSQL WON'T START OR STOP?
============================
The most common reasons the server does not start are:
- AppArmor is enforced and something is wrong with the confinement profile.
- Process supervisor scripts (init, systemd etc) fail to execute normally.
- The configuration in /etc/mysql/... is wrong and prevents server from running.
First check the contents of syslog (or systemd journal) and then check the
logs at /var/log/mysql/ for any hints of what might be wrong.
Examples:
grep mysql /var/log/syslog
journalctl -u mariadb
* NEW SERVICE NAME, PROCESS AND BINARY NAMES IN MARIADB 10.5
============================================================
Starting form MariaDB 10.5, the default SysV init service name is 'mariadb',
and can be accessed at path /etc/init.d/mariadb. The alias 'mysql' is only
created on upgrades.
On systemd services both 'mariadb' and alias 'mysql' are available all the time.
Note that the new daemon name is 'mariadbd' instead of 'mysqld' and also most
of the binaries have been renamed to mariadb-something, yet the old mysql-something
name has been kept as a symbolic link to the new name for backwards compatibility.
* NATIVE SYSTEMD SERVICE INTRODUCED IN MARIADB 10.1
===================================================
From MariaDB 10.1 onward the upstream mariadb.service and mariadb@.service are
used to provide the full systemd experience. Some features available in
traditional /etc/init.d/mysql have been changed. For details see
https://mariadb.com/kb/en/mariadb/systemd/
* MIXING PACKAGES FROM MARIADB.ORG AND OFFICIAL DEBIAN REPOSITORIES
==================================================================
Please note that the MariaDB packaging in official Debian repositories are of
a completely new generation compared to the legacy packaging used in MariaDB.org
repositories. You cannot mix and match MariaDB 10.1 packages from official
Debian (or Ubuntu) repositories with packages from MariaDB.org repositories.
Packages from the MariaDB.org repositories include the revision string '+maria'.
If a MariaDB.org repository is enabled, learn to use apt pinning properly.
Please do not file bugs in Debian regarding packages with '+maria' in the
revision string.
* ROOT USER AUTHENTICATION VIA UNIX SOCKET
==========================================
On new installs no root password is set and no debian-sys-maint user is
created anymore. Instead the MariaDB root account is set to be authenticated
using the Unix socket, e.g. any mysqld invocation by root or via sudo will
let the user see the mysqld prompt.
You may never ever delete the mysql user "root". Although it has no password
is set, the unix_auth plugin ensure that it can only be run locally as the root
user.
The credentials in /etc/mysql/debian.cnf specify the user which is used by the
init scripts to stop the server and perform log rotation. This used to be the
debian-sys-maint user which is no longer used as root can run directly.
If you have start/stop problems make sure that the /etc/mysql/debian.cnf file
specifies the root user and no password. In the long run please stop using that
file as is has been obsoleted.
* MARIADB IS SECURE BY DEFAULT
==============================
MariaDB in Debian is secure by default, because:
- It only listens to the localhost socket and cannot be accessed remotely unless
the sysadmin changes the configuration in /etc/mysql to allow so.
- There is no debian-sys-maint with password in /etc/mysql/debian.cnf anymore.
- There is no root account with password anymore. The system admin needs to
create one themselves if they need it. With no password, all issues related
to password management and password leaking are gone. Sysadmins can access
the database without a password simply by running 'sudo mysql' thanks to
socket based authentication, which detects the system root user and allows
them to use the mysqld console as the mysql root user. For details see
https://www.slideshare.net/ottokekalainen/less-passwords-more-security-unix-socket-authentication-and-other-mariadb-hardening-tips
- There is no test database nor test accounts in the out-of-the-box Debian
installation.
Therefore there is also no need to run the 'mysql_secure_installation'. In fact
that script will try to do things that are already prevented, and might fail.
* WHAT TO DO AFTER UPGRADES
===========================
The privilege tables are automatically updated so all there is left is read
the release notes on https://mariadb.com/kb/en/release-notes/ to see if any
changes affect custom apps.
There should not be any need to run 'mysql_upgrade' manually, as the upgrade
scripts do that automatically.
* WHAT TO DO AFTER INSTALLATION
===============================
The MySQL manual describes certain steps to do at this stage in a separate
chapter. They are not necessary as the Debian packages does them
automatically.
There should not be any need to run 'mysql_install_db' manually, as the install
scripts do that automatically.
The only thing that is left over for the admin is
- creating new users and databases
- read the rest of this text
* NETWORKING
============
For security reasons, the Debian package has enabled networking only on the
loop-back device using "bind-address" in /etc/mysql/my.cnf. Check with
"netstat -tlnp" where it is listening. If your connection is aborted
immediately check your firewall rules or network routes.
* WHERE IS THE DOCUMENTATION?
=============================
https://mariadb.com/kb
* PASSWORDS
===========
It is recommended you create additional admin users for your database
administration needs in addition to the default root user.
If your local Unix account is the one you want to have local super user
access on your database with you can create the following account that will
only work for the local Unix user connecting to the database locally.
sudo /usr/bin/mysql -e "GRANT ALL ON *.* TO '$USER'@'localhost' IDENTIFIED VIA unix_socket WITH GRANT OPTION"
To create a local machine account username=USERNAME with a password:
sudo /usr/bin/mysql -e "GRANT ALL ON *.* TO 'USERNAME'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION"
To create a USERNAME user with password 'password' admin user that can access
the DB server over the network:
sudo /usr/bin/mysql -e "GRANT ALL ON *.* TO 'USERNAME'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION"
Scripts should run as a user who have the required grants and be identified via unix_socket.
It is wise to run scripts as the "mysql" system user. Like root,
mysql@localhost is created by default to have all privileges in MariaDB
and to use unix_socket authentication. But scripts running under "mysql"
won't have system-wide root so they won't be able to corrupt your system.
If you are too tired to type the password in every time and unix_socket auth
doesn't suit your needs, you can store it in the file $HOME/.my.cnf. It should
be chmod 0600 (-rw------- username usergroup .my.cnf) to ensure that nobody else
can read it. Every other configuration parameter can be stored there, too.
For more information in the MariaDB manual in/usr/share/doc/mariadb-doc or
https://mariadb.com/kb/en/configuring-mariadb-with-mycnf/.
* FURTHER NOTES ON REPLICATION
==============================
If the MySQL server is acting as a replication slave, you should not
set --tmpdir to point to a directory on a memory-based file system or to
a directory that is cleared when the server host restarts. A replication
slave needs some of its temporary files to survive a machine restart so
that it can replicate temporary tables or LOAD DATA INFILE operations. If
files in the temporary file directory are lost when the server restarts,
replication fails.
* DOWNGRADING
=============
Unsupported. Period.
You might get lucky downgrading a few minor versions without issued. Take a
backup first. If you break it you get to keep both pieces. Do a restore from
backup or upgrade to the previous version.
If doing a major version downgrade, take a mysqldump/maria-backup consistent
backup using the current version and reload after downgrading and purging
existing databases.
* BACKUPS
=========
Backups save jobs. Don't get caught without one.
|
