1 files changed, 204 insertions, 0 deletions
diff --git a/debian/mariadb-server.README.Debian b/debian/mariadb-server.README.Debian
new file mode 100644
index 00000000..6042249a
--- /dev/null
+++ b/debian/mariadb-server.README.Debian
@@ -0,0 +1,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.