[ic] IC 4.8.9->5.2 upgrade snafus

Kris Deugau kdeugau at vianet.ca
Wed Jan 25 13:37:40 EST 2006


I've been given the task of moving several stores from one (somewhat 
flaky) machine (currently running 4.8.9 and 4.9.5) to a new more 
reliable machine running 5.2.  The old machine is running Debian Woody, 
fairly heavily modified;  the new one is Debian Sarge with a custom 
local non-threaded perl.  IC is installed from source in all cases.

The first store to be moved is the most complex;  it's had a number of 
customer modifications added on the catalog side, and receives the most 
traffic by far of just about any other site (of any kind) that we host. 
  I have not finalized the move yet due to several problems pointed out 
by the customer on detailed, store-specific testing.

At a glance, the store *seemed* to move easily enough.  (To copy the 
store, I rsync'ed the on-disk catalog tree, and dumped the MySQL 
database to get loaded on the new machine.  I copied the store's webroot 
(such as it is) and made sure that the CGI binary was from the right 
version of IC.  The locations of files for IC installs on both systems 
follow our own internal conventions and are the same on both systems.)

There are a few issues with gnupg due to woody->sarge changes in the 
package that we know about and can allow for.  There's something in the 
determination for shipping costs that may no longer require a hack 
implemented by the customer, so that's good too.  There are also a 
handful of other oddities that we've got solutions for or leads on fixing.

However, there are a few other glitches that I can't trace:  (they may 
be related to other issues - causing them, or being caused *by* them)

1)  Order numbers appeared to have reset themselves somewhere in the 
move.  The customer reported that a few test orders showed up with order 
numbers that had long since been used, and which effectively mangled 
those existing orders.  I don't know what the reset went to originally, 
but the live store is showing order numbers in the 33000-34000 range, 
and the only place I can find where that number might get stored is in 
etc/order.number in the filesystem catalog data.

2)  When an item is deleted from the admin section, an options table 
error comes up.  The customer says they're not using that table for 
anything and that it shouldn't be referenced in the first place.

3)  The customer had set the store subsections menu (category_vertical) 
on the left-hand side of their page to be cached, and regenerated once 
per day.  Somewhere along the line, the settings the customer has used 
to cause this seem to be getting ignored or misinterpreted.

Any suggestions on fixing these?

-kgd


More information about the interchange-users mailing list