Peter's Blog

I'm so taken with my new SliceHost VPS that I've moved this blog over to it. For the first time in four years this blog is hosted on something other than Apache: Nginx. It's still on drupal but running under php5 for the first time (only needing this fix).

The DNS has only just propogated so this is my first posting on the new host. To me it feels snappier when navigating around, a definite improvement.

I've been moving all my sites over to the new host, I've decided to put all my eggs in one basket. Well, not quite, I've also signed up for a minimal rsync.net account, giving me just over 3g of backup space. It will cost me circa £2.50 a month but will be worth it for the peace of mind.

I've put all my sites and also my most important /etc directories (such as /etc/nginx) into a subversion repository. I found a great subversion tip for checking /etc into subversion in the subversion faq:

How can I do an in-place 'import' (i.e. add a tree to Subversion such that the original data becomes a working copy directly)?

Suppose, for example, that you wanted to put some of /etc under version control inside your repository:

1. svn mkdir file:///root/svn-repository/etc \ -m "Make a directory in the repository to correspond to /etc"
2. cd /etc
3. svn checkout file:///root/svn-repository/etc .
4. svn add apache samba alsa X11
5. svn commit -m "Initial version of my config files"

This takes advantage of a not-immediately-obvious feature of svn checkout: you can check out a directory from the repository directly into an existing directory. Here, we first make a new empty directory in the repository, and then check it out into /etc, transforming /etc into a working copy. Once that is done, you can use normal svn add commands to select files and subtrees to add to the repository.

There is an issue filed for enhancing svn import to be able to convert the imported tree to a working copy automatically; see issue 1328.

So all the juicy stuff is in subversion and then I rsync the subversion repository over to rsync.net for the backup (nb, don't rsync a live svn repository while anyone else is modifying it!). This will allow me to roll-back changes should need be (or more likely see what I've changed to break something) using the Slicehost subversion repositories.

If anything does go wrong with my Slicehost slice (not saying it will but it might), I can rent a new VPS or dedicated server and have my stuff back up and running in less than a day (DNS propgation to the new server would be the delaying factor). It's not perfect redundancy but I'm not shafted.

Probably a more likely scerario is my server gets pwned in which case I would remaster it.

The rsync copy between the Slicehost and rsync runs at 583850.15 bytes/sec. Pretty good.

Possible improvements:

• Use Duplicity to backup the repositories, with a full+incremental scheme.
• Put a web front end on the subversion repositories so I can browse them (although [subclipse|http://subclipse.tigris.org/) is working nicely).

UPDATE: I've noticed this article getting hits for people looking how to copy a subversion repository. The simple answer is to just copy the files: cp -rf, rsync -a, however you like copying things. If the repository is live (i.e people are using it) or it will be running on a different version of subversion then the answer is to use:

svnadmin dump path-to-repository > dump.dat
cp dump.dat {wherever}
cd {wherever}
svnadmin load path-to-new-repository < dump.dat

I've got a nice Rails development setup going now. Aptana is a very nice IDE, very powerful, very rich. The Rails development aspect is most useful in being able run applications in development mode on my PC. I use the mysql server on the deployment server through an ssh tunnel rather than install a database on the PC.

I have created a subversion repository on my VPSlink server. I have installed the subclipse plugin on Aptana and checked out my application onto the work PC. I work on the application in Aptana, polish it and when it is ready I commit the changes again through Aptana. Then on my server I deploy the code by getting the new version out of subversion. I don't use a simple rsync to deploy and I haven't got into capistrano (the rails deployment tool) going via svn works for me. I might consider putting up something like trac (or a rails based alternative) to give me a development wiki and web browsing of the repository.

I've been thinking about backups and the current plan is to backup the SVN repositorys and mysql dumps from my VPSLink server to my site5 server and vice versa. The VPSLink stuff is more in need of backing up since I am the administrator of that one, the site5 account includes daily backups. I was tempted by rsync.net a nice, simple, flexible and cheap remote backup option but since I already have two accounts with ssh access and 35G of space between them I don't think I need to spend more money. Rsync.net looks appealing but the main thing it is lacking for professional purposes would be Windows file permissions, otherwise I might consider it for backing up the servers at work: being able to recover all ones files is good, not having to spend a week fixing the spaghetti mess of windows access permissions is better.

One major change is that I have reverted from Lighttpd back to Apache on my VPSLink server. The main reason for this was that Lighttpd seems to have some limitations in terms of supporting things like drupal's urls. Lighttpd would be good for simple setups but getting multiple legacy php and rails applications set up is just as troublesome as with Apache so I've gone back to the devil I know.

I've had Apache fail to start with memory errors a few times. This could well be the 500M limit of the VPSLink coming into play. VPSLink is cheap because there is no swap, 500M is my absolute limit. If I start getting memory problems I will have to consider the options:

• I can upgrade the VPSLink to 1G memory but for similar money I could get a cheap dedicated server
• I could get a different VPS account, one that had burst memory (it's the bursts that kill VPSLink) but I do like the performance of VPSLink.
• I could fiddle about tuning the number of apache processes and suchlike but life is too short for that one

This blog is still on the site5 account. The server is being upgraded soon, maybe this will resolve the loading issues it has whenever I try doing some development on it (e.g run 'top' and shriek in horror).