Socheat suggested I post a link to this here on the forum. I just finished writing up a procedure in our knowledgebase for our customers that steps through the process of performing an upgrade on any supported InterWorx platform from MySQL of your distro and the PHP 4.3.11 InterWorx package to a version of your choice using the source RPMs from InterWorx.
This procedure has been well tested on CentOS 4. If anyone tries these directions with Fedora and runs into problems, we could use the feedback to correct them.
Obviously, I would ask that if you are not a Steadfast customer, you do not contact our support staff, but post issues here. Also, of course, this is not officially supported by InterWorx, so issues with it should certainly not be directed to their staff.
Do you know some compatibility problems when upgrading from MySQL 4.1 to MySQL 5.0 ?
Is it safe to just upgrade the RPM like you suggest ?
I think about AES crypt field ? I’m not sure there are compatibles ?!
Don’t you think you could add two steps to your tutorial :
copy the old mysqld binary (for example mysqld-4.1.old) to be able to restart with the old version ?
Backup all databases with a mysqldump then restore all databases with the new mysql ? (I think it should solve all compatibility problems for encrypt field. Not sure as I don’t done tests)
Maybe a third step could be necessary, like run the mysql_upgrade script ?
Thanks for your returns.
It’s true that we thought about upgrading MySQL 4.1 to 5.0 but we are not sure if there won’t have too much incompatibilty problems
Thanks for this tutorial which should help a lot of people, and give the basics of how to manage rpms
I have not noted upgrade issues between 5.0 and 4.1. For the most part, everything seems to work fine on the customer end. MySQL 5 is smart enough to handle the MySQL 4.1 database format without issues.
The real problem we see is going from 4.0 to 4.1 due especially to the changes to how encodings, collations, etc are handled. I would recommend a mysqldump before going to 4.1, and probably 5.0 just to be safe, but the other steps, backing up the binary, etc seem unnecessary.
Dumping and reimporting should only be necessary between 4.1 and 5.0 if there’s corruption, and I’ve not seen any from past experience.
I thought there was a compatibility problem between 4.1 and 5.0 with AES encrypt field. If I remember well MySQL 5.0 has changed the way they encrypt the data (don’t remember if it is from AES to DES, ???). I’ll look into this
I have had some problems let’s me explain what they are :
1- mysql-share doesn’t install older mysql client like libmysqlclient10 or 14
So you have to find a mysql-share-compat rpm and install it (from mysql site)
2- all libmysql are installed in /usr/lib64/libmysqlxxx rather than /usr/lib64/mysql/
The perl-DBD-MySQL looks for libmysqlclient.so in /usr/lib64/mysql/ and doesn’t find it
(/usr/bin/ld: /usr/lib64/mysql/libmysqlclient.a(libmysql.o): relocation R_X86_64_32 against `a local symbol’ can not be used when making a shared object; recompile with -fPIC
)
So I had to manually copy all /usr/lib64/libmysqlclientxxx to /usr/lib64/mysql/
Evertthing else works like a charm (after rebuilding php4 and php5 of course !)
In fact I also have the same problem when recompiling PHP5 !!
/usr/bin/ld: /usr/lib64/mysql/libmysqlclient.a(libmysql.o): relocation R_X86_64_32 against `a local symbol’ can not be used when making a shared object; recompile with -fPIC
/usr/lib64/mysql/libmysqlclient.a(libmysql.o): could not read symbols: Bad value
collect2: ld returned 1 exit status
And more OSCOMMERCE IS NOT COMPATIBLE WITH MYSQL5 due to JOIN changement !!!
So all the clients that use OsCommerce have to patch their softs !
The universe is probably better off without osCommerce… (yes I know I use it all the time…)
Wonderful package management aside, its probably a good idea to check everything that links against the mysql library after an update. I had a fun time eairlier this week reparing the damage on a server after someone did a minor version update of PHP on a cPanel box. Segfaults, segfaults, and more segfaults!
Socheat recommended these instructions as a possible solution to my problem with PHP 5 coexisting with Interworx in CentOS 4.4
Testing environment:[LIST=1]
Two machines with clean installs of CentOS 4.4
Joomla 1.5 and Modernbill 5
1st machine without Interworx and using CentOSPlus repo version of PHP 5.1.6-3 and MySQL 5.0.27 works great,
2nd virtual machine using Interworx and either CentOSPlus repo version of PHP 5.1.6-3 and MySQL 5.0.27, or following the instructions in the link above (both 5.1.6 and 5.2) all fail.
failure is defined as: I can't install Modernbill 5 or Joomla 1.5- trying to access Joomla install page gives this error:[LIST=1]
With the Steadfast instructions:
> PHP Fatal error: require_once() [<a href='function.require'>function.require</a>]: Failed opening required '/chroot/home/xxx/xxx.xxx.xxx/html/libraries/loader.php' (include_path='.:/usr/share/pear') in /chroot/home/xxx/xxx.xxx.xxx/html/installation/includes/framework.php on line 35
With the CentOSPlus repo enabled and display errors turned on I get a stream of:
> Warning: preg_match: internal pcre_fullinfo() error -3
[/LIST] [/LIST]Any help appreciated!
Thanks for unlocking my brain Socheat! There were indeed missing files in the latest nightly build of Joomla. This method worked fine. Running PHP 5.2 with Joomla now without issue so far.
/var/tmp/mysql-5.0.27-show_flags
/var/tmp/rpm-tmp.15150: /var/tmp/mysql-5.0.27-show_flags: /bin/sh: bad interpreter: Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.15150 (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.15150 (%prep)
/var/tmp/rpm-tmp.15150: /var/tmp/mysql-5.0.27-show_flags: /bin/sh: bad interpreter: Permission denied
This probably means you have the /tmp partition mounted noexec. This will have to be resolved so the rpmbuild can execute bash scripts in that location.
I think you have a typo in your command. You shouldn’t be doing “-c http://some/src.rpm”. The -c command specifies a config file. The correct command is:
[root@host root]# rpm -Uhv --nodeps /usr/src/redhat/RPMS/uname -i/mysql*-5.0.27-100.*
error: File not found by glob: /usr/src/redhat/RPMS/i386/mysql*-5.0.27-100.*
yum install rpmbuild --rebuild --nobuild --with cos3x http://mirror.steadfast.net/misc/iworx/php-5.2.0-100.iworx.src.rpm 2>&1 | grep "needed" | awk '{ print \$1 }' | xargs
Gathering header information file(s) from server(s)
Server: CentOS 3 - Addons
Server: CentOS 3 - Base
Server: CentOS 3 - Extras
Server: InterWorx-CP - CentOS 3
Server: InterWorx-CP - Generic
Server: CentOS 3 - Updates
Finding updated packages
Downloading needed headers
Need to pass a list of pkgs to install
Usage: yum [options] <update | upgrade | install | info | remove | list |
clean | provides | search | check-update | groupinstall | groupupdate |
grouplist >
Options:
-c [config file] - specify the config file to use
-e [error level] - set the error logging level
-d [debug level] - set the debugging level
-y answer yes to all questions
-t be tolerant about errors in package commands
-R [time in minutes] - set the max amount of time to randomly run in.
-C run from cache only - do not update the cache
--installroot=[path] - set the install root (default '/')
--version - output the version of yum
--exclude=some_pkg_name - packagename to exclude - you can use
this more than once
--download-only - only download packages - do not run the transaction
-h, --help this screen
[deps: libmhash 0.9.1-1.rhel3.dag.i386]
Is this ok [y/N]: y
Downloading Packages
Getting libmhash-0.9.1-1.rhel3.dag.i386.rpm
libmhash-0.9.1-1.rhel3.da 100% |=========================| 128 kB 00:01
warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 6b8d79e6
Error: Could not find the GPG Key necessary to validate pkg /var/cache/yum/rpmforge/packages/libmhash-0.9.1-1.rhel3.dag.i386.rpm
Error: You may want to run yum clean or remove the file:
/var/cache/yum/rpmforge/packages/libmhash-0.9.1-1.rhel3.dag.i386.rpm
Error: You may also check that you have the correct GPG keys installed
[root@offshoresimple root]# yum clean
Gathering header information file(s) from server(s)
Server: CentOS 3 - Addons
Server: CentOS 3 - Base
Server: CentOS 3 - Extras
Server: InterWorx-CP - CentOS 3
Server: InterWorx-CP - Generic
Server: CentOS 3 - Updates
Finding updated packages
Cleaning packages and old headers
Attempt to delete a missing file /var/cache/yum/base/headers/glibc-0-2.3.2-95.27.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/base/headers/glibc-kernheaders-0-2.4-8.34.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/glibc-0-2.3.2-95.20.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/glibc-0-2.3.2-95.30.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/glibc-common-0-2.3.2-95.20.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/glibc-common-0-2.3.2-95.30.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/glibc-devel-0-2.3.2-95.20.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/glibc-devel-0-2.3.2-95.30.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/glibc-headers-0-2.3.2-95.20.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/glibc-headers-0-2.3.2-95.30.i386.hdr - ignoring.
Attempt to delete a missing file /var/cache/yum/updates/headers/initscripts-0-7.31.13.EL-1.centos.1.i386.hdr - ignoring.
I do not understand why I should use this command without specifying php version (v5 is my intention) as stated in the steadfast guideline:
Regarding trying to install the libmcrypt and libmhash rpms, these are just prerequisites to installing php - not actually installing php, that’s why you don’t specify any php version there.
I’d try:
yum install libmhash-devel libmcrypt-devel
The goal here is to get libmhash-devel and libmcrypt-devel RPMs installed. If you can find the actual .rpm files for these, you can just do:
[deps: libmhash 0.9.1-1.rhel3.dag.i386]
Is this ok [y/N]: y
Downloading Packages
Getting libmhash-0.9.1-1.rhel3.dag.i386.rpm
libmhash-0.9.1-1.rhel3.da 100% |=========================| 128 kB 00:01
warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 6b8d79e6
Error: Could not find the GPG Key necessary to validate pkg /var/cache/yum/rpmforge/packages/libmhash-0.9.1-1.rhel3.dag.i386.rpm
Error: You may want to run yum clean or remove the file:
/var/cache/yum/rpmforge/packages/libmhash-0.9.1-1.rhel3.dag.i386.rpm
Error: You may also check that you have the correct GPG keys installed
[/quote]
Ah, this is failing in CentOS 3 because Yum is not smart enough to offer to import the GPG key for the packages and thus can’t verify them. If you run this command first, it will accomplish the task required:
Regarding trying to install the libmcrypt and libmhash rpms, these are just prerequisites to installing php - not actually installing php, that’s why you don’t specify any php version there.
I’d try:
yum install libmhash-devel libmcrypt-devel
The goal here is to get libmhash-devel and libmcrypt-devel RPMs installed. If you can find the actual .rpm files for these, you can just do:
rpm -ivh RPM-FILE-NAME-HERE[/quote]
yum install zlib-devel
\Gathering header information file(s) from server(s)
Server: CentOS 3 - Addons
Server: CentOS 3 - Base
Server: CentOS 3 - Extras
Server: InterWorx-CP - CentOS 3
Server: InterWorx-CP - Generic
Server: CentOS 3 - Updates
Finding updated packages
Downloading needed headers
zlib-devel is installed and is the latest version.
No actions to take
yum install libmhash-devel libmcrypt-devel
Gathering header information file(s) from server(s)
Server: CentOS 3 - Addons
Server: CentOS 3 - Base
Server: CentOS 3 - Extras
Server: InterWorx-CP - CentOS 3
Server: InterWorx-CP - Generic
Server: CentOS 3 - Updates
Finding updated packages
Downloading needed headers
Cannot find a package matching libmhash-devel
libmcrypt-devel is installed and is the latest version.
No actions to take
Cabizeid … that’s a known issue with certain MySQL5 builds. Make sure you’ve updated libtool, etc. to the latest version, and that your /etc/ld.so.conf contains one line:
include /etc/ld.so.conf.d
Next, move /etc/ld.so.conf.d/mysql-i386.conf, type ldconfig and try again.
Basically, it’s looking for the zlib stuff in the wrong directory — the one supplied by ld (/usr/lib/mysql) instead /usr/lib.