Commit 61e31aa5 authored by Otto Kekäläinen's avatar Otto Kekäläinen

Remove files from debian/* that are unrelevant for this upstream repo

 * README and NEWS are very old and mostly plain wrong and not needed
 * Lintian-overrides are relevant only in actual Debian QA systems
 * watch file was plain wrong and anyway relevant only in downstream distros
parent 6809fdb7
###########################
## FIXME for 5.1 ##
###########################
* put this trigger-recreation thing into the init scripts -- what?!
###########################################################################
# Here are some information that are only of interest for the current and #
# following Debian maintainers of MySQL. #
###########################################################################
The debian/ directory is under SVN control, see debian/control for URL.
#
# Preparing a new version
#
The new orig.tar.gz (without non-free documentation) is created in /tmp/ when
running this command:
debian/rules get-orig-source
#
# mysqlreport
#
The authors e-mail address is <public@codenode.com>.
#
# Remarks to dependencies
#
libwrap0-dev (>= 7.6-8.3)
According to bug report 114582 where where build problems on
IA-64/sid with at least two prior versions.
psmisc
/usr/bin/killall in the initscript
zlib1g in libmysqlclient-dev:
"mysql_config --libs" ads "-lz"
Build-Dep:
debhelper (>=4.1.16):
See po-debconf(7).
autoconf (>= 2.13-20), automake1.7
Try to get rid of them.
#
# Remarks to the start scripts
#
## initscripts rely on mysqladmin from a different package
We have the problem that "/etc/init.d/mysql stop" relies on mysqladmin which
is in another package (mysql-client) and a passwordless access that's maybe
only available if the user configured his /root/.my.cnf. Can this be a problem?
* normal mode: not because the user is required to have it. Else:
* purge/remove: not, same as normal mode
* upgrade: not, same as normal mode
* first install: not, it depends on mysql-client which at least is unpacked
so mysqladmin is there (to ping). It is not yet configured
passwordles but if there's a server running then there's a
/root/.my.cnf. Anyways, we simply kill anything that's mysqld.
## Passwordless access for the maintainer scripts
Another issue is that the scripts needs passwordless access. To ensure this
a debian-sys-maint user is configured which has process and shutdown privs.
The file with the randomly (that's important!) generated password must be
present as long as the databases remain installed because else a new install
would have no access. This file should be used like:
mysqladmin --defaults-file=/etc/mysql/debian.cnf restart
to avoid providing the password in plaintext on a commandline where it would
be visible to any user via the "ps" command.
## When to start the daemon?
We aim to give the admin full control on when MySQL is running.
Issues to be faced here:
OLD:
1. Debconf asks whether MySQL should be started on boot so update-rc.d is
only run if the answer has been yes. The admin is likely to forget
this decision but update-rc.d checks for an existing line in
/etc/runlevel.conf and leaves it intact.
2. On initial install, if the answer is yes, the daemon has to be started.
3. On upgrades it should only be started if it was already running, everything
else is confusing. Especiall relying on an debconf decision made month ago
is considered suboptimal. See bug #274264
Implementation so far:
prerm (called on upgrade before stopping the server):
check for a running server and set flag if necessary
preinst (called on initial install and before unpacking when upgrading):
check for the debconf variable and set flag if necessary
postinst (called on initial install and after each upgrade after unpacking):
call update-rc.d if debconf says yes
call invoce-rc.d if the flag has been set
Problems remaining:
dpkg-reconfigure and setting mysql start on boot to yes did not start mysql
(ok "start on boot" literally does not mean "start now" so that might have been ok)
NEW:
1. --- no debconf anymore for the sake of simplicity. We have runlevel.conf,
the admin should use it
2. On initial install the server is started.
3. On upgrades the server is started exactly if it was running before so the
runlevel configuration is irrelevant. It will be preserved by the mean of
update-rc.d's builtin check.
Implementation:
prerm (called on upgrade before stopping the server):
check for a running server and set flag if necessary
preinst (called on initial install and before unpacking when upgrading):
check for $1 beeing (initial) "install" and set flag
postinst (called on initial install and after each upgrade after unpacking):
call update-rc.d
call invoce-rc.d if the flag has been set
W: mysql-dfsg source: maintainer-script-lacks-debhelper-token debian/mysql-server.postinst
W: mysql-server: possible-bashism-in-maintainer-script postinst:68 'p{("a".."z","A".."Z",0..9)[int(rand(62))]}'
......@@ -12,7 +12,6 @@ usr/bin/mysqlreport
usr/bin/mysqlshow
usr/bin/mysqlslap
usr/bin/mysql_waitpid
usr/share/lintian/overrides/mariadb-client-10.1
usr/share/man/man1/innotop.1
usr/share/man/man1/mysqlaccess.1
usr/share/man/man1/mysqladmin.1
......
mariadb-client-5.3: package-has-a-duplicate-relation
mariadb-client-5.3: wrong-name-for-upstream-changelog usr/share/doc/mariadb-client-5.3/changelog.innotop.gz
mariadb-client-5.3: pkg-not-in-package-test innotop
mysql-dfsg-5.1 (5.1.38-1) unstable; urgency=low
* Please read http://dev.mysql.com/doc/refman/5.1/en/upgrading-from-5-0.html
* Make sure to do a REPAIR TABLE on all tables that use UTF-8 and have a
FULLTEXT index.
-- Christian Hammers <ch@debian.org> Sat, 4 Jul 2009 02:31:21 +0200
mysql-dfsg-5.0 (5.1.14beta-2) unstable; urgency=low
* The BerkeleyDB Storage Engine is no longer supported. If the options
have-bdb or skip-bdb are found, MySQL will not start. If you have BDB
tables, you should change them to use another storage engine before
upgrading to 5.1.
-- Monty Taylor <mordred@inaugust.com> Thu, 18 Jan 2007 12:28:21 -0800
mysql-dfsg-5.0 (5.0.45-2) unstable; urgency=low
* Binary logging is now disabled by default. If you really need it (e.g. on
a replication master), remove the comment from the log_bin line in my.cnf.
-- Norbert Tretkowski <nobse@debian.org> Sat, 10 Nov 2007 16:26:35 +0100
mysql-dfsg-5.0 (5.0.18-9) unstable; urgency=low
* Rotation of the binary logs is now configured in /etc/mysql/my.cnf with
"expire-logs-days" which defaults to 20 days. The old file
/etc/mysql/debian-log-rotate.conf should be removed together with
/etc/cron.daily/mysql-server after this value has been adjusted. Note that
the old variable defined the number of files whereas the new one defines
a time span in days.
-- Christian Hammers <ch@debian.org> Tue, 24 Jan 2006 22:18:21 +0100
* MYSQL WON'T START OR STOP?:
=============================
You may never ever delete the special mysql user "debian-sys-maint". This
user together with the credentials in /etc/mysql/debian.cnf are used by the
init scripts to stop the server as they would require knowledge of the mysql
root users password else.
So in most of the times you can fix the situation by making sure that the
debian.cnf file contains the right password, e.g. by setting a new one
(remember to do a "flush privileges" then).
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 are used by the
init scripts to stop the server and perform logrotation. So in most of the
time you can fix the situation by making sure that the /etc/mysql/debian.cnf
file specifies the root user and no password.
This used to be the debian-sys-maint user which is no longer used.
* WHAT TO DO AFTER UPGRADES:
============================
The privilege tables are automatically updated so all there is left is read
the changelogs on dev.mysql.com to see if any changes affect custom apps.
the release notes on https://mariadb.com/kb/en/release-notes/ to see if any
changes affect custom apps.
* WHAT TO DO AFTER INSTALLATION:
================================
......@@ -24,59 +26,51 @@ The only thing that is left over for the admin is
- creating new users and databases
- read the rest of this text
* DOWNGRADING TO 4.0 or 4.1:
============================
Unsupported. Period.
But if you do and get problems or make interesting experiences, mail me, it
might help others.
Ok, if you really want, I would recommend to "mysqldump --opt" all tables,
then purge 4.1, delete /var/lib/mysql, install 4.0 and insert the dumps. Be
carefully, though, with the "mysql" table, you might not simply overwrite that
one as the password for the mysql "debian-sys-maint" user is stored in
/etc/mysql/debian.cnf and needed by /etc/init.d/ to start mysql and check if
it's alive.
* SOME APPLICATION CAN NO LONGER CONNECT:
=========================================
This application is probably linked against libmysqlclient12 or below and
somebody has created a mysql user with new-style passwords.
The old_passwords=1 option in /etc/mysql/my.cnf might help. If not the
application that inserted the user has to be changed or the application that
tries to connect updated to libmysqlclient14 or -15.
* 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 see if "mysqld: all" or similar is in /etc/hosts.allow and read
hosts_access(5).
immediately check your firewall rules or network routes.
* WHERE IS THE DOCUMENTATION?:
==============================
Unfortunately due to licensing restrictions, debian currently not able
to provide the mysql-doc package in any format. For the most up to date
documentation, please go to http://dev.mysql.com/doc.
https://mariadb.com/kb
* PASSWORDS:
============
It is strongly recommended to set a password for the mysql root user (which
/usr/bin/mysql -u root -D mysql -e "update user set password=password('new-password') where user='root'"
/usr/bin/mysql -u root -e "flush privileges"
If you already had a password set add "-p" before "-u" to the lines above.
It is strongly recommended you create an admin users for your database
adminstration needs.
If your 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 have have the required grants and be identified via unix_socket.
If you are tired to type the password in every time or want to automate your
scripts you can store it in the file $HOME/.my.cnf. It should be chmod 0600
(-rw------- username username .my.cnf) to ensure that nobody else can read
it. Every other configuration parameter can be stored there, too. You will
find an example below and more information in the MySQL manual in
/usr/share/doc/mysql-doc or www.mysql.com.
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 username .my.cnf) to ensure that nobody else
can read it. Every other configuration parameter can be stored there, too.
ATTENTION: It is necessary, that a .my.cnf from root always contains a "user"
For more information in the MariaDB manual in/usr/share/doc/mariadb-doc or
https://mariadb.com/kb/en/configuring-mariadb-with-mycnf/.
ATTENTION: It is necessary, that a ~/.my.cnf from root always contains a "user"
line wherever there is a "password" line, else, the Debian maintenance
scripts, that use /etc/mysql/debian.cnf, will use the username
"debian-sys-maint" but the password that is in root's .my.cnf. Also note,
"root" but the password that is in root's .my.cnf. Also note,
that every change you make in the /root/.my.cnf will affect the mysql cron
script, too.
......@@ -85,19 +79,6 @@ script, too.
user = your-mysql-username
password = enter-your-good-new-password-here
* BIG_ROWS FOR EVEN MORE ROWS IN A TABLE:
=========================================
If you ever run out of rows in a table there is the possibility of building
the package with "-DBIG_ROWS" which, according to a MySQL employee on
packagers@lists.mysql.com should lead to a 64bit row index (I guess > 2^32
rows) but also to an approx. 5% performance loss.
* BerkeleyDB Storage Engine
===========================
Support for BerkeleyDB has been removed in 5.1, and consequently both the
have-bdb and skip-bdb configuration options will cause the server to fail.
Removing the options from /etc/mysql/my.cnf will fix this problem.
* FURTHER NOTES ON REPLICATION
===============================
If the MySQL server is acting as a replication slave, you should not
......@@ -107,3 +88,19 @@ 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/mydumpber consistent
backup using the current version and reload after downgrading and purging
existing databases.
* BACKUPS
============================
Backups save jobs. Don't get caught without one.
......@@ -58,7 +58,6 @@ usr/bin/wsrep_sst_xtrabackup-v2
usr/share/doc/mariadb-server-10.1/mysqld.sym.gz
usr/share/doc/mariadb-server-10.1/INFO_SRC
usr/share/doc/mariadb-server-10.1/INFO_BIN
usr/share/lintian/overrides/mariadb-server-10.1
usr/share/man/man1/msql2mysql.1
usr/share/man/man1/myisamchk.1
usr/share/man/man1/myisam_ftdump.1
......
mariadb-server-10.1: command-with-path-in-maintainer-script postinst
mariadb-server-10.1: possible-bashism-in-maintainer-script postinst:81 'p{("a".."z","A".."Z",0..9)[int(rand(62))]}'
mariadb-server-10.1: possible-bashism-in-maintainer-script preinst:33 '${cmd/ */}'
mariadb-server-10.1: statically-linked-binary ./usr/bin/mysql_tzinfo_to_sql
mariadb-server-10.1: statically-linked-binary ./usr/sbin/mysqld
etc/mysql/my.cnf
usr/share/mysql-common/internal-use-only
usr/share/lintian/overrides/mysql-common
script-not-executable ./usr/share/mysql-common/internal-use-only/_etc_init.d_mysql
script-not-executable ./usr/share/mysql-common/internal-use-only/_etc_mysql_debian-start
......@@ -183,12 +183,6 @@ install: build
# mariadb-test
mv $(TMP)/usr/mysql-test $(TMP)/usr/share/mysql
# lintian overrides
mkdir -p $(TMP)/usr/share/lintian/overrides/
cp debian/mysql-common.lintian-overrides $(TMP)/usr/share/lintian/overrides/mysql-common
cp debian/mariadb-server-10.1.lintian-overrides $(TMP)/usr/share/lintian/overrides/mariadb-server-10.1
cp debian/mariadb-client-10.1.lintian-overrides $(TMP)/usr/share/lintian/overrides/mariadb-client-10.1
# For 5.0 -> 10.1 transition
d=$(TMP)/usr/share/mysql-common/internal-use-only/; \
mkdir -p $$d; \
......
maintainer-script-lacks-debhelper-token debian/mariadb-server-10.1.postinst
maintainer-script-lacks-debhelper-token debian/mariadb-server-10.1.postrm
version=3
opts="uversionmangle=s/-(rc|beta)/$1/" \
ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/www.mysql.com/Downloads/MySQL-5.1/mysql-([\d\.]*(?:-beta|-rc)?).tar.gz debian
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment