Hosts Begone!

5 March 2007 | 17:58 | Administration, Linux | No Comments

With my move to virtualisation and seemingly non-stop addition of net-enabled appliances, the hosts file I have on all machines has grown to over 20 entries. I thought it was about time I centralised this configuration and ran a local DNS server.

You always hear how the most common DNS server - bind - is a monolithic beast, but if you have reasonably moderate requirements, the implementation is quite simple.

The setup I wanted to achieve was probably very common for a home network. All machines/devices have static IP addresses and are all part of the same class C subnet. All DNS requests (for both local and remote addresses) should be cached by the local DNS server to improve lookup performance. All external DNS requests should be forwarded to my ISP’s DNS server(s). Adding a machine or changing an IP address should require no more the an update on the actual device holding the IP address in question, and an update to the local DNS server. All other machines should then be able to resolve the new hostname.

If this sounds like something you would be interested in (thanks Entourage - or more specifically) see the installation and configuration on the wiki and say hosts file - begone!.

The next obvious step would be to run a DHCP server too, but that is a story for another day.



The Virtual Bandwagon

19 December 2006 | 10:50 | Administration, Linux | No Comments

It seems that everyone is jumping on the virtualisation bandwagon. Reasons such as server consolidation and improved management seem to be pretty compelling to system administrators, and features such as live migration could be the icing on the cake. Can virtualisation save me too?

The three biggest headaches I have are resource management (e.g. continuously running out of disk space on /), service immobility, and keeping the system current. Regarding the last point, there’s a primal urge to respond when your system status script notifies you that your tar-1.16.r1 has be superseded with 1.16.r2. Who can resist this call to action? Not I! But every time I update installed components I find myself backing up all the configuration files (despite the fact that they haven’t changed since the last update and are included and backed up in my configuration file subversion repository), silently crossing my fingers, and hoping for the best. In addition, my experience/paranoia with hard disks compel me to run the system in a RAID-1 configuration (backup? bah!) which results in the system incurring a non-trivial overhead - particularly with regard to write performance.

Dynamic disk allocation could be achieved with LVM, or - you guessed it - virtualisation.
System portability is by definition a feature of virtualisation, so service separation into different VMs seems to be a reasonable solution to start uncoupling services from physical machines.

With the ability to checkpoint and clone VMs, virtualisation can be used to perform “test updates” - item 3: check!

Now that my spare room has appeared to morph into a data centre, what virtualisation technology is right for me?

There’s Virtual Machines (VMware, Microsoft Virtual Server, Parallels) which emulate all the hardware. It is the most flexible option as you can “pretend” to be running any hardware as far as the guest VMs are concerned, but it’s also most resource intensive. In addition to being isolated from each other, the VMs are isolated from the host machine.

Then there’s Paravirtualisation (Xen) which uses a hypervisor to manage and isolate the VMs either by hardware (using Intel’s VT-x or AMD’s SVM CPU level virtualisation found in recent chipsets) or by loading customised versions of the host OS which has been modified to be aware and behave for the hypervisor. The guest VMs are executing their code natively (albeit under the control of the hypervisor), which means you can only run software targeted for the hardware you are running it on, and if you don’t have a new whiz bang CPU, this limits your guest OS choices to pretty much Linux only. This performs considerably better than the previous option.

Finally there is OS level virtualisation (Solaris Zones, Linux-VServer, Virtuozzo/OpenVZ) which adds a virtualisation layer to the host OS. This is the most limited option, as all your guest VMs need to be the same as your host (although in the case of Linux, not the same distro), but also has the smallest overhead (only 1-2% of resources are spent on virtualisation). Each VM is essentially a chrooted/jailed full file system that is mounted by the host and share the (patched) host kernel (gross simplification - but it is essentially the how it appears to the administrator). What this gives you is full access to the file system of each VM from the host, regardless if it’s running or not.

So where does this leave me? On account of me only running Linux (on the server at least), OS flexibility (or inflexibility) was not a factor. More important was performance - particularly on older hardware, and price. The choice looked between Xen and OpenVZ. When ever I’m faced with a choice, I invariably choose the simplest option (at least initially) and in this case it clearly seemed to be OpenVZ.

Two weeks on and I’m loving it! I can run a debian-based webserver, MySQL under centos, and all my custom services from a gentoo server. I can bind a mount point to each VM (or VE - Virtual Environment - in OpenVZ-speak) to allow the virtual machines share disk which is great both for general storage and things like a portage tree. From the host (or HN - Hardware Node) I can monitor and tune a multitude of resource allocations for each VE which are reflected immediately.

The only area lacking in this solution would appear to be a good monitoring/management interface - but I’m working on it. Stay tuned for further virtual adventures!



WoW Linux!

5 December 2006 | 12:35 | Entertainment, Linux | No Comments

With the latest beta release (6.0.0 beta 3) of CodeWeaver’s CrossOver Linux (formally CrossOver Office) I am finally able to install and run World of Warcraft flawlessly on Linux. In fact, it seems to run better than under Windows XP on my laptop! I tried Cedega and Wine, but neither was as simple and functional as cxlinux.
Although I haven’t used either in quite a while, I’m still concerned about being able to run Adobe Photoshop and Premier, so this may not be the silver bullet to allow me to fully get rid of Windows - but I am definitely getting close. And one 10GB partition out of 4 PC’s and 1.5 TB of disk is a manageable ratio.
People seem to have positive experiences running Photoshop under cxlinux and I’ll be sure to try it out when the need arises.
It it worth the asking US$39.95? HELL YES! Even though I believe pretty much all the code updates are passed upstream to the Wine group, and generally I’m more a DIY person (computer-wise that is), the simplicity of the pre-configured settings for specific applications can not be undervalued.

I can’t wait for the official release!



The cost of small pleasures

7 August 2006 | 18:16 | Administration, General, Linux | No Comments

After reading this article linked to from slashdot (and popular enough to be backslashed), I realised that I too would be happy spending a number of hours reconfiguring my home network just to screw with anyone who had the poor judgement to try and use my wifi.

This as an alternative to leaving my network managed by my routers and its wifi secured with WPA seems like a good use of my time. Sure I need to reconfigure my whole network into multiple segments, install and configure a DHCP server, and setup rules for iptables - but dude - upside down images!

What is it that causes the (admittedly small) pleasures achieved by messing with people - regardless of whether or not you are able to see the effects directly - have such a high personal value that pretty much any effort seems well worth the time and cost it involves?

Maybe it’s just me.



Why I’m an MVC bitch

31 July 2006 | 13:44 | Design, Development | No Comments

With the popularity of MVC frameworks such as (or because of) RoR (Ruby on Rails) I decided to see what all the fuss was about. Well let me tell you, as is the case of life after the introduction of a Tivo - I cannot foresee going back!

I remember, back in the day, learning and using the various system development lifecycles, processes, and models. I remember even advocating completing a design before writing the first line of code. Ahh - those were he days…

In web development, release cycles seem to have been reduced to hours and being able to respond rapidly to changing needs and user feedback is now a critical element in the success of a project.

So how can we enable this level of agility on applications from the get go? In the past the mantra has been “reusable objects”. Surely leveraging the fact that 80% of all applications share the same functionality (statistic obtained using the well established development estimation practice of pulling a figure out of the air) tells us that abstracting and refining and reusing this common functionality will a) provide us with reliable code, and b) enable us to skip this development effort and thus allow us to produce more stable applications faster.

This is all true and reasonably valid except for a couple of points:

1) With the pace of changing technologies being as fast as it is, old (legacy) components are often no longer relevant and as such their “reuse value” is negligible

2) In projects following formal development lifecycles, the actual coding was generally less than 50% of the effort and as such the development savings have little impact to the overall project

3) The primary reason for project failure is a mismatch between the deliverables and expectations (be that functionality, usability, time, or cost)

Understanding this, a more effective way to improve the success rate of a project is to engage application users early and frequently. In addition to this you need to be able to respond to the changes/refinements requested.

This is where an MVC framework really shines.

Here is where I interject the caveat that my current framework of choice (and hence where my experience lies) is CakePHP and as such the features and experiences may not be available in all frameworks.

In the first 5 minutes you can install the framework and have the default page being delivered. From then on there is no required order of development - I can add functionality or design iteratively.

For functionality, once I create a database table I can produce a model with its relationships and validation rules in minutes and I automatically get the CRUD functionality provided for me. I can then decide on an action I want the application to perform and write a controller function to perform this functionality. If it requires interaction with the database, most of the work can be done by calling built in functions on the model(s) and as such the amount of coding required for each discrete piece of functionality is generally quite small. I will then route a URL to this function and hack up a basic HTML view to present the results. I now have a working piece of functionality on the site and can go on to the next piece. If I need to update the database and alter a table that I have already created a model for, all I need to do is update the database and give the model a quick once over in case I need to add, alter, or remove a relationship or validation rule. My controllers will now have access to the updated database structure.

At the same time if I have a designer (or at some point when I am feeling creative) attention can be put to creating HTML templates, styles and the other visual elements that comprise the views. Although there is a fair amount of coupling between the views and controllers (i.e. the controllers explicitly provide the views with data and as such the views need to know the names of the variables being offered), this binding can easily be put off until the controller is complete (or at least is passing all the variables the view expects) and added in later.

As a further enticement, good frameworks will provide a number of additional “tools” to facilitate rapid development. Scaffolding will automatically create CRUD forms to enable you to interact with your data. Helpers for HTML and form generation and validation provide a mechanism to simplify the standardising of experience so that (for example) the whole application reacts to errors in a common manner.

These are just some thoughts and experiences I have had making the (both technical and emotional) jump from n-tier object oriented development to MVC - and as a result I find myself more and more becoming a full-on MVC bitch!



Plasma vs LCD

19 July 2006 | 19:19 | Entertainment, General | 3 Comments

Whilst trying to discover the “correct” new TV for myself, I found I had to wade though lots of information in order to verify (or debunk) myths and identify the distinguishing points.

My conclusions are based on researching the following:

Plasma:
Panasonic VIERA TH-42PV60A
Hitachi 42PD8900TA

LCD:
Sony BRAVIA KLVV40A10
Samsung LA40R71BD

Myths:

1) Plasma TVs have better viewing angles.
It seems that current plasma and LCD TVs both have viewing angles in the range of 170 - 180 degrees.

2) Plasma TVs have less motion blur during fast moving footage.
While this is still correct, good LCD TVs tend to have at most 8ms response times, so this is only noticeable to the most attentive viewer.

3) LCD TVs have a longer lifespan.
This too is generally true but it is becoming much of a muchness. Good plasma TVs boast a comparable 50 - 60,000 hour lifespan these days; are you really going to be watching the same TV in 20 years time?

4) LCD TVs have higher native resolutions.
This is only sort of true. An HD plasma TV is likely to have a resolution such as 1024 x 768 or 1024 x 1080. Competing LCD TVs would have a resolution more like 1366 x 768. In pixels there is not much between the 1024 x 1080 plasma and the LCD, and even if there was this would only be noticeable if you are connecting a non-video source (such as a computer) to it. They will generally both handle 720p and 1080i content and more likely that not also handle 1080p.

Truths:

1) Plasma is susceptible to screen burn.
This is true, but can be mitigated with good management. Try not to leave static images on your screen for more than an hour, and don’t pause a DVD (for example) for more than 20 minutes. This is particularly important during the first 200 hours while the phosphors are still fresh. Try to watch 4:3 content in full screen so you have no black bars to burn in.

2) LCD is more expensive.
Once you reach the 42″ size, this is still true, however sometimes you can get a good deal on a 40″ LCD which brings it to a price comparable with a 42″ plasma.

3) Plasma has better colour/contrast.
This is generally true and people who like bright screens should see the next point. Common plasma contrast ratios range between 4,000:1 and 10,000:1 where LCD is more likely to give you between 1,000:1 and 5,000:1. Plasmas also tend to have more uniformity (evenness) in brightness and colour from corner to corner.

4) LCD’s provide better daylight viewing.
Both the fact that LCD’s are generally brighter than plasma’s and don’t have plasma’s reflective screens make LCD’s easier to see and less prone to screen glare than plasma.

5) LCD’s consume less power.
This would be truer if phrased as “LCD’s consume MUCH less power”. LCD’s generally consume anywhere between 30-50% less power than plasmas. As an additional consequence, plasmas get hotter than LCD and generally have cooling fans - some that are quite audible.

I’m confused - is there a winner?

In order to find the one that’s right for you, you need to do 2 things:

1) Compare the technologies
2) Identify the model with the features you need

Comparison Points:

Picture:
Are you likely to watch much in daylight? Do you generally watch with lights on that would reflect on the screen? If so you have to lean towards LCD - but remember you are sacrificing the colour and contrast when you are watching in optimal conditions. Would you rather the experience is great while watching in daylight/lights on and average in low light or average in daylight/lights on and great in low light?

Price/Cost:
Plasma is generally cheaper than LCD at the 40″ (LCD) - 42″ (plasma) size. This gap is even greater if you want to go to bigger (such as 50″). If price is a consideration (and let’s be honest - when isn’t it?), this should be acknowledged as a factor. Don’t forget that the price isn’t the whole cost though - with an LCD using 50% less power you may find this cost saving a factor.

Resolution:
Are you going to be using the TV to do more than watch video content such as act as a computer monitor? If so, this should only be a factor if you find an LCD TV with a much greater resolution.

Features:

Inputs/Outputs:
Does the TV have all the connections you need? Does it have HDMI? If so how many?

Tuner:
Do you need a tuner (i.e. are not going to feed it from a cable box/digital stb/media center)? If so what type (analogue/standard digital/HD digital)? Do you “NEED” 2 tuners?

Conclusion

These are just the facts. Personal perceptions and tastes should always weigh more heavily than technical differences.

For most people I believe it should be a simple 3 step process:

1) Identify the features you NEED from the Features list above

2) Determine how much you can afford / are happy to spend

3) Go to as many stores are you can and look at the TVs within your budget that have the features you need

I’m sure you will not be disappointed - and if you are it’s because your budget was set to low ;-)



Back it up!

17 July 2006 | 22:38 | Administration, Linux | No Comments

Why are people (including myself) so lazy about backing up their data?

Do we assume the “managed” in the $4.95/month managed server takes care of this for us? Do we think the risk of failure is so small that it will only happen to other people? Do we think it will require a large and ongoing effort? Do we just not know where to start?

With the cost of hard disks being so low these days, these seems to be no reason not to have a copy of at least your most important databases and files on a separate disk to ease the pain when that dark day that you will forever call “the hard disk crash of {insert year here}” comes.

A combination of this thought and the inherent laziness that most programmers have prompted me to look into what this actually would entail. I believe that the end result was simplified by the fact that I run mostly Linux, but I’m sure with cygwin or something similar, the same can be pretty much achieved on windows.

The end result is a set of scripts for backing up MySQL and transferring data (both the MySQL backups, and other data such as my websites) to a remote server. If I create a new database that needs to be backed up, I just have to grant access to it for the backup user and restore user and it will automatically be included in the backup routine. If I want to backup a new folder, I need to add it to my backup script and it will be synced according to the next schedule. Alternatively, I could create a symlink for all top level folders needing backup inside a common “backup” folder and only need to backup that folder, but this reduces the flexibility of being able to backup my websites to machine1 and audio (for example) to machine2. Once a month each backup will be restored to a scrap table for verification. Finally, due to the magical default behaviour of cron, anytime an error is encountered, I will be notified via email.

Information including all scripts for the MySQL backup can be found on the wiki: http://wiki.accordingtokris.com/index.php?title=MySQL_Backup

Information including scripts for content backup can also be found on the wiki: http://wiki.accordingtokris.com/index.php?title=System_Rsync_Backup

Enjoy - and no more excuses if when you have a disk failure!