Managing WordPress and Gallery2 With Subversion

Keeping WordPress up to date using the standard method of deleting old files, extracting the new ones and then running the database upgrade script is a bit cumbersome, but really not that difficult. Gallery2 uses more or less the same methodology, but it does not require you to delete your files prior to the upgrade because it generates a script to remove deprecated files after the install is complete. This is very kind of them, but the Gallery package is large, and upgrades can get a bit unwieldy. While there are certainly more difficult software packages to maintain, there are things I would much rather be doing than software updates, so I decided to make my life easier by using subversion to manage both applications.

Subversion is a code revision management tool that is everything CVS should have been. It is not only amazingly useful for software developers, but it can be readily used by end users as a convenient method of keeping their software up to date. It is for this reason that the Automattic and and Gallery folks have started recommending it for those who have command line access to subversion enabled servers.

There is no way to force the software to make an existing install into a subversion checkout, so to convert my site, I pretty much just followed the instructions at wordpress.org site.

Create a directory for the new install and “cd” into it:
$ mkdir wordpress-svn

Checkout the current WordPress version:
$ svn co http://svn.automattic.com/wordpress/tags/2.3.1 .

Copy the things I cared about into from the old directory into the new one:
$ cp ../wordpress/wp-config.php .
And the same for:
favicon.ico
.htaccess

The only thing I didn’t really like was their method for copying the files from the old wp-content directory to the new one.

They suggested using “cp -rpf”:
$ cd wordpress
$ cp -rpf wp-content/* ../wordpress-svn/wp-content

But I prefer to use a “tar | tar” operation as root from my original wp-content directory.
$ cd wordpress/wp-content
$ tar cpEf - * | (cd ../../wordpress-svn/wp-content; tar xf -)

I don’t really have a reason for this other than it’s the way I have always moved large directories full of files with varying permissions. I just have more confidence in “tar” to maintain permissions than I do “cp”. I seem to remember being bitten by “cp” while moving some Oracle databases at some point.

That pretty much did it for WordPress… Next I moved onto Gallery2. The process was very similar.

Create the new gallery2 directory within your wordpress-svn folder and “cd” into it:
$ mkdir gallery2

Checkout the latest version of the Gallery2 code:
svn co https://gallery.svn.sourceforge.net/
svnroot/gallery/branches/BRANCH_2_2/gallery2 .

Copy over the config file:
cp ../../wordpress/gallery2/config.php .

Finally, copy the g2data directory over using “tar | tar”:
$ cd ../../wordpress/gallery2/g2data
$ tar cpEf - * | (cd ../../wordpress-svn/gallery2/g2data; tar xf -)

That was it… Now all that was left was to rename wordpress to wordpress-presvn and wordpress-svn to wordpress:
$ mv wordpress wordpress-presvn; mv wordpress-svn wordpress

Everything worked fine, so I was golden. If it had not been, I could have simply renamed the directories back to their original names.

What did all this get me? Much much easier upgrades. Upgrading WordPress is now just a matter of switching to the latest tag and running “svn up”:
$ svn sw http://svn.automattic.com/wordpress/tags/2.3.2
$ svn up

With Gallery, however, there is no need to do a switch for dot releases, so until it goes from 2.2.x to 2.3.x there is no need to run the “svn switch”… I can just “svn up”.

Remember that this is a 10,000 foot view of the process. Please read the links to the Automattic and Gallery documentation if you are going to make the move yourself.

Quick Start Guide for Asterisk

Asterisk is a complete open source software-based IP PBX solution that runs on a variety of platforms. It supports VOIP in several protocols, and can seamlessly integrate with almost any standards-based telephony equipment using relatively inexpensive hardware.

This guide is a quick-start set of notes that should help you get the Asterisk service up and running with the web-based graphical user interface. Much of this was taken from the various README files that come with the software download, but I thought it would be nice to have the directions all in one place so that I don’t have to search for them in the future. I did this on a new RHEL 5 install. I would imagine that the same procedure should work on most Linux distributions.

Configuration and implementation of Asterisk is fairly complex and is beyond the scope of this document. I should also say this this guide does not include directions for installing and configuring other Asterisk related software that is required to integrate with telephony equipment.

Enough disclaimers… Let’s get started.

  • Download the latest source package of Asterisk, untar it and CD into the newly created directory.
  • Run “make
  • Run “make install
  • Run”make samples” (Doing this will overwrite any existing config files you have, so don’t do it if you are upgrading or something like that)
  • Run “make config” (This creates the `/etc/rc.d/init.d/asterisk’ file so you can crontroll the
  • asterisk service with chkconfig and service.)

You are now done installing Asterisk. Now let’s install the GUI.

  • Download the latest source package of the Asterisk GUI client, untar it and CD into the newly created directory.
  • Run “make
  • Run “make install
  • Run “make samples” This installs the sample configuration files. Again, don’t do this if you are upgrading because it will overwrite your existing files.

Now let’s configure it.

You need to edit a few Asterisk configuration files to enable the GUI

1) In /etc/asterisk/http.conf:

        [general]
        enabled = yes
        enablestatic = yes
        bindaddr=xxx.xxx.xxx.xxx (The IP address of your Asterisk server)


2) In /etc/asterisk/manager.conf

        [general]
        enabled = yes
        webenabled = yes


3) Create an appropriate entry in manager.conf for the administrative user

        [admin]
        secret = YourFavoritePassword
        read = system,call,log,verbose,command,agent,config
        write = system,call,log,verbose,command,agent,config


4) Run “make checkconfig

Look for the following lines… They will tell you how to get to your GUI.

  * GUI should be available at
  * http://xxx.xxx.xxx.xxx:8088/asterisk/static/config/cfgbasic.html

  * Before using the GUI, Please visit the install page at
  * http://xxx.xxx.xxx.xxx:8088/asterisk/static/config/setup/install.html 


5) We should be all set Let’s start or restart asterisk:

Run “/sbin/service asterisk restart

6) Lastly, grab a web browser and go to your install page. It should look something like this:

http://xxx.xxx.xxx.xxx:8088/asterisk/static/config/setup/install.html

Configure it up and have fun with your new Asterisk server.

Mounting ISO Image Files On Solaris

More and more, software is distributed in the form of a downloadable ISO image. This is handy because you can then burn it to a CD or DVD, but many times you just want to install it without having to make a disk first. Linux makes this fairly easy, but it’s a little trickier with Solaris. You have to use the “lofiadm” command to first create a block device for the image before you can use “mount” to mount it as a filesystem. Here is the commands.

Make the block device with “loviadm”:
lofiadm -a /path/to/your/image.iso /dev/lofi/1

Mount the image as a read-only filesystem:
mount -F hsfs -o ro /dev/lofi/1 /mountpoint

Ecto is Busted in WordPress 2.1

Last week I took this site to WordPress 2.1 and much to my dismay realized that Ecto, my favorite XMLRPC blogging client no longer worked. It would let me post, but it was never able to update the category information for posts… It just hung with no error. I looked into it, and found out that Ecto expects the category information to be returned as a string, not an int.

Adriaan, the developer of Ecto is blaming WordPress, while I’m sure the folks at Automattic would call it an Ecto problem… That’s just how these things tend to work. Anyhow, it’s pretty easy to fix if you make this quick change to xmlrpc.php.

Simply change this on line 180:

'categoryId' => $catid,

To this:

'categoryId' => (string) $catid,

Hopefully someone will go back to their code tree and make a permanent fix so we don’t have to constantly edit this file every time we upgrade.