0004646: /var/opt/csw/mysql5/my.cnf ignored

Notes
(0008647) phil (reporter) 2011-01-01 00:02	ya, this is a major bug -- the preference is backwards. /var/opt/csw should always have precedence over /opt/csw/xxx, if both are checked.

(0008648) maciej (reporter) 2011-01-02 02:41	I did part of the work so far. The experimental catalog[1] contains packages which read /etc/opt/csw/mysql5/my.cnf. The postinstall script no longer writes to /opt/csw/mysql5 (where it does not have write access). There's a remaining problem that /opt/csw/mysql5/my.cnf still has precedence over /etc/opt/csw/mysql5/my.cnf, and a way to fix that would be to set MYSQL_HOME to something else than /opt/csw/mysql5. If you remove the old /opt/csw/mysql5/my.cnf file, or make an install on a clean system, you will be able to have a per-zone configuration. [1] http://buildfarm.opencsw.org/experimental.html#mysql-5.0 [^]

(0008649) james (reporter) 2011-01-02 10:31	Where would I set MYSQL_HOME if it's not in the conf file? The configuration really needs to be simpler and in one place. In a zone configuration you can't remove /opt/csw/mysql5/my.cnf. The solution is to not have a working copy in /opt. Put the master in /opt as a sample and copy it to /etc/opt on install where is becomes the working conf. Note the configurations should be in /etc not /var.

(0008650) maciej (reporter) 2011-01-02 13:26	In https://sourceforge.net/apps/trac/gar/changeset/12146 [^] MYSQL_HOME is exported in the startup script, which causes the /opt/csw/mysql5/my.cnf file to be ignored. mysqld sets MYSQL_HOME to BASEDIR if BASEDIR/my.cnf is present. However, this only happens when MYSQL_HOME is initially unset. If we give MYSQL_HOME a value beforehand, mysqld doesn't look into BASEDIR. I've created a new set of packages and put them into experimental. Please try them.

(0008653) phil (reporter) 2011-01-02 22:18	James: It should be mentioned that mysql documentation says that checking the datadir, is standard procedure. So if datadir is under /var, then it is valid and expected that the conf file could also be under /var in that directory. That being said, I think it should also check under /etc. Although in our case, /etc/opt/csw the script also claims that having it in datadir, is deprecated, however. To Maciej: I dont think that making the user set variables is a good idea. I think the better method is to fix the startup script to follow good orders for csw layout. This should work, whether the thing is started via smf, or "by hand". For _safe script fixes, I think we should just hard-patch the code block starting with if test -r "$MY_BASEDIR_VERSION/my.cnf" && test -r "$DATADIR/my.cnf" to be if test -r "/etc/opt/csw/my.cnf" ; then

(0008654) phil (reporter) 2011-01-02 22:26	James: It should be mentioned that mysql documentation says that checking the datadir, is standard procedure. So if datadir is under /var, then it is valid and expected that the conf file could also be under /var in that directory. That being said, I think it should also check under /etc. Although in our case, /etc/opt/csw the script also claims that having it in datadir, is deprecated, however. To Maciej: I dont think that making the user set variables is a good idea. I think the better method is to fix the startup script to follow good orders for csw layout. This should work, whether the thing is started via smf, or "by hand". For _safe script fixes, I think we should just hard-patch the code block starting with if test -r "$MY_BASEDIR_VERSION/my.cnf" && test -r "$DATADIR/my.cnf" to be just if test -r "/etc/opt/csw/my.cnf" ; then MYSQL_HOME=/etc/opt/csw elif test -r "$DATADIR/my.cnf" ; then MYSQL_HOME=$DATADIR fi erm.. except you seem to have configured it with /etc/opt/csw/mysql5, so okay, substitute that in, above?

(0008662) maciej (reporter) 2011-01-04 10:44	Phil: The startup script does not contain the block you mentioned (if test -r "$MY_BASEDIR_VERSION/my.cnf" && test -r "$DATADIR/my.cnf"). Where did you get this line from?

(0008666) maciej (reporter) 2011-01-04 22:18	Phil: Your proposed change can only take effect if you export the MYSQL_HOME variable, and if you reject the idea to use environment variables to configure MySQL, your proposal is internally inconsistent. I don't know if we can properly match MySQL's precedence pattern to ours. MySQL: /etc/my.cnf (global) ? SYSCONFDIR/my.cnf (global) ? $MYSQL_HOME/my.cnf (server) ? defaults-extra-file (runtime) ? ~/.my.cnf (user) OpenCSW: global_sysconfdir (global) ? sysconfdir (global) [ ? runtime ? user ] The only way that I can see that would work is to hard-patch the initial /etc/my.cnf to /opt/csw/mysql5/my.cnf. If you agree it's okay to export MYSQL_HOME, we can do the following in the startup script[1]: prefix="/opt/csw/mysql5" BASEDIR="${prefix}" MYSQL_VAR="/var${prefix}" sysconfdir="/etc${prefix}" if [ -r "${sysconfdir}/my.cnf" ]; then MYSQL_HOME="${MYSQL_VAR}" elif [ -r "${BASEDIR}/my.cnf" ]; then MYSQL_HOME="${BASEDIR}" fi export MYSQL_HOME I think that this is what achieves the right OpenCSW precedence. If /etc/opt/csw/mysql5/my.cnf is present, /opt/csw/mysql5/my.cnf is ignored. I've built updated packages with the above code, smoke-tested them and put them into experimental. Please test! [1] https://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/mysql5/branches/mysql-5.0.x/files/cswmysql5 [^]

(0008667) phil (reporter) 2011-01-04 23:31	Ah sorry. I was reading the wrong file. my "patch" was for mysqld_safe, not our init file. I think we would be best to focus on patching mysqld_safe, and keeping the init file as minimal as possible. I say that, because mysqld_safe is quite complex. Usually, for maintanance purposes, its a good idea to minimise complexity whereever possible. Having large complexity in TWO areas of the chain for startup, I would suggest is counterproductive for us.

(0008668) maciej (reporter) 2011-01-05 01:00	The problem with patching mysqld_safe is that it changes the documented way MySQL startup works. Imagine someone trying to debug a problem that is related to these settings. They will probably read MySQL documentation[1] and examine our startup script. If we patch mysqld_safe, they will find no indication that we're changing the default behavior. They might spend a lot of time debugging, until they discover that we've modified mysqld_safe. Don't you think it might be a problem? [1] http://dev.mysql.com/doc/refman/5.0/en/option-files.html [^]

(0010429) laurent (manager) 2013-06-09 16:05	Upon my suggestion, and the method was replaced recently (before I took over the package) by the default MySQL script. It looks for my.cnf in /etc/opt/csw/my.cnf, then /opt/csw/my.cnf, then /var/opt/csw/mysql5/my.cnf (the content of the last two, if found, is added to the default). The only modification for the script is the one that allows picking up the binary architecture to run on Solaris according to what the system supports or what is configured. So basically, it follows what upstream recommends, and it has been working nicely for me. Unless there's some negative feedback, I'll close this ticket soon.

(0010430) laurent (manager) 2013-06-09 16:05	See last note.

(0010457) laurent (manager) 2013-06-30 18:19	Works good.

Relationships

OpenCSW Bug Tracker