DVD Colors by alvimann at Morguefile

Plone 3 Migration: Pushing Through the Wall

When it comes to Plone, I seem to be a perpetual newbie. I really only get into the guts when it is time to do an upgrade. I have been running on Plone 2.5.1 for some time and in January I started the shift to Plone 3. What a disaster. What I found is that I could try to end run the migration problems I had, but it still was not a workable outcome. After trying a number of different mixtures – including importing a ZEXP file from 2.5.1 into 3.1.7 – I gave it up as a bad experience. Summer has given me a new opportunity to work on the upgrade, now to 3.2.3, and it went remarkably well. I am now running in 3.2.3 and all of the ripples seem to have smoothed to calm waters.

I won’t belabor my earlier experiences but I did use them as a starting point.  I went to Plone.org and installed 3.0.6, which was the last one for which I could get a migration to work.  I ran into the same problems and decided I might have to step through each iteration from 2.5.1 up to 3.2.3, migrating one step at a time.

I followed the standard upgrade procedure:

  1. Install the new Plone version in a new folder (not over the former one, and not by just unzipping the Plone products into the old Products folder)
  2. Copy the old Data.fs file over
  3. Copy the old Products over

I could not get the migration to 2.5.4 to work.

I decided to get back to basics and figure out if I could get straight to 3.2.3 and was able to do it, although it wasn’t smooth.  However, it would be unfair to suggest it had anything to do with documentation or the upgrade guide!  Rather, I seemed to hit a couple of common errors and had to keep backing up and starting again.

Installing 3.2.3

This will seem like a no-brainer but be sure that, when you unzip the Unified Installer, and read the README and UPGRADING files, that you really read them.  I had two issues during the multiple installs I eventually completed:

1.  sudo ./install.sh    If you leave off the sudo, you end up getting odd permissions problems in your /usr/local/Plone folder.  This in turn appears to cause problems in (a) starting Plone and (b) running it.  One common problem was a TraversalError (or one that mentioned a missing Traversal adapter)  that popped up when I started to try to maneuver through my site.  I ended up deleting the entire Plone, and reinstalled it properly.  Using sudo fixed it.

2.  Don’t install in a custom target folder.  You can do so, with the switch –target=, but when I did it, I got errors that showed that something in Plone was looking for /usr/local/Plone.  I was unable to determine whether it was picking up on some cached file (although I had restarted the server) or really a problem with the install.  In any event, I reinstalled and took the default folder.

I also started to get iteration errors.  This was my favorite:

(‘iteration over non-sequence’..(.))

Again, it seems to be permissions based, although I couldn’t find any online solutions to it and just know it disappeared as I finally made progress.

The fix for these was to make sure the owner of the files was plone:staff.

Migration

Once I had 3.2.3 installed and the permissions correct, I dragged my current Data.fs file over.  I chown’d it and then copied the Products over into the /products folder.   On one attempt, doing this actually seemed to cause additional problems, like Product conflicts.  On my successful migration, I left the Products alone and only moved over my 2.5.1 Data.fs file.  This worked, and was the way I made progress.  The Plone Migration tool worked without a hitch, something I had not experienced with 3.1.7.

Buildout Blows Up

This is something other people found.  I am not sure what happened, but I was able to migrate my 2.5.1 Data.fs successfully and make some other changes.  The site looked fine.  Then I went back to the command line and ran the bin/buildout command.  Again, an obvious fix, but if you run the buildout command in the /zinstance/bin folder, you will get errors about cfg files not found.  Run it from /zinstance.

When I ran the buildout command, it attempted to grab Cheetah, an egg that I had not added (since I had not edited the buildout.cfg file other than to change a port) and spat out errors.  When I opened up Plone again, I could reach the Zope Management Interface (ZMI), but nothing else.  More traversal errors.

Products

This led me to my last install of Plone 3.  One tip I picked up from a blog was to go into your ZMI, Control Panel, Product Management, and delete all the entries.  As you may know, the list of products there do not match the products installed.  The tip was to delete all of the entries, then, when you restart the server, it will repopulate with what was actually installed.

Then I dragged over the two old Products that I wanted to keep and dropped them in the Products folder.  Again, I chown’d them and restarted the server.  They were available in the Quickinstaller and installed without a hitch.

Some pages continued to give me odd errors – Traversal – so I followed another tip, which was to edit your buildout.cfg file to turn on debugging, and then running Plone in the foreground:  bin/plonectl fg.  Again, this is newbie stuff, but running it in the foreground means you get to see absolutely everything that is going on – no hidden errors!  I found a couple, including an error about installing Five.

Although it is a product, the issue was related to a third product I had attempted to drop in to the products folder.  The error about Five was a red herring, and I fixed the problem by eliminating the product.

Instead, I edited buildout.cfg to grab the egg for that product, ran buildout again with bated breath, and it worked flawlessly.  I restarted Plone and my product was in place.

Final Thoughts

Some of the errors related to buildout may have been due to the almost non availability of Plone.org simultaneously to my installation attempt.  When I ran buildout today, the Cheetah install didn’t have any problems.  I definitely needed to be more careful about file ownership, which seemed to cause a number of errors that, from weren’t obviously permissions based.