I read a few months back that Stuart Langridge was using Subversion to keep his WordPress up-to-date and I thought: “that’s clever” and didn’t do anything about it.
Today I was talking to Matt and he mentioned updating one of his WordPress installations and I noticed I was due an update myself. I downloaded the latest release and was having a quick skim through the upgrade procedure to make sure I wasn’t forgetting about anything and I spotted a link to the Subversion update instructions… I’m off work sick today and have the time so I decided to give it a go.
I backed up my database and checked out the latest stable version:
steve@decaf~$ cd /var/www/sickbiscuit.com
steve@decaf:/var/www/sickbiscuit.com$ svn co http://svn.automattic.com/wordpress/tags/2.3.3/
I copied over my database config file, theme, plugins and uploads and ran the
wp-admin/upgrade.php script via my browser. The final act was to modify the symlink pointing to the WordPress directory and it worked first time. Profit!
Hopefully whenever I need to update in the future all I’ll have to do is use the following:
svn sw http://svn.automattic.com/wordpress/tags/NEW_VERSION/
followed by running the database upgrade script again. Quick and painless.
I’ve just finished migrating sickbiscuit.com from my home development machine to my new VPS.
DNS records have been updated and
decaf is now handling mail and web traffic for the domain allow the only thing I’ve copied over is this blog.
Hopefully this will give me the motivation needed to spruce things up a bit as the last iteration of sickbiscuit.com looked like it was designed by a programmer
Last month I decided to invest in a VPS from VPSLink.
I had been considering this for a while, especially after my experience using an Ubuntu VPS with Infurious and after 2 power failures within as many weeks due to building work nearby to my home, my hand was forced. No more hosting on a Linux box on the end of a DSL connection for me!
I opted for a XEN based VPS running Debian Etch. I've really come to love APT based distros after running Kubuntu on my desktop before I was endowed with a Mac and with the relative ease of setting up all the Infurious services on Ubuntu. So I decided to go upstream and it's a far cry from my past experiences with Slackware
My first priority was getting my LAMP stack up and running and I spent my free time over the past few days following this excellent tutorial.
Just like many other things in the FLOSS world: you get the instructions, follow those instructions and it Just Works. This instance was no different and all I really had to so was copy and paste commands & configuration settings and I probably spent more time doing background reading, testing each part as I went along and keeping track of all the changes I made on my personal wiki.
The result is I can now host email accounts for as many domains I wish, provide access to those accounts over IMAPS and perform server-side virus scanning and spam filtering.
I've said it before and I'll say it again: I love free software!
I'm currently visiting my family in sunny Fermanagh and typing this from the ASUS Eee PC handed to me by Matt as I left the office yesterday.
One word sums up my opinion of this little device: “amazement.” I'm amazed that something of this size and at a price of £220 can run a full Linux distribution, has built-in WiFi and can therefore allow me to perform all my day-to-day tasks.
So far I have been able to catch up on my RSS feeds with Google Reader using Firefox; i've ssh’d into my home development machine with the included terminal application and connected to the Infurious jabber server via Pidgen. Just a normal day at the office!
I've found the size of the keyboard a bit awkward but I always have difficulty adapting to a new keyboard anyway, and the 800×480 screen resolution is a bit limiting, but I can't find a single fault in terms of performance and if a full-sized keyboard, monitor and mouse were attached then I could use an Eee PC as a daily workstation no problem.
Hopefully I’ll be able to grab an photo of this gadget soon so you all can have a look at it in action.
After a lot of frustration, reading of documentation and even giving up completely on certain paths of action I finally got Jabber up and running. The “Jabber burnout” as Adian called it was terrible and only now do I feel de-stressed enough to write about it.
I initially setup an installation of jabberd2 as I have had previous experience with it and was comfortable with it's administration. I got it working without difficulty and could connect to it via a standalone client but ended up abandoning it when I tried to get a web interface working with it.
As is, jabberd2 doesn't have it's own http polling system, which is necessary for use with a web client and I looked at a couple of mplementations, including Punjab
but decided to throw in the towel and go with a different Jabber server which had this facility built-in, along with logging and multi-user chat: all things jabberd2 didn't provide. Enter ejabberd.
I found configuring ejabberd a bit awkward and the documentation a bit unclear but it eventually bent to my will. This was followed with a lot of playing about with mod_proxy which made me want to cry more than once, but the result was that I got JWChat working and from behind a restrictive corporate firewall
Getting multi-user chat operational was the final piece of the puzzle and I learned an important lesson: ejabberd's
mod_muc module likes to be configured to use a subdomain of the virtual host, even if it doesn't resolve to anything in DNS. This was a painful lesson to learn…
Today, we have a groupchat facility, with logging, that's accessible from anywhere on the web, magic!
As I previously mentioned, my current task as Infurious system admin is providing the team with a bug/task tracking system, namely Trac.
My initial thought was: “our server runs Ubuntu, this should be easy…”
I could get Trac running via
tracd and I could see that
mod_python was working via
mod_python.testhandler but the two didn’t seem to want to play together. Last night, after much frustration, I just gave up and configured Trac to run as a CGI application. Problem solved.
Unfortunately this solution will introduce a performance penalty but at this stage it’s my priority to get the system functional before I start worrying about access speed.
All I have left to do is get the Trac permissions set up and I’m going to move on to configuring a Jabber server which will free us from our dependency on Campfire.
Me? A Linux hippy? You bet!
It’s been a busy week. The lads and myself have been quite industrious, making plans and Getting Things Done.
I’ve taken on responsibility of taking care of the Linux side of things and last night finished setting up an SSL enhanced, WebDAV accessible Subversion repository, for which Aidan has written an introductory guide.
My current task is getting Trac installed and I’m quite enjoying being up to my elbows in command line goodness. It must be the Linux hippy in me
There’s definitely an atmosphere of excitement about the endeavour and it makes the day job seem more tolerable knowing there could be more interesting things on the horizon. Geek on!
During my day job at $BIG_MONEY I’m behind a restrictive corporate firewall and as such can’t ssh to anywhere in the outside world. Which makes me sad. Step in AjaxTerm:
What you are seeing is a screenshot of my screen session for a project I’m working on.
Editing a Perl script with vi in my web browser, I love it!
I finally got sick of not being able to use SQL subqueries and decided to upgrade my MySQL installation from 4.0.x to 5.0.x.
I had wanted to do this previously but was afraid I’d end up breaking something and be left without a working development environment or a website either, for that matter, so I resorted to complicating my custom queries in CakePHP with JOIN statements
I couldn’t find a 5.0.x package for Slackware 10.0 in the package browser, so I bit the bullet and downloaded the source archive…
I extracted the files, issued the immortal
./configure && make commands, left things for a while and was pleasantly surprised when the compilation succeeded.
removepkg got rid of the old package, a new one was easily produced using checkinstall and
installpkg installed it for me.
The only problem I had was when I went to fire up the daemon and nothing happened. It turned out that the startup script was expecting
mysqld_safe to be found in
/usr/bin instead of
/usr/local/bin where it had been installed to: that was quickly remedied with the creation of a symbolic link. From there it was plain sailing, all my databases were functional.
But enough techno-gibberish. The point of the matter is that I managed to build a package from source, get it up and running and the system as a whole still worked! Linux administration definitely appears to coming more natural to me. Bob be praised
Now that MacServ has been deployed keeping development and production copies of the code synchronised has become an issue. The app is still very much a work in progress, with daily requests for fixes & tweaks from the technicians using it and instead of keeping track of modified files and then manually updating them via
scp, I decided to let laziness motivate me to utilise a less painful system.
I spent a bit of time researching the use of
rsync but decided that subversion would better suit my needs. I started by adding a new user and creating a directory for my repository:
# adduser svn
# su svn
$ cd ~
$ mkdir repo
Next was to create the repository and make it writable by all accounts in the
$ svnadmin create repo/
$ chmod -R g+w repo/
Just to be awkward, I decided on having multiple access methods to the repository. For local access I added a username & password for myself into
repo/conf/passwd and fired up the daemon, restricting it to
$ svnserve -d -r /home/svn/repo/
In order for remote access to preserve file permissions on the repository, wrappers for
svnlook had to be created:
$ cat /usr/local/bin/svn
To prevent the logs on my development machine from filling with failed login attempts,
ssh connections to it are on a non-standard port, so the final step in enabling remote
svn+ssh:// access was to tweak the
ssh settings on the hosting account:
$ cat ~/.ssh/config
Finally I was able to perform the initial check-in of my code and then check it out on the production side of things
I’ve still got a lot of things to learn about the day-to-day use of version control: for instance, I had problems with some configuration and
.htaccess files which are required to be different between development & production. Having to enter my password multiple times to perform an update is also a bit of a drag, but it might motivate me to look into the use of ssh-agent and public-key access to my development machine, doing away with login passwords altogether…