I’ve had a good time at Ghost, with the position offering me the opportunity to learn a range of new tools and techniques (Sass, Git, Lemonstand, et al), but I feel that I’ve somewhat outgrown it (too much of a focus on frontend technologies), and the desire to move onto bigger and better things lead me to School Stickers.

I’m sure that once I start there I will be posting more about the company and my role, etc.. but for now, lets just say they have a really cool system for promoting good behaviour in schools, which you can find out more about at Carrot Rewards and Classroom Carrots.

Anyway, now that I’m leaving, Ghost Design has a position open for a new web developer, so get your CV and portfolio ready, and you could be taking over my job.

That isn’t to say that WordPress is bad – it isn’t – it’s just that for some of the projects I was working on, using WordPress was a bit like cracking a walnut with a sledgehammer.

Add to this the fact that the majority of our clients were having trouble understanding the WordPress administration interface (meaning that, more often than not, I ended up populating the content for them), I was looking for something better suited to the type of project I was working on.

Enter CouchCMS

CouchCMS is a lightweight content management system that is designed to work with pretty much any HTML template you wish to throw at it.

Unlike a lot of other CMSs I’ve used, which require that you convert your template into a theme (which, depending on the CMS at hand, can be hard work, not to meantion downright confusing for a beginner), Couch instead gets you to define the editable regions of your template via the addition of some special tags added to your existing markup, which it then uses to build the administration area of the site to your requirements.

But this post isn’t designed as a review of Couch (although if it was, it would probably say something like “two thumbs up”), or even a tutorial on how to use it - rather, the purpose of this post is to explain my plan to use Couch with Git.

Separation of data and logic

Since getting into Git I’ve discovered lots of really useful ways to make my life easier. For example, after following an article on how to Install and manage WordPress with Git, all the WordPress sites that I maintain on a daily basis are version controlled with the minimum of fuss, making it easy for me to update them as and when I need to.

This is achieved via the use of a submodule containing the core WordPress files (and nothing site specific), while the rest of the repository contained the bits specific to the site being built. This is very similar to the concept of the separation of  data and logic.

I wanted the same with Couch, but the default install has at least two folders (uploads, snippets) and one file (config.php) that exist within the main couch folder.

I made a post in the forum about this, and found that the aforementioned folders are easily moved, but without a config.php file in the correct place, Couch would just refuse to work. Although it looks as though the guy who wrote Couch might implement a fix for this himself at some point in the future, I’m impatient, so I made my own solution.

What I did

The solution, when you think about it, is really simple. First I made a copy of the default config.example.php file, renamed it config.php, then moved it into the root directory folder before customising its settings (while not forgetting to set the values for the uploads and snippets folders), then created a new config.php file in the couch folder with the following content:

<?php
$folder = dirname(dirname(__FILE__));
require $folder.'/config.php';

As you can see, this gets the path to the root folder (because relative paths don’t work), then uses it to require the config.php file that has all your settings in it.

Now that the couch folder is standalone, you’re free to do whatever you want with it, such as set it up as a submodule, or simply ignore it from your Git repository.

I’ve tested this with Couch 1.2.5 and 1.3-RC1, and so far as I can see, it works fine with both (although I can’t see any reason why it shouldn’t work with any version of Couch, past or future).

But what if you’re not working on an open source project? Sure, you can buy access to private repositories from GitHub - but if you have a team of five or less, I’m here to tell you to put your wallet away.

Bitbucket for teh win

Allow me to introduce you to Bitbucket, which started life as Mercurial’s answer to GitHub, and served as a hub for the Mercurial community. I used the Bitbucket service, for a time, during my Mercurial days at Propeller, as they offered private repositories for free.

I remember at the time that this caused me much dilemma, as I knew the de-facto industry standard was becoming Git, and was keen on switching away from Mercurial for this reason, but could not afford GitHub.

This all changed on the 3rd October 2011 when Bitbucket announced support for Git.

Is it any good?

Bitbucket works in much the same way as GitHub does, and so far as I can tell, supports mostly all the same features. For example, each repository supports a wiki and issue tracking system, full history of past commits, support for pull requests, integration with a large number of services, and proably a whole ton of other git-based goodies that I’ve not even begun to explore.

They also support submodules hosted at in other locations (such as GitHub), a feature that I take full advantage of on almost all of my own projects (even WordPress ones), so you don’t need to worry about losing this feature.

Keen on taking business from their rivals, BitBucket also supports the ability to import repositories directory from GitHub, Google Code, Subversion, et al. meaning that switching to BitBucket is an easy process.

(And no, as my old work colleague Sheepy asked me, it doesn’t do anything funny like ‘covert the repositories into mercurial then back into git’.)

Value for money

Bitbucket makes its money by charging for the maximum number of people that can access each repository, rather than on the number of repositories you own. This means, for example, if you’re in a small web design firm with a large throughput, (such as Ghost Design) it could work out more cost effective than the competition, without any loss of functionality.

So, If you’re not yet using any form of remote repository for your private projects, then give Bitbucket a go., Whereas if you’re already using GitHub, a couple of quick sums will tell you if you’re better off with BitBucket, and with no more than a few minutes importing your existing repositories, you’ll be up and running before you know it.

Full discolsure

I did win a t-shirt from Bitbucket as part of their spooning promotion, but it takes a lot more than a free t-shirt to buy me. I’ve posted this message because I believe that Bitbucket offer a good service, and I want to give credit where credit is due.

*watches as tumble-weed bounces across the void*

…one of the main reasons I got a dedicated server was because of Git, and all the wonderful things that it is able to do for you.

The problem I quickly discovered was that all of my (and my employer’s) customers used shared hosting, which meant being limited to FTP for uploading changes to their websites.

This meant that when it came to deploying my changes to the server, I still had to find and upload each of the changed files manually (or think “sod it” and upload them all, to make sure I didn’t miss any).

And, if I’m honest, this became quite repetitive and boring… So what should you do if you want to automatically deploy from Git via FTP?

git-ftp to the rescue

git-ftp is a free and open source Bash script that allows you to push files in a Git repository via FTP to a remote server. But rather than upload all the files each time you push, git-ftp is intelligent enough to only upload (or delete) files that have changed since the last push.

It also has additional features such as configuration of an ignore file, which will prevent any specified files from uploading, and the ability to perform dry-runs, which simulates the upload facility, to make sure that nothing will go wrong before you do push for real.

Installing git-ftp was so simple that even I (a Neanderthal when it comes to most things Linux) was able to do it without issue, and once a repository is configured with the correct FTP settings:

$ git config git-ftp.user daniel
$ git config git-ftp.url ftp.example.com
$ git config git-ftp.password s3xyAnd1Kn0wIt

and an initial git-ftp initiation process is completed, pushing the most recent changes is a simple as:

$ git ftp push

Alternatives

To help avoid confusion, I figured it would be important to point out that there is another project hosted on github which has the same name, and does the same thing, as the aforementioned git-ftp, but is written in Python rather than Bash. As I’ve not used it, I cannot comment on it, but if Python is your thing, then you might be interested in trying that instead.

Alternatively, if you don’t mind spending a bit of money, it might be worth taking a look at Beanstalk. This is designed to be an all-in-one solution alternative to github for repository hosting, with the additional benefit of automatic FTP deployment, and third-party service integration, etc…. I gave their free plan a try, and the service they offer seems to work well…

Conclusion

…but personally, seeing as a price-tag of free is very attractive, I’m quite happy combining git-ftp and Bitbucket (more on this in a future post), and in fact do so for 12 (and counting) projects.

It would appear, however, that whoever it was that hacked into my server and turned it into a spam-sending machine, had other ideas.

(This post is a bit long and rambling, so feel free to skip to the end if I start to bore you.)

A bit of background

This time last year, if you had asked me about running my own Web server, I would have told you that I had no interest in it. I was perfectly happy with the cPanel based shared hosting that I was been using, and didn’t see the need for anything else.

This all changed during my time at Propeller Communications, where I was introduced to version control. My first taste of a version control system was Mercurial, and while my own experience of it was rarely bad, and the bundled TortoiseHG was a joy to use, it didn’t take long for me to realise that the de-facto industry standard was Git (thanks, mainly to GitHub), so upon leaving Propeller, I made the switch.

The list of benefits afforded to users of version control is long, but the one benefit that really caught my attention was the ability to push changes I had made on my local machine directly to the server. No longer did I have to use FTP to upload the correct files to the correct place, while remembering to removing files that weren’t needed any more. I simply had to run one command, and everything was taken care of for me.

But, in order to reap the benefits of Git, I needed my sites to be hosted somewhere that supported Git – and to date I’ve yet to find a shared host that does. So it was time to say goodbye to cPanel, and say hello to SSH.

First tentative steps

Prior to setting up my live server, the one the hackers took a fancy to, I had built two local development servers.

The first, which was as much an experiment as anything else, was in built out of an old PC in the office at Ghost Design. The process involved booting off the Ubuntu Server (10.11) CD, selecting all the options I wanted (LAMP, DNS, SSH, etc..), then, after watching the progress bar complete, I installed Webmin to help manage it. This, I felt, went quite well, and allowed me to gain more confidence using the Linux command line.

The second, which I use as a development server in my flat, was built out of a PC that I had been using as a Windows-based media server. The install of Debian 6 was a much more involved process because I had decided to install all the software I wanted manually. I also avoided installing Webmin, as I wanted to learn how do things properly.

The success of these two servers had filled me with confidence, and so on the 8th December 2011, with a small loan from my mum, I ordered a dedicated server from Hetzner. Because a development server should be as close to that of the production server as possible, I went for Debian 6 again, and for the most part, followed the same instructions as I had for my home server.

Skip to the end

On the 30th January I received an email from Hetzner stating that an ISP had reported my server for sending spam. I forwarded this email to Phil, who suggested that an incorrectly configured mail server might be at fault. After removing EXIM, I thought that would be the end of it, but three days later I received another abuse report.

A full week later I was still receiving abuse reports, and crying out to Phil for help. I have no idea how he managed it (via the use of the occult no doubt), but he tracked down the culprit: a whole bunch of unexpected files located in three of the sites/vhosts I was hosting.

Two of the sites were based on WordPress. I vaguely understand how the open source nature of WordPress, combined with an out of date install and some lax permissions, could allow someone to search the source code for exploits, then search the Web for an exploitable server. But the third was a static HTML site, meaning whoever had done this had been able to get access to it from one of the other two sites, meaning, potentially, the entire server was compromised.

To stop the immediate issue of spam being sent, I had to turn the server off, and following Sheepy‘s advice, I’m going to “Nuke it from a great distance and start again”.

Prevention is better than cure

So what can I do differently to prevent this from happening again? I think my main issue was that of permissions. You can afford a level of flexibility, and a more relaxed attitude to permissions on a development server, because, for the most part, it isn’t accessible to the outside world. For obvious reasons, the same isn’t true of a production server.

I’m also going to make sure that any software I use on the server is kept up to date, thereby increasing the chance of exploits being fixed.

Anyway, I’m going to reinstall the server soon, and I’m still hoping to write the server newbie post, so watch this space.