How to upgrade MySQL RPMS

[danf]

Our server currently has MySQL version 5.0.45. rpm -qi MySQL-server reveals the following:

Name : MySQL-server Relocations: (not relocatable)
Version : 5.0.45 Vendor: MySQL AB
Release : 0.glibc23 Build Date: Tue 17 Jul 2007 05:42:10 PM CDT
Install Date: Mon 05 May 2008 11:08:46 PM CDT Build Host: rpmbuild32.cpanel.net
Group : Applications/Databases Source RPM: MySQL-5.0.45-0.glibc23.src.rpm
Size : 33126186 License: GPL
Signature : (none)
Packager : MySQL Production Engineering Team <build@mysql.com>
URL : http://www.mysql.com/
Summary : MySQL: a very fast and reliable SQL database server

Since the build host is at cpanel.net, I'm assuming this isn't the official CentOS RPM. How can I get a newer version of all the MySQL RPMS?

Thanks.

--df

[azrael]

Search mysql and edit it to your wanted version.

And then /scripts/mysqlup --force.

[FractalizeR]

Search mysql and edit it to your wanted version.

And then /scripts/mysqlup --force.

There is no such file - /var/cpanel/cpanel.conf on my server.

[InterServed]

Noticed that latest mysql 5.0x version is 5.0.67 , while latest cpanel beta still use 5.0.51a.

I'm to afraid to manually upgrade it , maybe cause problems with 3rd party scripts, waiting for cPanel to update first

[cPanelDavidG]

Noticed that latest mysql 5.0x version is 5.0.67 , while latest cpanel beta still use 5.0.51a.

I'm to afraid to manually upgrade it , maybe cause problems with 3rd party scripts, waiting for cPanel to update first

EDGE, CURRENT and RELEASE are on 5.0.51a-2cp at this time rather than 5.0.51a. Refer to http://changelog.cpanel.net for details.

[InterServed]

Indeed, i also noticed that 5.0.67 is on BETA stage.

[cpanelkenneth]

Indeed, i also noticed that 5.0.67 is on BETA stage.

Out curiosity, what motivates you to upgrade to MySQL 5.0.67 ?

[InterServed]

You asked for it, here's the reasons :

Part1:--------------------------------------------------
Important Functionality added or changed:

* Security Enhancement: To enable stricter control over the
location from which user-defined functions can be loaded, the
plugin_dir system variable has been backported from MySQL 5.1.
If the value is non-empty, user-defined function object files
can be loaded only from the directory named by this variable.
If the value is empty, the behavior that is used before 5.0.67
applies: The UDF object files must be located in a directory
that is searched by your system's dynamic linker.
(Bug#37428: http://bugs.mysql.com/37428)

* Important Change: Incompatible Change: The FEDERATED storage
engine is now disabled by default in the .cnf files shipped
with MySQL distributions (my-huge.cnf, my-medium.cnf, and so
forth). This affects server behavior only if you install one
of these files. (Bug#37069: http://bugs.mysql.com/37069)

* Cluster API: Important Change: Because
NDB_LE_MemoryUsage.page_size_kb shows memory page sizes in
bytes rather than kilobytes, it has been renamed to
page_size_bytes. The name page_size_kb is now deprecated and
thus subject to removal in a future release, although it
currently remains supported for reasons of backward
compatibility. See The Ndb_logevent_type Type
(http://dev.mysql.com/doc/ndbapi/en/n...vent-type.html),
for more information about NDB_LE_MemoryUsage.
(Bug#30271: http://bugs.mysql.com/30271)

* Important Change: Some changes were made to CHECK TABLE ...
FOR UPGRADE and REPAIR TABLE with respect to detection and
handling of tables with incompatible .frm files (files created
with a different version of the MySQL server). These changes
also affect mysqlcheck because that program uses CHECK TABLE
and REPAIR table, and thus also mysql_upgrade because that
program invokes mysqlcheck.
+ If your table was created by a different version of the
MySQL server than the one you are currently running,
CHECK TABLE ... FOR UPGRADE indicates that the table has
an .frm file with an incompatible version. In this case,
the result set returned by CHECK TABLE contains a line
with a Msg_type value of error and a Msg_text value of
Table upgrade required. Please do "REPAIR TABLE
`tbl_name`" to fix it!
+ REPAIR TABLE without USE_FRM upgrades the .frm file to
the current version.
+ If you use REPAIR TABLE ...USE_FRM and your table was
created by a different version of the MySQL server than
the one you are currently running, REPAIR TABLE will not
attempt to repair the table. In this case, the result set
returned by REPAIR TABLE contains a line with a Msg_type
value of error and a Msg_text value of Failed repairing
incompatible .FRM file.
Previously, use of REPAIR TABLE ...USE_FRM with a table
created by a different version of the MySQL server risked
the loss of all rows in the table.
(Bug#36055: http://bugs.mysql.com/36055)

Important bugs fixed:

* Important Change: Security Fix: It was possible to circumvent
privileges through the creation of MyISAM tables employing the
DATA DIRECTORY and INDEX DIRECTORY options to overwrite
existing table files in the MySQL data directory. Use of the
MySQL data directory in DATA DIRECTORY and INDEX DIRECTORY
pathname is now disallowed.
(Bug#32167: http://bugs.mysql.com/32167, CVE-2008-2079
(http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-2079))

* Security Fix: Three vulnerabilities in yaSSL versions 1.7.5
and earlier were discovered that could lead to a server crash
or execution of unauthorized code. The exploit requires a
server with yaSSL enabled and TCP/IP connections enabled, but
does not require valid MySQL account credentials. The exploit
does not apply to OpenSSL.

Note
The proof-of-concept exploit is freely available on the
Internet. Everyone with a vulnerable MySQL configuration is
advised to upgrade immediately.
(Bug#33814: http://bugs.mysql.com/33814, CVE-2008-0226
(http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-0226),
CVE-2008-0227
(http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-0227))

* Security Fix: Using RENAME TABLE against a table with explicit
DATA DIRECTORY and INDEX DIRECTORY options can be used to
overwrite system table information by replacing the symbolic
link points. the file to which the symlink points.
MySQL will now return an error when the file to which the
symlink points already exists.
(Bug#32111: http://bugs.mysql.com/32111, CVE-2007-5969
(http://cve.mitre.org/cgi-bin/cvename...=CVE-2007-5969))

* Security Fix: ALTER VIEW retained the original DEFINER value,
even when altered by another user, which could allow that user
to gain the access rights of the view. Now ALTER VIEW is
allowed only to the original definer or users with the SUPER
privilege. (Bug#29908: http://bugs.mysql.com/29908)

* Security Fix: When using a FEDERATED table, the local server
could be forced to crash if the remote server returned a
result with fewer columns than expected.
(Bug#29801: http://bugs.mysql.com/29801)

* Security Enhancement: It was possible to force an error
message of excessive length which could lead to a buffer
overflow. This has been made no longer possible as a security
precaution. (Bug#32707: http://bugs.mysql.com/32707)

* Incompatible Change: With ONLY_FULL_GROUP_BY SQL mode enabled,
queries such as SELECT a FROM t1 HAVING COUNT(*)>2 were not
being rejected as they should have been.
This fix results in the following behavior:
+ There is a check against mixing group and non-group
columns only when ONLY_FULL_GROUP_BY is enabled.
+ This check is done both for the select list and for the
HAVING clause if there is one.
This behavior differs from previous versions as follows:
+ Previously, the HAVING clause was not checked when
ONLY_FULL_GROUP_BY was enabled; now it is checked.
+ Previously, the select list was checked even when
ONLY_FULL_GROUP_BY was not enabled; now it is checked
only when ONLY_FULL_GROUP_BY is enabled.
(Bug#31794: http://bugs.mysql.com/31794)

* Incompatible Change: The MySQL 5.0.50 patch for this bug was
reverted because it changed the behavior of a General
Availability MySQL release.
(Bug#30234: http://bugs.mysql.com/30234)
See also Bug#27525: http://bugs.mysql.com/27525

* Incompatible Change: Several type-preserving functions and
operators returned an incorrect result type that does not
match their argument types: COALESCE(), IF(), IFNULL(),
LEAST(), GREATEST(), CASE. These now aggregate using the
precise SQL types of their arguments rather than the internal
type. In addition, the result type of the STR_TO_DATE()
function is now DATETIME by default.
(Bug#27216: http://bugs.mysql.com/27216)

* Incompatible Change: It was possible for option files to be
read twice at program startup, if some of the standard option
file locations turned out to be the same directory. Now
duplicates are removed from the list of files to be read.
Also, users could not override system-wide settings using
~/.my.cnf because SYSCONFDIR/my.cnf was read last. The latter
file now is read earlier so that ~/.my.cnf can override
system-wide settings.
The fix for this problem had a side effect such that on Unix,
MySQL programs looked for options in ~/my.cnf rather than the
standard location of ~/.my.cnf. That problem was addressed as
Bug#38180: http://bugs.mysql.com/38180.
(Bug#20748: http://bugs.mysql.com/20748)
End of part1 --------------------------------------------------

[InterServed]

Part2:--------------------------------------------------

* Important Change: MySQL Cluster: AUTO_INCREMENT columns had
the following problems when used in NDB tables:
+ The AUTO_INCREMENT counter was not updated correctly when
such a column was updated.
+ AUTO_INCREMENT values were not prefetched beyond
statement boundaries.
+ AUTO_INCREMENT values were not handled correctly with
INSERT IGNORE statements.
+ After being set, ndb_autoincrement_prefetch_sz showed a
value of 1, regardless of the value it had actually been
set to.
As part of this fix, the behavior of
ndb_autoincrement_prefetch_sz has changed. Setting this to
less than 32 no longer has any effect on prefetching within
statements (where IDs are now always obtained in batches of 32
or more), but only between statements. The default value for
this variable has also changed, and is now 1.
(Bug#25176: http://bugs.mysql.com/25176,
Bug#31956: http://bugs.mysql.com/31956,
Bug#32055: http://bugs.mysql.com/32055)

* Important Change: Replication: When the master crashed during
an update on a transactional table while in AUTOCOMMIT mode,
the slave failed. This fix causes every transaction (including
AUTOCOMMIT transactions) to be recorded in the binlog as
starting with a BEGIN and ending with a COMMIT or ROLLBACK.
(Bug#26395: http://bugs.mysql.com/26395)

* Important Change: It was possible to use FRAC_SECOND as a
synonym for MICROSECOND with DATE_ADD(), DATE_SUB(), and
INTERVAL; now, using FRAC_SECOND with anything other than
TIMESTAMPADD() or TIMESTAMPDIFF() produces a syntax error.
It is now possible (and preferable) to use MICROSECOND with
TIMESTAMPADD() and TIMESTAMPDIFF(), and FRAC_SECOND is now
deprecated. (Bug#33834: http://bugs.mysql.com/33834)

* Important Change: The server no longer issues warnings for
truncation of excess spaces for values inserted into CHAR
columns. This reverts a change in the previous release that
caused warnings to be issued.
(Bug#30059: http://bugs.mysql.com/30059)

* Replication: Important Note: Network timeouts between the
master and the slave could result in corruption of the relay
log. This fix rectifies a long-standing replication issue when
using unreliable networks, including replication over wide
area networks such as the Internet. If you experience
reliability issues and see many You have an error in your SQL
syntax errors on replication slaves, we strongly recommend
that you upgrade to a MySQL version which includes this fix.
(Bug#26489: http://bugs.mysql.com/26489)

The End --------------------------------------------------

[cpanelkenneth]

Re-posting the MySQL change log does not give me any indication of your reasons.

[InterServed]

I'm a paranoid person when it comes to security, as i can see there are quite some Security Enhancement made with this mysql release, I'd sure like to upgrade.

[McPhil]

Does cPanel have an ETA on when it will include MySQL 5.0.67 in it's package? I have a new bit of software that won't work with 5.0.51 but works a treat with 5.0.67. Much to my chagrin, the devs won't support their software unless it's running on 5.0.67.

Cheers -Phil

[cpanelkenneth]

The MySQL 5.0.67 RPMs are in BETA testing now.

[McPhil]

The MySQL 5.0.67 RPMs are in BETA testing now.

Is that in the bleeding edge tree?

Cheers,
Phil

[blargman]

Granted it wouldn't be Cpanel supported but if your looking for bleeding edge software, compile it from source. Doing so isn't all that difficult. Even drop in Fedora/Redhat rpm's would work without too much of an issue(granted as long as you use the right version with the right glibc etc. Just make sure you disable mysql from updating. Cpanel's install of MySQL isn't all that non-standard. I can't think of any reason off hand why this would cause too much of an issue. Granted at this point you're in control of updating.