Till's blog

Moving our PHP application into the cloud, means for us that we are leaving FreeBSD for Linux. Not the best move (IMHO), but I shall elaborate on this in a future blog post.

Once we decided on Ubuntu as the Linux of our choice, I started by moving our development server to an instance on Slicehost. Point taken, Slicehost is not the cloud (as in Amazon EC2, Rackspace, Flexiscale or GoGrid) yet, but Linux on Slicehost and Linux on Amazon EC2 will be alike (or so I hope :-)) and a getting a small slice versus getting a small EC2 instance is an economical decision in the end.

Introduction

The following is the start script for my php-cgi processes, which I ported from FreeBSD (I previously blogged about it here).

The advantages of this script are:

1. php-cgi runs on a unix domain socket — no need for tcp/ip on localhost.
2. No need for the infamous spawn-fcgi script, which never worked for me anyway, and on Ubuntu requires you to install lighttpd (if you don't happen to be on Karmic Koala).
3. You can setup different websites with different instances of php-cgi. This is great for virtual hosting, especially on a development server where the different workspaces may have different PHP settings and you want to run versions in parallel without sharing settings and therefore maybe affecting each other.
4. Icing on the cake: we could even add a custom php.ini to the start call for each instance (-c option) to customize it even further.

Mostly German content ahead!

Die Berliner PHP Usergroup trifft sich am 5. August, ab 20:30 Uhr, in der Z-Bar.

Thema: Debugging mit Eclipse und Xdebug (Vortragender: Marthin Rothenberger)

Adresse:

View Larger Map

Teilnahme: kostenlos

( In English: The next meetup of the Berlin PHP Usergroup will take place on the 5th August, 2009. We'll meet at Z-Bar, at around 8:30 PM. This meetup's topic is Debugging with Eclipse and Xdebug. Feel free to join. The admission is free! (Free, as in free Beer, or something)! )

This week, we just had it. The current provider we pay to host our subversion repositories is just unbearable, and so we decided to move (on) to [Unfuddle][3]. Our reason to move to Unfuddle is that they offer everything we need (and more, e.g. Git), at a pretty good price. I also heard Unfuddle a 100 times when I shopped for a recommendation.

And on top of all the features, they also kick butt at support and for example offered to import our repositories right away. But, has anyone of you tried to dump a subversion repository, ever?

Creating a dump

Being a good user, I rtfm'd first. The manual states to use svnadmin dump. And apparently it's that easy?

Not really.

First off, the manual tells me to: svnadmin /path/to/repo. That didn't work at all though. Instead I had to svnadmin dump /path/to/repo/.svn. But that didn't work regardless.

server# svnadmin ./path/to/repo/.svn
svnadmin: Expected repository format '3' or '5'; found format '8'

server# svnadmin ./path/to/repo/.svn
svnadmin: Can't open file './path/to/repo/.svn/format', no such file or directory

Apparently a more recent version of Subversion cannot deal older repositories?

Updated, 2009-07-23: Apparently it helps to be awake while doing this. The solution to the problem above is rather simple. svnadmin does not work on a checkout, but only on the real repository. So in case you are hosting with an external provider such as Unfuddle, Hosted Projects, CVSDude, Assembla and so on, you won't be able to svnadmin dump on a working copy.

If you ever contributed your spare time to any project which gives away something at the price of zero, you may be familiar with a large variety of feedback.

It's always reassuring for those who spend their time to get feedback from happy users. But of course there's no way to please everyone at the same time. And aside from the usual "This doesn't work!!!11 WTF?!!", some people seem to be particularly ungrateful, or just way out of bounds when they email in.

I hereby classify feedback into three different types:

• valuable
• useless
• mediocre — in between the above

By classifying feedback, I don't mean classify the content. Of course I have to admit that I prefer positive feedback over negative (Who doesn't?), but in the end it's more or less the attitude and effort which people bring to the table — in emails or bug reports.

Even if someone basically told me that something sucks, I can — given it's valuable feedback — work with them to improve.

Last night, a user had the urge to email us (RoundCube) to tell us how ridiculous RoundCube is. So according to him RoundCube does not provide enough features, whatever we provide is not up to his personal standards, he had issues installing it, using it and suggested that we should drop RoundCube and instead provide an ajax frontend to Squirrelmail.

He also managed to insult some ISP (pobox.com), which his "schoolmate from high school" founded.

No offense Squirrelmail (I'm using you as a backup from my non-JavaScript-friendly mobile), but I really don't see anything valuable in the email I read. I could have taken this a lot more personal when I took the liberty to reply. For transparency I copied our [email protected] mailing list on my response.

This morning the user complained to me about sharing his email with the world, told me I attacked his family (Err, what?), then attacked me personally and demanded that I remove his personal information from the archives.

His response was of course emailed off-list and I didn't feel sharing it again to fuel the fire.

Anyway, I did reply on key and stayed away from personals. But I just received another email from him where he emailed the SourceForge legal team and CC'd myself (and most developers again), demanding that we remove his information, or that they make us because I violated SourceForge's terms of service (3A).

Err... it's certainly not going to ruin my weekend. But what the hell?

So, every once in a while I find myself in need of trying out newer, maybe, not-yet-released features in PHP. For example, recently, I wanted to test RoundCube PHP6 — this is how I did it.

On a side note, the same setup would also work for testing code with previous versions of PHP.

Toolbox

I used nginx and the PHP source with a little bit of ./configure and make — for kicks!

My O.S. of choice is FreeBSD and therefor the installation steps covered are tailored to it. With a small amount of Linux/Unix-fu, anyone should make it work on another distribution regardless.

Install nginx

First off, install nginx. On FreeBSD, this should be all:

• cd /usr/ports/www/nginx-devel && make install distclean

On other systems, this maybe a:

• apt-get install nginx
• emerg nginx
• rpm -shoot-myself nginx

The next step includes the infamous spawn-fcgi which many people use to control the php-cgi processes. A lot of tutorials on the net suggest to install lighttpd because it's a part of it, but on FreeBSD, you may skip that and do the following instead:

• cd /usr/ports/www/spawn-cgi && make install distclean

Pretty cool, huh?

So once this is done, the usual tasks need to be completed — in no particular order:

• edit the nginx config and enable fastcgi in nginx (/usr/local/etc/nginx/nginx.conf)
• enable nginx itself in /etc/rc.conf (nginx_enable="YES")
• get another nifty start script (see Shell Script) to wrap spawn-cgi

... and done!