“The time has come…to talk of many [technologies].” –Lewis Carroll(‘The Walrus and the Carpenter’)
Archive for September, 2007
How I Upgraded to WordPress 2.3 on Live Blog With Zero Downtime
3Few days back I had noted on this blog that the WordPress 2.3 upgrade of my blog went trouble-free and the blog was inaccessible only for less than a minute during the upgrade. I had quickly noted down the steps that I had followed to do the upgrade and I am trying to give a shape to those rough notes in the hope that it may come handy to me in the future. Whether or not this will be useful to the others depends on whether they share the same environment as that of my blog. Most important factor to me was my web host Dreamhost‘s support for remote shell access which is very helpful in carrying out many of the following tasks conveniently. I find FTP, scp etc. to be slow and inefficient. I was also lucky that my theme and plugins didn’t me give any problems.
So let’s get started.
Before starting to do anything, read how to prepare for WordPress 2.3 and about the BackUpWordpress plugin.
The general idea here is to create a complete replica of the current blog at a different location but using the WordPress 2.3 version. Such a copy can be made on a local system too(if LAMP stack is installed, say XAMPP) but because Dreamhost makes it so easy to work with the remote shell, I decided to make the copy on the Dreamhost server directly.
Let us first get everything ready that is needed to make a copy of the existing blog. We need to create a new directory to install WordPress 2.3 in it and also need to create a new database to import the old posts into it. (If you can’t/don’t want to create a new database, you can use the same existing database and use a new table prefix(e.g. wp2_) instead, but there is always a tiny-weeny bit of risk involved with this.)
From the control panel of your web host, create a new sub-domain and name it something like blog2.domain.com(you can create just a new directory too like domain.com/blog2); on Dreamhost this creates a new directory with the name blog2.domain.com and I use this directory name in the rest of the post.
Create a new MySQL database and let’s say you name it wp23_db. You can do this (1) using mysql command in a remote shell(ssh), (2) using phpMyAdmin web interface, or (3) from the control panel(like cPanel); use whatever method is provided by your web host. Note down the host name, user name and password details for the created database for future reference. On most web hosts the MySQL host name will be localhost, but on Dreamhost it will be mysql.domain.com.
Download WordPress 2.3 and extract it in the newly created directory, probably using FTP, like you might have always done. Or preferably, use subversion to install WordPress 2.3 this time. If you use Dreamhost, you can connect using ssh/putty and run the following commands:sh# cd $HOME/blog2.domain.com
sh# svn co http://svn.automattic.com/wordpress/tags/2.3 .
Copy the content files(theme files, uploaded files etc.) from your current blog directory to the new directory:
sh# svn co http://svn.automattic.com/wordpress/tags/2.3 .
sh# cp -rpf ../oldblog/wp-content/* wp-content
sh# svn up
sh# svn up
Also include any other directories you might have created to store non-Wordpress files like images.
Now import all the data from the old database to the newly created one. You may prefer to export/import from the phpMyAdmin interface, which makes it a very easy task but painfully slow, so I use the command line instead:sh# mysqldump ––add-drop-table -u -p -h mysql.domain.com > exported.sql
sh# mysql -u -p -h mysql.domain.com wp23_db < exported.sql
sh# mysql -u -p -h mysql.domain.com wp23_db < exported.sql
Remember to use *your* username, password, MySQL host name and database name in the commands.
You might consider disabling all the plugins in your current blog *before* exporting the database and then re-enable them as soon as the export job is finished. Actually it is strongly recommended that you disable the plugins before exporting the database as it may be necessary in your case depending on what plugins are installed on your blog. For the record, I didn’t have to disable the plugins(I was using the 3.0 beta version of Google Sitemap and latest versions of all other plugins).
The database is ready now with all your posts in it. Next enter the database details of this *new* database(wp23-db) in the wp-config.php of the new 2.3 installation:sh# cd $HOME/blog2.domain.com
sh# cp wp-config-sample.php wp-config.php
sh# emacs -nw wp-config.php
sh# cp wp-config-sample.php wp-config.php
sh# emacs -nw wp-config.php
[php]
define(‘DB_NAME’, ‘wp23-db’); // The name of the database
define(‘DB_USER’, ‘username’); // Your MySQL username
define(‘DB_PASSWORD’, ‘password’); // …and password
define(‘DB_HOST’, ‘localhost’); //mysql.domain.com in case of Dreamhost
[/php]
If you can’t access your blog at the new URL, try:
Copying your old .htaccess file to the new directory:
sh# mv $HOME/oldblog.domain.com/.htaccess $HOME/blog2.domain.com
Going to the Options -> Permalinks page in the WordPress administration area of the new blog and clicking the Update button.In case parts of the blog look broken or you see database errors referring to tables such as post2cat, some of the plugins may be at fault, see the next step.
If you had disabled the plugins in your old blog before exporting the database(Step 4), then obviously the new blog will start with all of them disabled as well. Try enabling them one by one and see if any of them cause any trouble, in which case, consider upgrading the problematic plugins to their latest versions, or simply disabling them until you find a solution to it. You can read more about which plugins are compatible with WordPress 2.3.If your theme looks broken, then you can try to fix the incompatible code yourself or try to use a new, 2.3 compatible theme. The chances of a theme breaking disastrously is extremely rare if you ask me. Rich’s article has a workaround.
If you are happy with the working of the copy of your blog at http://blog2.domain.com/, it is time to make the final switch from the old blog to the new one. (Note that the old blog was serving your readers faithfully all this time without being affected by all the upgrading stuff we have been doing in the background). This is a critical step and you should confirm multiple times that your WordPress installation and the database backups are in sound size and shape before proceeding further. Do this as part of the final step:Change the URLs to point to your original blog location:
Go to http://blog2.domain.com/wp-admin, change the values in Options -> Blog Address and Options -> Website Address to http://oldblog.domain.com/. You can change the URLs directly in the database too, like we did in Step 6.
Go to http://blog2.domain.com/wp-admin, change the values in Options -> Blog Address and Options -> Website Address to http://oldblog.domain.com/. You can change the URLs directly in the database too, like we did in Step 6.
sh# mv oldblog.domain.com tempblog.domain.com && mv blog2.domain.com oldblog.domain.com
Your web host may instead support mapping of domain names to directories in a different way. Use whichever way is available to you to map the old blog URL to the new installation directory. If you think something has gone wrong, then you have to reverse only this particular step.
You can now access the upgraded version at http://oldblog.domain.com/
(Delete the old database, old installation directory and the new sub-domain if you like.)
That’s it. Did I goof-up somewhere? I hope you at least got the gist of the method of upgrading described above. While enjoying the new features of the 2.3 version, try to make some time to read useful posts about WordPress 2.3 on the web. Mine was a success story, you may want to read about a different, not-so-positive WordPress 2.3 upgrading experience too. I could add a few more miscellaneous points such as how FTP too can be used instead of a shell to achieve the same end result but I think we would agree that the post is already quite long :)
Upgrading to WordPress 2.3 with Zero Downtime!
1I had decided to upgrade my wordpress blog to the 2.3 version once it gets released but I was planning to create a duplicate of this blog and work on it for couple of weeks before overwriting this original blog with the upgraded copy. I had never imagined that the whole upgradation process will go so smoothly without any database schema, plugin or theme issues and with literally zero downtime.
My blog is running on WordPress 2.3 version now! But you can’t see any difference? That’s the whole point! :)
I did not disable a single plugin during the upgradation process though I still need to test if all of them are working properly or not. They do not currently produce any observable bugs at the least. Throw me an email if you find a part of the site broken.
To be completely honest, the site did go down for around 40 seconds towards the end but that was because I goofed up a little bit. A simple rename set everything right. I am now planning to disable/uninstall some of the plugins, make a list of additional plugins to install and also search for a more 2.3 friendly theme. I am happy with categories for now, so I am keeping them; tags will have to wait.
If I can find time, I will try to document the process that I followed to upgrade this blog which I did in less than 30 minutes. I followed the subversion procedure to upgrade the blog. More details soon…
Update: Done, I have documented the entire procedure.
Connecting To Nokia N800 From a Computer Using VNC
12Setting Up Nokia N800 for VNC Access Using `x11vnc`
Install x11vnc application on the Nokia N800. Either download the x11vnc deb package on the PC, transfer it to N800 and install it; or download and install it directly from N800.
From the Connection Manager top menu, select Internet Connection -> IP Address. I assume it to be 192.168.2.10 for the purposes of this tutorial.
Accessing Nokia N800′s screen from Windows:
Download TightVNC Viewer application for Windows and extract it at a convenient location.
Run the TightVNC Viewer executable, enter the IP address( as noted in the previous section) in the pop-up dialog box, and click the Connect button.
Enjoy accessing N800′s screen comfortably using PC’s keyboard/mouse :)
(Experiment with the different settings in TightVNC viewer at your leisure.)
Accessing Nokia N800′s screen from GNU/Linux:
Chances are high that a VNC client is already installed on your GNU/Linux distribution. To test for one client, try the ‘vncviewer ––help’ command:
If you see the version information as displayed above, it means vncviewer is installed on your computer. You can run the following command to connect to the N800(substitute the IP address of *your* N800 below that you had noted above):
sh# vncviewer 192.168.2.10:0
And you should be up and running just as in Windows.
If you get an error though that the vncviewer command is not found on your system, then either some other VNC client application may be installed on your distribution(check in the menus) or perhaps you need to install a VNC client manually. vncviewer was already there on my Ubuntu, Fedora, openSuse, Linux Mint etc. ; if that is not the case with you, search for a VNC client in your distribution repositories or on the web.
Just by installing a ~500KB VNC server application x11vnc on the Nokia N800 Internet Tablet you can access its screen from any computer by using any of the available VNC client software for your favourite operating system. You can connect N800 to a computer through ssh in the same way, if there is no GUI present for example, but let that be a topic for another post.
Microsoft’s Mobile PC Newsletter Features Linux-enabled Nokia N800
0Microsoft’s Mobile PC Newsletter of the month of September(2007) features a section on Linux-powered Nokia N800 Internet Tablet about an article written by Matt Faulkner on gottabemobile.com. The website basically features Windows powered Tablet PCs and UMPC devices. As Matt himself says:
We don’t deal with too many devices that aren’t Tablet PC or UMPC related, but there are a few that enhance our ‘Mobile’ life, and the N800 could be one of those devices.
Fair enough.
But what took Microsoft’s “Mobile PC” Newsletter so long to mention a mobile product that is almost nine months old today? It’s not even a detailed review of the product, just a short post by Matt! I felt strange that such a passing mention of a nine month old Linux-powered product found space in Microsoft’s newsletter :)
Installing C++ Boost 1.34.1 on Slackware/Zenwalk
1NOTE: This post is an update of my earlier post Installing C++ Boost 1.33.1 on Slackware/Zenwalk, to now use the new version of C++ Boost libraries – 1.34.1. What follows below is the traditional way of downloading and installing C++ Boost 1.34.1 on any Slackware based distribution such as Zenwalk and Absolute; for a simpler way of installing it using SlackBuild build script, go to the bottom of the post. .
C++ Boost 1.34.1 on Slackware : Traditional Method
Download bjam(tgz) and boost-1_34_1(tar.bz2) source packages from the sourceforge.net website:
bjam for Slackware
C++ Boost source package
(or Google for the latest versions of these two packages) Save these two files in the home directory and then cd to it:
bjam for Slackware
C++ Boost source package
(or Google for the latest versions of these two packages) Save these two files in the home directory and then cd to it:
sh# cd $HOME
Install bjam(as root):
sh# installpkg boost-jam-3.1.14-1-linuxx86.tgz
sh# export PATH=$PATH:/boost-jam-3.1.14-1-linuxx86/
Compile and install boost(as root)*:
sh# export PATH=$PATH:/boost-jam-3.1.14-1-linuxx86/
sh# tar xjvf boost_1_34_1.tar.bz2
sh# cd boost_1_34_1
sh# bjam ––toolset=gcc
sh# cd boost_1_34_1
sh# bjam ––toolset=gcc
C++ Boost is now installed. This procedure doesn’t install the files in the default library paths, so compilation commands are slightly longer than they are for distributions like Gentoo and Debian/Ubuntu:
sh# g++ -o first first.cpp -I/usr/local/include/boost-1_34_1
sh# g++ -o second second.cpp -I/usr/local/include/boost-1_34_1 -L/usr/local/lib -lboost_filesystem-gcc
sh# g++ -o second second.cpp -I/usr/local/include/boost-1_34_1 -L/usr/local/lib -lboost_filesystem-gcc
You can simplify this by adding the paths of boost folders to gcc library environment variables:
sh# export CPLUS_INCLUDE_PATH=/usr/local/include/boost-1_34_1
sh# export LIBRARY_PATH=/usr/local/lib
sh# export LIBRARY_PATH=/usr/local/lib
The compilation can now be performed using the following simple commands:
sh# g++ -o first first.cpp
sh# g++ -o second second.cpp -lboost_filesystem-gcc
sh# g++ -o second second.cpp -lboost_filesystem-gcc
The two ‘export’ commands can be added at the end of the profile file(/etc/profile or $HOME/.bash_profile or something like that) to avoid having to type them every time a new shell is opened. Other way to simplify the process would be to create symbolic links to boost library paths in the Slackware standard include paths so that gcc can find them directly.
*Thanks to kerrigangster for reminding me about the new syntax to build C++ Boost libraries using bjam build tool.
C++ Boost 1.34.1 on Slackware – SlackBuild Method
kerrigangster also pointed out a neat way of installing packages on Slackware using the SlackBuild build scripts, so if you don’t want to download the required files manually, you can automate the download and installation process of Boost libraries using the C++ Boost SlackBuild script:
Download(Right-click -> Save As…) the following two files and save them in your home directory:
boost.SlackBuild script
C++ Boost slack-desc
(please email me if any of the above two links stop working) Run the downloaded boost.SlackBuild script(as root):
boost.SlackBuild script
C++ Boost slack-desc
(please email me if any of the above two links stop working) Run the downloaded boost.SlackBuild script(as root):
sh# sh boost.SlackBuild ––cleanup
You need to be connected to Internet for the above script to run successfully. Alternatively you can manually download the C++ Boost source package and store it in the same directory as boost.Slackbuild before running the script.
The installation package will be created in /tmp. Build from there:sh# ls /tmp/boost*
sh# installpkg /tmp/boost-1.34.1-i486-1.tgz
sh# installpkg /tmp/boost-1.34.1-i486-1.tgz
You can delete all the temporary files now if you want. Files from /tmp may be deleted automatically by the operating system at the next reboot. You can test the installation as explained in the first section.
Too easy, right? :)
Recent Comments