I have always been an extremely fond user of wordpress, and the system never fails to impress me, as a blogging interface, a CMS, site management, it is incredibly clean, intuitive and simply “beautiful”. In a time when there is are so many systems out there geared for blogging, wordpress excels.

The new admin interface is very refreshing, clean and with a new built in “visual editor” for writing out articles.  Adding media to your blogs seems to be a lot easier now.

The upgrade process as usual with wordpress was incredibly easy, and took only a few moments to do (just remember to look after your plug-ins directory).

But i have been intrigued with SVN (subversion) for quite a while, and with the rather time saving command of:

svn update

To carry out updates, i thought it was time to indulge myself in SVN. It was remarkably easy to get working.

Installing SVN

The server i currently host this blog on is running CentOS 5.1, to install the SVN client you simply do:


[root@hera httpdocs]# yum install subversion
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for subversion to pack into transaction set.
subversion-1.4.2-2.el5.i3 100% |=========================| 42 kB 00:00
---> Package subversion.i386 0:1.4.2-2.el5 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
Package Arch Version Repository Size
=============================================================================
Installing:
subversion i386 1.4.2-2.el5 base 2.3 M

Transaction Summary
=============================================================================
Install 1 Package(s)
Update 0 Package(s)
Remove 0 Package(s)

Total download size: 2.3 M
Is this ok [y/N]: y
Downloading Packages:
(1/1): subversion-1.4.2-2 100% |=========================| 2.3 MB 00:00
Running Transaction Test
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/sitebuilder/tmp(/.*)?.
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications for /usr/local/sitebuilder/tmp(/.*)?.
Installing: subversion ######################### [1/1]

Installed: subversion.i386 0:1.4.2-2.el5
Complete!

Then you can check your SVN install:


[root@hera httpdocs]# svn --version
svn, version 1.4.2 (r22196)
compiled Mar 14 2007, 20:55:55

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

Now you have two options, you can either do a fresh install of wordpress, or convert your current setup to an SVN able setup, this will enable you to use the simple SVN command to do future updates.

Initially i did some test runs on a dummy folder, to test out how SVN worked, it seems to be summed up with a few commands:

svn co

This command “checks-out” the code from the server and places it in the directory of your chosing i.e.

svn co http://svn.automattic.com/wordpress/trunk/ .

This will install the trunk version of the code in the current working directory (that’s what the final . states).

The trunk version is the “latest bleeding edge” version of a project, this would have the latest builds but could potentially (and somewhat likely) to have bugs, and should only be used for developers attempting to work with new code for future versions (i.e. making plug-ins or themes).

To download the current “stable” version (which in this case is 2.5) you would carry out the following command:

svn co http://svn.automattic.com/wordpress/tags/2.5 .

Next time you wish to upgrade to a newer version, for example when version 2.6 gets released, then you would carry ou the following command:

svn sw http://svn.automattic.com/wordpress/tags/2.5/

You can carry out the above commands to do a Clean Install or Convert a traditional install to subversion. I think the documentation at wordpress.org is quite thorough and will get you through with easy.

So as with the cliche of wordpress upgrades, I’ve rewarded myself this blog post!

The Issue:

If you have a domain hosted on a server, but you have setup Google Apps for your domain to use the Gmail style email system for your domain, then you might notice a problem with sending mail to your own domain.

The problem is due to the domains hosted on the server telling your SMTP server that this server is the final destination for the email and all email will be sent using the local delivery methods on Linux.

To force your mail server (in this case Postfix) to relay your emails to the Google mail servers, then you will need to change the settings in the transport file:


[12:40:21] [root@localhost /etc/postfix]# cd /
[12:46:33] [root@localhost /]# cd /etc/postfix/
[12:46:39] [root@localhost /etc/postfix]# nano transport


in the transport file you might see a line similar to:


mydomain.com maildrop:


Where “mydomain.com” is the domain you have hosted on the server.

To fix the domain relay issue to use the MX records at Google, you will need to change the above line to:


mydomain.com relay:ASPMX.L.GOOGLE.com


if you have multiple domains on the server, of which some could be a mix of google hosted or locally hosted (for email), then you can simply set the file to look something like:


mydomain.com relay:ASPMX.L.GOOGLE.com
mygoogledomain.com relay:ASPMX.L.GOOGLE.com
mylocaldomain.com maildrop:


Then run the commands:


[12:47:43] [root@localhost /etc/postfix]# postmap /etc/postfix/transport
[12:47:44] [root@localhost /etc/postfix]# /etc/init.d/postfix reload
Reloading postfix: [ OK ]
[12:47:44] [root@localhost /etc/postfix]#


You can now test your emails by sending a mail on the server to a local domain, you can do it using a simple PHP script:

< ?php
mail(“youremail@yourdomain.com”, “test – mailserver”, “Message body”);
?>

If at any time you wish to see what postfix is doing, then you can keep an eye on your log file:


[12:53:40] [root@localhost /etc/postfix]# tail -f /var/log/maillog


This will stream the maillog file and show you what postfix is doing.

[NOTE: This was carried out and tested on CentOS 5.1 but it should work on any Postfix Linux install]