I've spent the past two weeks installing and upgrading Movable Type on a test server before actual deployment. The pre-upgrade installation was Movable Type v2.661 and it ran on Windows IIS 6.0 with ActivePerl. The plans for the post-upgrade were Movable Type 3.2 running on Linux Fedore Core 4 or 5. I installed Fedora Core 5 beta on a Dell blade server, but had some issues which I believe to be related to the beta. So I went back to Fedora Core 4 and installed that instead. I installed MT 3.2 on a "clean" default Red Hat Fedora Core 4.0 system and successfully upgraded the MT 2.661 MySQL database which I copied from my production server to this new Linux server
While I got most of Movable Type 3.2 (MT 3.2) installed and functioning, I was having a weird problem whereby the default MT 3.2 plugins (nofollow, Template Refresh, and SpamLookup weren't displaying. I went into the Plugins screen and it says "No plugins with weblog-level configuration settings are installed". Also, the More Actions drop-down list was greyed out. Very odd. I checked my permissions on the Apache web server and made sure to set permissions to execute/read for .cgi scripts within the /var/www/cgi-bin/ directory by permoding chmod 755 *.cgi. After running this I was able to successfully run the MT 3.2 "check installation test script" with no errors, i.e.: http://beta.tmcnet.com/cgi-bin/mt-check.cgi
With no errors displaying, there wasn't much to Google search on or even post to the Movable Type Forums. Stumped and frustrated, I said "aw heck, I'll just open up all the permissions on the Linux server." chmod 777 EVERYTHING - hack me if you want, I don't care, I just want this damn thing to work! Still no dice. I was able to successful post into the MT 3.2 database, but the plugins weren't working. Another stange problem was in all likelihood is related to my other issues was that my MTInclude (macros) within my templates actually RENDER within the HTML source file - that is, my macro code displayed in my browser instead of doing variable substitution.
So I posted some stuff on the Movable Type forums, but didn't get much help. As a last resort, I contacted Movable Type technical support using their online trouble ticket system. (TMC has a paid license so we get free technical support.) At first, their technical support was as stumped as I was. I even gave them root-level SSH access to my blog installation to check my installation and they weren't able to resolve it for over a week. Movable Type tech support mentioned that they had a couple other users with the same issue as me, but they didn't have a solution and that they'd get back to me.
I did some more research on my own and someone pointed out that SELinux (Security-Enhanced Linux) could be the culprit. While installing Fedora Core 4, SELinux was "checked" by default with a message saying something to the effect that it is highly recommended to ensure a higher degree of security for web servers. In case you don't know, SELinux is an implementation of mandatory access control (MAC) in the Linux kernel using the Linux Security Modules (LSM) framework. Standard Linux security is a discretionary access control model. Mandatory access control (MAC) gives admins full control over all interactions of software. Administratively defined policy closely controls user and process interactions with the system, and can provide protection from broken software or malware running as any user.
So while I did have SELinux enabled, I didn't think it was an issue since I figured SELinux by default sets up the correct "context-level" access permissions for the cgi-bin directory and the other Apache directories. My assumption was incorrect. Further, the Movable Type installation instructions for Linux do not mention anything about checking the SELinux permissions. They only mention file-level permissions and using the chmod command.
Movable Type tech support got back to me and asked:
Do you have SELinux enabled on this server? You can run "system-config-authentication" as root to verify that this is enabled. The settings of SELinux are what caused the plugins to not be seen by Movable Type.
In this file: /etc/selinux/targeted/contexts/files/file_contexts
there is this rule:
That rule basically means that the /var/www/cgi-bin directory (and all subdirectories) have a "httpd_sys_script_exec_t" context. Meaning that CGI scripts can execute from this location.
In the case of the /var/www/cgi-bin/mt/plugins directory, each plugin directory (and the /var/www/cgi-bin/mt/plugins folder itself) should have a context type of httpd_sys_script_ro_t. This allows read-only file access to the directory and files and also execute permission.
To adjust the context for the plugins folder, use this command:
chcon -R -t httpd_sys_script_ro_t /path/to/mt/plugins
Sure enough, I did have this context type set for this directory. I ran the above chcon (change context) command on the MT plugins directory and this solved my plugins issue and all the other issues I was having. Learn something new every day. I asked Movable Type, "I used a default MT 3.2 install with a default Fedora 4.0 install, so I'm surprised you don't encounter this problem more regularly with others that also do a 'default' install. I was just wondering why this problem doesn't occur fairly regularly and make it into your FAQ or Troubleshooting guide?" They said they were going to add it to the Knowledge Base, so if you see it there, you know who to thank.
While I was waiting for Movable Type technical support to get back to me, I decided to play around with upgrading the current Windows IIS 6.0 installation from MT 2.661 to MT 3.2. "If I can't get MT 3.2 to work on the Linux server at the moment, I may as well upgrade the Windows version," I thought to myself. For the most part, the installation was pretty seemless.
Many websites will tell you to export the Movable Type blogs one at a time to a text file and then import the blog entries into the new installation. This is the wrong way to upgrade for 3 reasons. First, you lose the unique entry_id for your entries. Your entry_ids, trackback IDs, and comment IDs will all be different, which will make any "manual" SQL massaging of the two databases impossible. Secondly, if you have multiple blogs, exporting each blog separately and then importing is a pain. Lastly, exporting blogs to a text file doesn't bring any of your customized templates over to the new blog nor any of the weblog configuration settings. So basically, you'd still have to copy/paste all the templates by hand, plus reconfigure all the weblog settings.
There is a much better way to upgrade - simply backup/copy the MT 2.661 database into a new database and then let Movable Type 3.2 upgrade the new database for you with all of your templates, blog entries, and configuration settings all intact.
Here are the steps to upgrade ANY version of Movable Type to the most recent version:
If you're using MySQL, backup the current MT database:
1) Backup SQL Database to a text file with .sql extension
mysqldump -u root -p[password] blogs > blogs.sql
2) Create NEW blog database called 'blogs'
mysql -u [user] -p[password]
create database blogs;
3) Import SQL database to the newly created blog database
From command shell run this:
./mysql -h localhost -u [user] -p[password] blogs < blogs.sql
4) You may received this error: "Connection error: Client does not support authentication protocol requested by server; consider upgrading MySQL client"
MovableType doesn't support the new MySQL password hashing scheme. So you have to change it to the old password hashing algorithm. To do that, do the following:
5) Go back into MySQL:
mysql -u [user] -p[password]
GRANT ALL PRIVILEGES ON *.* TO 'bloguser'@'%' IDENTIFIED BY 'mypassword' WITH GRANT OPTION;
UPDATE mysql.user SET Password = OLD_PASSWORD('mypassword') WHERE User = 'bloguser';
6) Create a new directory on your server for the MT 3.2 program files which you have downloaded. Label this new directory something like "mt32" and upload the MT distribution.
7) If your new directory is in cgi-bin, make sure you upload the mt-static directory outside of the cgi-bin, otherwise it will try and execute the files.
Make sure to upload the images in the mt-static directory as binary files and all other files as text.
8) Copy all your old plugins to the new plugin directory into the new MT directory.
Some plugins have needed files outside of the plugin directory, often directories within the extlib directory. Make sure to grab those as well. Plugin files can also be found in the php directory. Copy these from your old MT directory to the new MT directory to the same location. Make sure not to copy over plugins that exist in the new MT distribution since they are newer versions.
9) Rename mt-config-original.cgi to mt-config.cgi.
Compare your old mt.cfg settings to mt-config.cgi and copy the pertinent settings over to the new config file. Important to note that the database password is no longer stored in a separate file.
a) In mt-config.cgi specify the new cgi path location where you put your new MT files (i.e. http://beta.tmcnet.com/mt3/). Check the default encoding on the new config file (UTF-8). Make sure that it is consistent with the encoding you are already using.
b) Set the path for static files in the config file, i.e. StaticWebPath http://beta.tmcnet.com/mtstatic
c) If you have renamed the comment and trackback script files, change it accordingly.
d) Set permissions for CGI scripts: For Linux, set permissions of the cgi files to 755 and the mt-config.cgi to 644
10) Clear your browser cache before pointing to the new mt.cgi file.
11) Launch MovableType 3.2 for the first time by browsing to the new mt.cgi file.
This will automatically prompt you to upgrade the old database format (MT 2.661 in my case) to the new database format.
12) Rebuild all your blogs and see if you encounter any errors.
I recommend installing the PowerRebuild plugin which allows you to rebuild multiple blogs simultaneously.
a) Note #1: I had some issues with the Individual Archives mappings not importing from the old version. Thus, when I rebuilt, it used MT 3.2's default archive mapping to place the entries using locations and filenames I didn't want. I had to recreate the mappings for some of the blogs.
b) Note #2: I had some orphaned Trackback pings in a blog, so I was getting this error: "Can't call method "id" without a package or object reference at lib/MT/App/CMS.pm line 1230." When going to main page of the blog.
i.e. Main Page of a specific blog: http://[blogURL]/mt3/mt.cgi?__mode=menu&blog_id=1
Solution: Delete orphaned trackbacks from the MT interface.
Alternatively: install the MySQL ODBC driver, then go into Microsoft Access and delete all orphaned trackback pings within the mt_tbping table. I actually recommend install a MySQL ODBC driver anyway. Very useful to access the MT database directly.
13) (optional) Add these Regex (regular expressions) to your SpamLookup plugin:
So now I have MT 3.2 successfully installed on Windows IIS 6.0. My next project is to attempt to migrate to the Red Hat Linux server I was playing around with. But that is a project for another day...
I hope this tutorial helps anyone looking to upgrade Movable Type. If it was helpful, drop me a line or post a comment.
Also, my other blog entry, Upgrading MovableType Berkeley to MySQL may be of help.