Sam Pointer

The Perl to Rails re-write of www.dailyunixtip.com is drawing near.

Almost all of the functionality required to have a working site is there, there’s a decent suite of tests (that now pass!), and the back-end infrastructure is almost there, thanks to the wonderful people over at hostingrails.com.

So, what have I learnt so-far?

Centos isn’t a patch on RHEL-proper

(But only if you actually pay-up for that support contract). I really mean this.

In previous roles in corporate environments RHEL versions 3 and 4 were prevalent. Big software, big gear, serious stuff, nice men from IBM.

Although I recognise that dailyunixtip.com isn’t even tugging at the coat-tail of that kind of infrastructure I have still be immensely frustrated at how much of a mish-mash the world of Centos package management is. To be able to apply .rpms you know have been tested and will work from a trusted repository with everything in it is a god-send. If you find yourself on Centos, go here for the nearest thing to it.

Of course, I’m not going to practice what I preach and actually buy a support contract, so in that sense Centos fills a niche for small no-budget exercises such as this. You get a de-baged RHEL for the price of nothing, but like repo parts for your Ford Escort: it won’t fit right from the factory.

I suppose that is what is at the core of what has irked me about Centos. I’m all for fiddling and deliving and generally getting deep into the minutae of the technology in front of me. But I’m also a business. I want my time to be spent in my code fettling my process and the infrastructure I have built. That’s what I’m paying or being paid for, and that’s ultimately what’s got to be done to generate the money that makes the whole exercise worthwhile.

Any external distraction (read: configuring external rpm repositories to install a FastCGI-enabled copy of lighttpd) is costing the project money.

Infrastructure changes take time, even in small outfits

In a past life I use to administer to a fairly complex BIND 9 installation, which was used as part of a failure and resilience infrastructure for an ASP service. Having thought about running a small named to take care of dailyunixtip.com and the various sub-domains, I rejected this in favour of leaving the whole thing to my domain registrar.

Again, in a small setting such as this any time spent fiddling with named.conf files would be a waste.

But, there’s a big "but".

You need to do a least a modicum of planning to ensure that all of your domains and subdomains and forward and reverse records are pointing the right way in very good time before you intend to launch. Running your own nameserver is a blessing in disguise for the first part of a new project, when short TTLs can help you rapidly deploy and test supporting infrastructure components such as SMTP servers, Apache and the like.