The systemd team committed mysql-init-scripts-2.0_pre1-r4 with a helper mysqld-prepare-db-dir. Included in that helper is this snippet attempts to do what 'emerge --config' is really supposed to handle: # Make the data directory if [ ! -d "$datadir/mysql" ] ; then # First, make sure $datadir is there with correct permissions # (note: if it's not, and we're not root, this'll fail ...) if [ ! -e "$datadir" -a ! -h "$datadir" ] then mkdir -p "$datadir" || exit 1 fi chown "$myuser:$mygroup" "$datadir" chmod 0755 "$datadir" [ -x /sbin/restorecon ] && /sbin/restorecon "$datadir" # Now create the database echo "Initializing MySQL database" /usr/share/mysql/scripts/mysql_install_db \ --datadir="$datadir" --user="$myuser" --basedir="/usr" ret=$? if [ $ret -ne 0 ] ; then echo "Initialization of MySQL database failed." >&2 echo "Perhaps /etc/mysql/my.cnf is misconfigured." >&2 # Clean up any partially-created database files if [ ! -e "$datadir/mysql/user.frm" ] ; then rm -rf "$datadir"/* fi exit $ret fi # In case we're running as root, make sure files are owned properly chown -R "$myuser:$mygroup" "$datadir" fi In the openrc init, it simply says: if [ ! -d "${datadir}"/mysql ] ; then eerror "You don't appear to have the mysql database installed yet." eerror "Please run /usr/bin/mysql_install_db to have this done..." return 1 fi I also feel it is potentially dangerous to 'rm -fr "$datadir"/*' in any init system. Reproducible: Always
This has been taken directly from [1]. I think that the rationale for the rm -rf is this: if DATADIR/mysql does not exist, mysql is certainly not configured to run, thus DATADIR is assumed to contain invalid data. However, I agree that the `rm` may be dangerous. emerge --config cannot be reliably called from a systemd unit nor from an init script (for various reasons). I actually think that the --config approach is just wrong and things like that should be left outside the package manager. For this reason, I suggest to drop --config and use a saner approach that can be used inside init scripts/systemd units. About the wording problem, i don't see any problem with fixing it. [1] http://pkgs.fedoraproject.org/cgit/community-mysql.git/tree/mysqld-prepare-db-dir
Then, I guess that dropping the "rm " would be enough (I guess people will try to remove that dir manually if they have cruft there :/)
(In reply to Pacho Ramos from comment #2) > Then, I guess that dropping the "rm " would be enough (I guess people will > try to remove that dir manually if they have cruft there :/) yes please, in case rm -rf "$datadir"/mysql/ would be the least minimum
mv(1) is certainly safer (perhaps coupled with mktemp -d). In other words, moving the current directory to another in the same parent directory prefixing it with a random (thus unique) string.
I think we could simply leave people fix it as they will have a message from: echo "Initialization of MySQL database failed." >&2 echo "Perhaps /etc/my.cnf is misconfigured." >&2 Warning them, no?
(In reply to Pacho Ramos from comment #5) > I think we could simply leave people fix it as they will have a message from: > echo "Initialization of MySQL database failed." >&2 > echo "Perhaps /etc/my.cnf is misconfigured." >&2 > > Warning them, no? Will simply drop the rm call then in a week if nobody comes with a better solution
systemd: Why did you duplicate functionality from --config to your script, and very poorly at that? It's NOT acceptable to try and configure MySQL automatically without user interaction. Just because a user might have a USE=-minimal MySQL installed on their system, doesn't mean they want it running either: You need a USE=-minimal build to get the USE=embedded libmysqld, and that doesn't require you to run mysqld at all, just have it present on your system (the library will invoke it for the embedded usage as needed). Even if you were going to try and configure on start, there is a LOT more code that needs to be run to prepare the database. mysql_install_db is the very bare minimum. You're not setting ANY of the passwords to secure the install, or populating the timezone or helper tables. There are also cases where your code will completely fail because those options to mysql_install_db are really important. The mysql-v2.eclass explicitly contains the pkg_config function to set up the entire mysql safely and reliably, and you're missing ALL of that additional code. I'd even strongly suggest that anybody that's got a mysqld configured by your code now needs to have a GLSA for your insecure deploy of MySQL :-(. If the database is installed with USE=minimal: mysql_install_db won't exist, so the rm -rf will be triggered, and all contents of datadir will be removed. If mysql/ is not yet created, but explicit subdirectories were created by the sysadmin for binlog/relaylog. Your code could remove them. There's only two choices I'll accept: 1. Remove mysqld-prepare-db-dir, tell the sysadmin to run emerge --config. 2. Create a NON-systemd script with the complete contents of pkg_config (be sure to include all hooks into mysql_fx, make pkg_config run said script. Tell the sysadmin to run new script. #1 is my preference. You have 24 hours to respond, and then I'm going to implement #1.
(In reply to Robin Johnson from comment #7) [...] At first thanks a lot for explanation and proposing solutions [...] > There's only two choices I'll accept: > 1. Remove mysqld-prepare-db-dir, tell the sysadmin to run emerge --config. > 2. Create a NON-systemd script with the complete contents of pkg_config (be > sure to include all hooks into mysql_fx, make pkg_config run said script. > Tell the sysadmin to run new script. > > #1 is my preference. > From what I have seen in eclass, #1 also looks good to me > You have 24 hours to respond, and then I'm going to implement #1. I have to admit that I got a bit angry when I read this really short timeout as I could have easily not seen it depending on the amount of work I have in real life every day. Would really appreciate if next time you could give a bit longer timeout to reply (around 3 days or so?)
Well, just one thing comes to my mind: haven't I told you so? Services are not the place to set up anything.
I have removed the offending script and (hopefully) all of its invocations. I have revbumped the ebuild to ensure people get rid of it. However, the systemd files need major refactoring since they are obviously ugly copy-paste from Fedora.
(In reply to Michał Górny from comment #9) > Well, just one thing comes to my mind: haven't I told you so? Services are > not the place to set up anything. +1 https://bugs.gentoo.org/show_bug.cgi?id=466084#c13
(In reply to Michał Górny from comment #10) [...] > However, the systemd files need major refactoring since they are obviously > ugly copy-paste from Fedora. Apart of dropping the configuration related comments, what else is wrong? I am for comparing: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/mysql-init-scripts/files/mysqld.service?view=markup and: http://svnweb.mageia.org/packages/cauldron/mysql/releases/5.5.15/3.mga2/SOURCES/mysqld.service?view=markup My only doubts: - The need of --basedir=/usr option - The Restart=always from Mageia :/ Thanks
Comments would be a first step, yes. Especially this one: > # Note: we set --basedir to prevent probes that might trigger SELinux alarms, > # per bug #547485 Bug where? It's not a Gentoo bug, so full URI needed. > ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID I'd place that in /usr/lib/mysql or something similar.
@robbat2: People installing mysql know that they *have* to configure access credentials. In my opinion, having mysql automatically provisioned by the init script/systemd unit is way better than creating and mantaining a huge pile of custom/distro scripts sunk into an eclass and requiring to run non-trivial emerge --config magic. I am the one who thinks that pkg_config() is a plainly wrong hack.
(In reply to Fabio Erculiani from comment #14) > @robbat2: > People installing mysql know that they *have* to configure access > credentials. In my opinion, having mysql automatically provisioned by the > init script/systemd unit is way better than creating and mantaining a huge > pile of custom/distro scripts sunk into an eclass and requiring to run > non-trivial emerge --config magic. I am the one who thinks that pkg_config() > is a plainly wrong hack. Fabio, we disagree on this. I don't want any sysadmin being surprised by the init system trying to be "too clever". Configuring package / package daemons is something that clearly lies on the sysadmin side and not on the packaging side.
(In reply to Fabio Erculiani from comment #14) > @robbat2: > People installing mysql know that they *have* to configure access > credentials. In my opinion, having mysql automatically provisioned by the > init script/systemd unit is way better than creating and mantaining a huge > pile of custom/distro scripts sunk into an eclass and requiring to run > non-trivial emerge --config magic. I am the one who thinks that pkg_config() > is a plainly wrong hack. People have the right to forget. People have the right to get distracted. And last thing people need is something trying to be half-smart and do some random, partial configuration in the name of being helpful. And worse than that, any kind of automatic configuration on startup is fragile by definition. If my system is screwed up for some reason, I don't want the service to start. I want it to fail, not to recreate files over an unmounted filesystem, for example.
Then please also consider dropping all the pkg_config() code and let users use upstream tools only. Bonus points if you eventually have them installed in a more standard location (like mysql_install_db), like other major distros do. "trying to be half-smart" is what pkg_config() and the rest of the machinery do, IMHO. Anyway, the proposed changes went through bug #466084 and nobody raised any objections.
(In reply to Michał Górny from comment #16) > (In reply to Fabio Erculiani from comment #14) > > @robbat2: > > People installing mysql know that they *have* to configure access > > credentials. In my opinion, having mysql automatically provisioned by the > > init script/systemd unit is way better than creating and mantaining a huge > > pile of custom/distro scripts sunk into an eclass and requiring to run > > non-trivial emerge --config magic. I am the one who thinks that pkg_config() > > is a plainly wrong hack. > > People have the right to forget. People have the right to get distracted. > And last thing people need is something trying to be half-smart and do some > random, partial configuration in the name of being helpful. > > And worse than that, any kind of automatic configuration on startup is > fragile by definition. If my system is screwed up for some reason, I don't > want the service to start. I want it to fail, not to recreate files over an > unmounted filesystem, for example. Then fix the script that does the initialization and make it better. No?
(In reply to Jorge Manuel B. S. Vicetto from comment #15) [...] > Configuring package / package daemons is > something that clearly lies on the sysadmin side and not on the packaging > side. Yes, you mentioned "packaging side", and that's what the mysql eclass pkg_config() does (it's in the packaging side!). Why did we end up with this config thing instead of telling people to use upstream supported tools for initializing DATADIR?
pkg_config wraps mysql_install_db to make it usable and safe for all Gentoo circumstances. Esp running multiple instances of MySQL on the same machine, and ensuring that it works in a higher percentage of the time (some options in your my.cnf lead to needing to pass --skip-OPT to mysql_install_db). I'll consider moving the contents of pkg_config to a seperate script, but I'm still going to direct sysadmins to that script, and not mysql_install_db. Debian does similar with their mysql-server package.
+*mysql-init-scripts-2.0_pre1-r6 (21 Sep 2013) + + 21 Sep 2013; Pacho Ramos <pacho@gentoo.org> + +mysql-init-scripts-2.0_pre1-r6.ebuild, + -mysql-init-scripts-2.0_pre1-r5.ebuild, files/mysqld.service, + files/mysqld_at.service: + Cleanup service files (#483526) +
