For example:

  require 'xapian-fu'
  include XapianFu
  db = XapianDb.new(:dir => 'example.db', :create => true,
                    :store => [:title, :year])
  db << { :title => 'Brokeback Mountain', :year => 2005 }
  db << { :title => 'Cold Mountain', :year => 2004 }
  db << { :title => 'Yes Man', :year => 2008 }
  db.flush
  db.search("mountain").each do |match|
    puts match.values[:title]
  end

The full announcement is here, github project here and rdoc here.  Hope you find it useful!

Firstly, where the same (or very similar) query occurs more than once, they are aggregated together rather than being recorded as individual slow queries. The user interface displays the count so you can see exactly how many times this slow query occurred in the last 7 days.

Secondly, the full SQL query is now displayed, so customers now have more information with which to optimise their applications.

Today I’m pleased to announce a new revision of the Brightbox Deployment Gem, version 2.3.6. This release fixes some of the issues reported to us by our users, along with a few extra features.

The documentation on the wiki has been updated with the new fixes and features. If you have any tips or find any errors just let us know.

NEW FEATURES

Apt Package Dependencies

Just as you can currently define gems your application relies on and have them automatically installed onto your servers, you can now do the same with apt packages. Define them in your deploy.rb and they’ll be installed before installing your required rubygems, which means you can use it to install apt packages that gems depend on. As an example, the nokogiri gem depends on a couple of apt packages.

depend :remote, :apt, "libxml2-dev"
depend :remote, :apt, "libxslt1-dev"
depend :remote, :gem, "nokogiri", ">= 0"

Intermediate SSL Certificates

Support for Intermediate SSL Certificates in Apache has been added, meaning you no longer need to manually edit the Apache config files directly. Just add one line to your deploy.rb and the gem now takes care of updating the Apache config for you. An example SSL configuration:

set :ssl_certificate, "my_cert.pem"
set :ssl_key, "my_cert.key"
set :ssl_intermediate, "intermediate.crt"

See the wiki page for Adding SSL Support to Apache for more information.

Deploy.local.rb

A common issue we’ve seen with is setting the deploy password. If you put it in deploy.rb, then it inevitably ends up in your source control repository, which is a bad idea. A workaround we’ve suggested in the past is to have a deploy.local.rb file, which isn’t tracked by source control, and load that from within your deploy.rb file. This allows you to have the password (or any other sensitive settings) defined, but kept outside your source control.

As part of this release, the gem now has official support for a deploy.local.rb file. If it exists, the gem will load it in for you.

For more information see the Advanced Gem Settings page on the wiki.

Disable (re)generating webserver config

If you’ve made manual changes to your webserver (apache or nginx) configuration, then you don’t want an accidental deploy:setup to overwrite your configs. Up until now you just had to avoid running the command, but now there’s a setting to disable it for you.

set :generate_webserver_config, false

FIXES AND ENHANCEMENTS

• Max Age setting now accepts a number as well as a string
• deploy:initial reloads Apache so the new config is loaded

We’ve been reasonably resistant to publishing an SLA until now, not because of doubts over our infrastructure or ability to deliver, but because of the minimal value we felt it would add for customers in the event of actual downtime. We’re a pragmatic bunch at Brightbox and like to avoid adding things just for the sake of it or “because everyone else does” :)

However, and it’s a pretty big “however”, we understand that for many people an SLA or “uptime guarantee” is a useful gauge of whether a provider is actually willing to “put their money where their mouth is” and make a financial commitment to meeting a specific minimum target.

So, I’m pleased to announce that from 1 Jan 2010 (backdated) Brightbox offers a 99.95% SLA on virtual machine and load balancing products (see Terms and Conditions for details). We’ll likely expand the SLA soon to also cover our MySQL products and other products currently in the pipeline, but we’ll need a different method of assessing “availability” for these products.

We’ve been developing a more robust solution for users and accounts for some time and hope to launch this new system in the next few weeks. In this post, I’d like to give a sneak preview on the forthcoming changes…

• Each person will have a Brightbox user account
• We’ll be introducing a number of “roles” (tbc)
• Each account will always have an “owner” contact, this person is ultimately responsible for the account
• Existing Brightbox account holders will be migrated to a new owner contact
• The account owner will be able to invite additional users to their account
• The control panel will enable users with access to multiple accounts to easily move between the accounts to which they have access

Over the next couple of weeks, all customers will receive an email explaining the changes and the migration process.

This package won’t actually support Rails 3 just yet though as we’ve yet to package and test the librack 1.1.0, which Rails 3 depends on.  We’re working on it now and once we’re happy with it we’ll add new packages to our repository as usual.

Brightbox is also sponsoring the meeting so there will be free pizza afterwards (free as in pizza, not as in speech).

More details on the NWRUG blog page.

Hope to see you there!

We’ve built a bunch of new master-master replicated pairs and our backend systems now distribute customers between them on sign-up. We’ve also been contacting some customers and moving them to new clusters, to relieve the pressure on the main cluster (customers with heavy requirements are still recommended managed dedicated clusters – these will be available to purchase simply as additional products soon). We’re using puppet to automate a lot of the setup of the new clusters and can deploy a new one, with monitoring and backups, very quickly.

This work has almost quadrupled the shared MySQL resources within the space of a couple of weeks, and provides a simple platform to continue scaling indefinitely. The decentralisation also makes some aspects of administration easier, such as arranging downtime for maintenance.

The visible differences are small: rather than everyone connecting to one address, sqlreadwrite.brightbox.net, each account needs to use the address provided in the control panel. The old sqlreadwrite.brightbox.net has become db01.mysql.vm.brightbox.net (the old name will of course continue to work indefinitely), and the new clusters are at db02.mysql.vm.brightbox.net, db03.mysql.vm.brightbox.net etc. Our wiki documentation has been updated to reflect this – customers on the old cluster don’t have to make any changes, it only really affects new customers and customers we’ve contacted to arrange a move.

We’ve also been working on improving the slow query logger to provide more useful results. Instead of reporting every slow query ever logged, it produces an intelligent summary of the week’s queries. This means when you see a slow query in the control panel, it means it’s shown up repeatedly and very likely needs attention, as opposed to queries that just happened to take longer than usual due to load on the cluster. We’ll be rolling this work out just after Christmas.

This work represents a big investment in our shared MySQL platform, which we know is invaluable to a lot of our customers, and allows us to keep growing without sacrificing performance.

sudo apt-get update
sudo apt-get install libapache2-mod-xsendfile
sudo a2enmod xsendfile
sudo invoke-rc.d apache reload

The graphing service is currently in beta, so you might find some occasional gaps in data for the time being, but over time this should prove a very useful feature.

Experienced programmer Paul was a beta tester for Brightbox back in our very early days and has now come on board as our new senior developer. He’ll be joining Baz and Caius working on our customer-facing control panel and our behind-the-scenes systems, and he’ll also take a lead in project managing all the development side of things.

Welcome to the team, Paul!

Brightbox is sponsoring the event and John will be speaking on Thursday about the wonders of UNIX – how its often forgotten tools can help with Ruby on Rails development and deployment.

They’ll also have some of our highly coveted tshirts and stickers to give away so if you’re going, make sure you track them down and say hello.

As usual, details on installing the packages from our repository are available on our wiki.

If you’re using Passenger and it’s making you happy, please do consider supporting its development by donating money in the form of an “Enterprise License” direct from Phusion, the company behind it.

However, this session data is never deleted, which means your session table continues to grow and grow forevermore. Your old sessions are left stored in the database, and although the table is indexed to help with finding sessions, it will eventually fill the disk up.

At this point you might be thinking the solution is obvious, just empty the sessions table after so long and let it fill up again. Rails even provides a rake task that does this for us, rake db:sessions:clear. The problem with taking this approach is that any active sessions get lost as well, which could be people with items in their baskets, currently logged in users, etc.

There is another solution, which is to only delete sessions that we consider to no longer be active. The updated_at column in the sessions table has an index on it, and thus looks designed for this type of query to be run. On the Brightbox control panel, we’ve decided this is session data that hasn’t been updated for over 24 hours. (A side effect of this is customers that haven’t visited the control panel in the last 24 hours are logged out. We’ve decided this is ok, but YMMV of course.)

We use the following rake task that clears out sessions 24 hours or older, which is run via cron at 3am every morning. You can change the threshold by editing "1 DAY" in the query, see the MySQL DATE_ADD() docs for valid values.

desc "Clear expired sessions"
task :clear_expired_sessions => :environment do
    sql = 'DELETE FROM sessions WHERE updated_at < DATE_SUB(NOW(), INTERVAL 1 DAY);'
    ActiveRecord::Base.connection.execute(sql)
end

Expiring the cache is just a case of deleting the html file. But what if you want to expire an entire tree of cache files? Say you change something in a header or footer, so every single page needs expiring at once.

The usual way to do this is to just delete the entire page cache tree, with FileUtils.rm_rf.  This works pretty well, but with a big tree you’ll get strange behaviour under high load due to concurrent access.  Whilst your rm_rf process is deleting the tree, file by file, your webserver will still be looking in there for page cache files and Rails will still be trying to write them.

This is easily solvable.  On a POSIX compliant filesystem, like EXT3, the rename operation is atomic – it either happens or it doesn’t, there is no in-between state where it is half renamed or anything.  So, before running the rm_rf, you rename your highest-level cache directory to something temporary.  This means the cache expiry is instantaneous, even if you have 100 meg of page cache, and you won’t get Rails writing new page cache files into it whilst you delete it.

It’s a good idea to use a robust temporary filename format so two processes don’t end up renaming a cache directory to the same thing at the same time, especially if your page cache is on a shared filesystem.

An example snippet of code follows. It assumes you want to expire pages from the controller named entries.

require 'socket'
tmp_cache_dir = [Socket.gethostname, Process.pid, Time.now.to_i, rand(0xffff)].to_s
page_cache_tree = File.join(ApplicationController.page_cache_directory, 'entries')
FileUtils.mv(page_cache_tree, page_cache_tree + tmp_cache_dir)
FileUtils.rm_rf(page_cache_tree + '-' + tmp_cache_dir)

This renames RAILS_ROOT/public/entries to something like RAILS_ROOT/public/entries-hostname22351125837834752773 (which should be sufficiently unique across a number of nodes in a cluster as to avoid collisions) and then deletes it.

If you want to expire the entire page cache, you’ll need to change the default from RAILS_ROOT/public as you can’t rename and delete that (it has images and javascripts etc. too!). Change it to something like RAILS_ROOT/public/page_cache. You’ll need to update your web server config to consider this new path too.

Remember that rename is only atomic within the same filesystem, so if you symlink your page cache directory from your RAILS_ROOT onto a shared filesystem, then you need to do all your renames and deletes within this.

Also, this has the side effect of working around a bug with our shared filesystem, GlusterFS, which got upset with multiple concurrent directory tree deletes (this is now fixed though).

As with our other Ruby EE packages, they upgrade (i.e replace) the standard 1.8 Ruby installation. This means all your gems stay the same, and everything on your system immediately starts using them (Phusion’s own Ubuntu packages do not work like this).  We’ve tested it with the usual Railsy native gems, RMagick, Mongrel, fasthread etc. and have had no problems.

If you’re on a Brightbox, just edit /etc/apt/sources.list.d/brightbox-rubyee.list and change the rubyee component to rubyee-testing:

deb http://apt.brightbox.net/ hardy rubyee-testing

Then update and upgrade:

sudo apt-get update
sudo apt-get install libruby1.8

If you’re not on a Brightbox, see the instructions on our wiki first. The wiki also documents how to revert back to the old packages.

As said above, we now have 64bit packages available too (which was recently made easier by some Debian package dependency updates, also included in our repository).

Please let us know how they worked out for you on our forum. Thanks!

The Control Panel that you may be familiar with uses Delayed Job. This is a Rails-specific gem that uses the database as a queue, with a nicely packaged worker process that handles messages as they arrive. Because the Control Panel only ever talks to Rails from Rails, this worked extremely well.

However, our other systems were not homogenous – there are a number of different interfaces that needed to be instructed at various times and across various machines, and Delayed Job didn’t really fit the bill. In particular, there were some tasks that could only happen on certain servers – while Delayed Job let us have multiple worker processes on different boxes, it essentially managed a single queue, so it could not differentiate between messages for one worker and messages for another.

AMQP to the rescue

Because of this, we looked elsewhere for our central work queue. We decided to use the AMQP protocol, with RabbitMQ as our implementation. AMQP is a protocol for taking incoming messages, placing them on one of many queues and routing them to a destination reliably; RabbitMQ is a server, built in Erlang, that is pretty lightweight and has some nice clustering features built-in.

Into the Warren

When it came to getting our Rails applications to talk to RabbitMQ, we had a couple of choices.

There is an AMQP gem which looked great. Unfortunately, as it uses EventMachine internally, it caused a few problems with our Passenger-based deployments – EventMachine opens a background thread which can cause issues to the web-server controlled Passenger processes.

There was also a gem called bunny. This works synchronously, thus avoiding the EventMachine issues – you connect and bunny either says “here’s the next message” or “the queue is empty” and then you disconnect.

It looked like bunny was perfect for our Passenger-based apps, with the AMQP gem being used in the non-Passenger side of things (actually in the end, we went with bunny on both sides, but for other reasons). But there was still a couple of things that we wanted to do with the messages.

Firstly, we are Rubyists and AMQP (the protocol) is language agnostic. In particular, we wanted to put a hash of data onto the queue and have a hash of data presented to us at the other end. Secondly, security is important to us – especially when it comes to tasks like rebooting or reconfiguring a server – so we wanted to ensure that the contents of the message were not tampered with in transit.

For these reasons, we built Warren. This adds filters over the AQMP layer. In our case, we had one filter that automatically marshalls the data to and from YAML as it is put onto and taken off the queue and a second HMAC filter that, with one line of configuration, ensures that the data was not altered on its journey.

Warren itself has an adapter layer, so it can quite happily use either the AMQP gem or bunny to actually talk to the queue. Adding new adapters, or filters, is as simple as creating a new subclass – Warren detects it and adds it to its stack.

Bigwig

With Warren it is pretty simple to put a message on to the queue:

Warren::Queue.publish(@queue_name, @hash_of_data)

It is just as easy to pull the messages off the other end:

Warren::Queue.subscribe(@queue_name) do | hash_of_data |
  do_something_with hash_of_data
end

But how do we implement this mysterious do_something_with(hash_of_data) call?

For our purposes, the endpoint needs to do different things depending upon which machine we are on and which queue we are listening to. The key one is our “builder” system which handles reboots, migrations and deployments, but there are several others, which while not yet live, will be coming onstream soon.

So effectively, we needed a set of daemon processes that listen to given queues and handle the messages that they receive. This splits into two components – the daemon framework and the workers themselves – which lead to Bigwig (keeping the rabbit theme going, Bigwig was a character in Watership Down).

Bigwig expects a configuration file, telling it how to connect to the AMQP server and a folder full of plugins. Each plugin is a simple Ruby class that performs a given action. Bigwig takes the incoming messages, looks for a parameter within the Hash called “method” and then uses that to find a plugin. The plugin is then invoked and can perform whatever tasks it needs to, using any data from the incoming message.

For monitoring purposes, Bigwig automatically deals with any incoming messages with a method of “ping” – these simply write a message to the log file. We can then send ping messages to the queue at set intervals and monitor that the log file is updated when expected – if we don’t see the update then we trigger an alert, in case the queue, or Bigwig, is down.

If the queue itself goes down, for whatever reason, then Bigwig uses an intelligent reconnect pattern. At first, it retries often, to minimise the downtime, but if the queue stays down, it reconnects less frequently, giving the queue a chance to restart before being swamped with connections. Of course, if the queue fails, then the ping messages won’t make it through and our monitor should alert us.

Calling back

Our primary internal application creates a Task object, with a unique identifier when dispatching tasks across the queue. This ID is then passed onto the queue and each Bigwig plugin is told of it when it is invoked. The application itself makes the Tasks available over ActiveResource.

This means that the Bigwig plugins themselves don’t actually need data passing over the queue. Instead, when they are invoked, they call back into the primary application, using the Task ID as the key to their ActiveResource call. They can then extract the data they need from the Task object and use that to do whatever they need to do. When completed, they call the complete! method on the ActiveResource object and our application knows that the job has been done (alternatively, they can call error! and our app knows that something went wrong). All of these appear in an event feed on the application’s homepage – so we know at a glance what activity is happening across our systems and, more importantly, what has failed.

We could have implemented this using AMQP again – a ‘responses’ queue that our primary application listens to, with each worker putting a message back when it was done. But we chose to use ActiveResource, partly because it is so simple (Rails makes it super-easy to expose your objects as XML and ActiveResource makes it equally easy for other Ruby programs to call back to them), and partly for philosophical reasons. When the primary application places a message onto the queue, it doesn’t necessarily know how it will be handled. AMQP dispatches it and a listener deals with it – in our case the listener is likely to be a Bigwig instance, but doesn’t have to be. But when the callback is made, it is always made into our application, which is already geared up for completing tasks or marking them as having an error. As we know that it is a Rails app at the other end, we chose to follow the path of least-resistance and use the “Rails way”.

However, we did have one issue with ActiveResource. Most of our plugins actually shell out to invoke Ruby scripts, with the plugin unpacking the information from the Task and generating command line arguments. This is a slight security risk, just because it is feasible that someone could inject a malicious command into the command line parameters (although as this is all internal it should never be an issue and Ruby’s system command does escape any supplied parameters). So we are switching the scripts to accept environment variables, thus bypassing the shell and eliminating a whole category of potential attacks. Secondly, using ActiveResource in a non-Rails application caused some weird errors – but only when you tried to POST back to the ActiveResource object. It turns out that ActiveSupport was causing some shifting to occur in the background and that was knocking out some of our own code. The solution was simple – we had to ensure that the require 'activeresource' statement was the first thing in each script.

So that’s a quick peek into the workings of some of our internal systems. We put a lot of thought into how these different components should work together, as their reliability is fundamental to our success as a business. And while they are not infallible (nothing ever is) I think you will agree that they show that using Ruby and AMQP as the “glue” to tie different systems together is not only feasible, it’s actually quite easy.

Caius

Hardware

• 15” Macbook Pro (Unibody) with 4GB ram, 7200rpm 320GB HD
• 48GB SSD Expresscard
• 24” Samsung External Monitor

Software

• TextMate – My third arm.
• iTerm – Gives me back cmd-<num> for switching tabs
• Adium / Tweetie / Limechat for communication
• Safari – Eats ram, but I still prefer it to any other mac browsers
• HTTP Client – Graphical curl, great for debugging XML calls
• Markdown – I write everything in it.

George

Hardware

• Thinkpad R500, Core 2 Duo P8600 2.4GHz, 4GB RAM, 250G 5400rpm disk, Windows Vista Home Premium license.
  Running Ubuntu Karmic; was intended to be Jaunty, but there was just too much broken stuff in it for this (quite new) Thinkpad. A great fat heavy breezeblock of a thing, but superb keyboard and display mean it can be used all day and it’s far and away the most powerful computer I’ve ever had.
• Acer Aspire One for emergencies. – Running Ubuntu Netbook Remix. (I’ve blogged about it before). Cute, useful – lovely little machine.
• Draytek Vigor 2820n and emergency backup ZTE 627. – Not that big a step up from the Prism VTX5000.
• Old no-name P4 box and 23” LCD.
  It’s shit but it’s mine. All the other computers are Brightbox’s. Personal email, house fileserver, source of graphs and music, controller of the central heating, footrest.

Software

• Lots and lots of xterms – still the best way to use computers.
• GNU screen.
• Windows XP inside KVM – for those “need IE” moments, chiefly involving Dell DRAC cards or suppliers’ support websites.
• Mozilla Thunderbird – For work email.
• Alpine – For personal email.
• Pidgin IM – I’m indifferent to it, but it works.
• joe – Because I learned WordStar at age 11 on my first PC, from my dad, who knew it and may well have used it before I was born.
• Google Chrome – Intuitive, fast, stable, and pretty. If the Google monopoly will make everything this good then bring it on.
• Google Calendar.

Jeremy

Hardware

• 15” Macbook Pro (Unibody) with 4GB RAM – the best machine I’ve ever owned by far both in terms of reliability and design
• 20” Dell 2005FPW external monitor at the office

Software

• TextEdit – I find myself writing lots of notes in plain txt files
• Yojimbo – collate all sorts of notes, PDFs etc
• Fireworks CS3
  I often use the Mac “common library” objects to quickly mockup forms which works nice. Probably the last Adobe software I’ll ever buy, they have a horrid licensing policy and the software is generally bug ridden. I probably could have built a small city with the money I’ve wasted on Adobe licences over the years
• Safari – not exactly lightening fast, but I’m used to it (I use DeliciousSafari plugin as CMD+D which is nice)
• Adium – nuff said
• Terminal – with Ciarán’s terminal tab switching bundle

John Leach

Hardware

• ThinkPad R61
• Some kind of EeePC for on-call on-the-go
• Bialetti stove-top coffee maker
• Xbox 360

Software

• Debian, Ubuntu.
• Ruby!
• SSH, bash, Capistrano, Puppet.
• Wireshark protocol analyzer – How do people troubleshoot anything without it?
• Strace, gdb – Useful for detecting how much crack a developer has been smoking.
• Emacs for development.
• Vim for config file editing.
• Tomboy for note keeping. I keep a LOT of notes.
• Redmine – It’s what projects crave.
• Guitar Hero

Louisa

Hardware

• Dell XPS M1330 – came pre-installed with Ubuntu and it JustWorks™
  Using Hardy – I prefer stability to the bleeding edge (ie, change scares me).

Software

• I mostly live in Firefox even though I suspect I should be using Google Chrome (see aforementioned comment re: scaredyness)
• I do a lot of admin stuff in OpenOffice but find I’m more productive actually writing stuff in gedit because then I don’t get obsessed with formatting and fonts
• I use a combination of TomBoy and a text file called scratchpad.txt for notes/drafts of stuff in progress
• I use Pidgin for IM/IRC
• I use GIMP and Inkscape a lot for photo-editing & design stuff (although not really that much for Brightbox because Jeremy is so much better at it than I am ;) )
• Talking of not-for-Brightbox design stuff, I use KXStitch for designing stitch charts for (often geeky) craft projects

I prefer a paper desk diary instead of using Google Calendar or to-do list software, but have to use the former to keep up to date with the rest of the team

Rahoul

Hardware

• Macbook Pro 15” Core 2 Duo with 3Gb RAM
  Running Leopard as I’ve not had time to upgrade to Snow Leopard yet
• EeePC 701 for emergencies
  Running Ubuntu Netbook Remix
• MacMini Core Duo
  Running Snow Leopard

Software

• Coda and Textwrangler – Believe it or not, I don’t like Textmate
• Adium and Nambu
• Fluid – To keep my important web-based stuff separate to Safari
• Acorn – Can’t afford Photoshop, don’t want it
• The Hit List, iCal, Spanning Sync and Google Calendar – Productivity ahoy
• Windows Vista inside VMWare, with IETester – Because IE6 still exists

Shared tools

And finally some shared tools that we all use for various things.

• Xero for our accounts
• Highrise to keep track of sales/marketing stuff
• Dropbox for quick’n’easy doc sharing
  (I love how it JustWorks™ on Linux—Louisa)
• Redmine for project management and bug tracking.

You’ll work closely with our Technical Director and Senior Sys Admin to run our virtual hosting platform, our Ruby on Rails hosting clusters, our network and our MySQL databases. A full job description is below.

The role is full-time and you can work from home, from our office in Leeds, or a bit of both (the rest of us do a bit of both).

Send a hello, a CV and salary expectations to jobs at the Brightbox UK domain. CVs should be in an open format, preferably PDF or plain text. Closing date is 24th October 2009.

As always, recruitment agents should e-mail our special recruitment company email address: root@localhost

• More jobs available at Brightbox
• More about working for Brightbox

Linux Systems Administrator

Job Description

• Work under the Technical Director and with our other system admins to support and run:
• our customers’ Ruby on Rails hosting clusters
• our virtual hosting platform
• our MySQL systems
• our networking infrastructure
• our backup systems
• our network management and monitoring systems
• Provide excellent customer service and support
• Assist with technical sales
• Participate in an out-of-hours on-call rota
• Work from home or our office in Leeds, or a mixture of the two
• Occasional visits to our hosting data centres for new builds and hardware maintenance
• Update technical and process documentation

Qualifications

• 2+ years experience with GNU/Linux based systems
• Experience with web technologies such as NGINX, Apache & mongrel
• Experience with Ruby, Rails desirable
• Familiarity with Puppet, Virtualization, MySQL, PostgreSQL, LVM desirable
• Familiarity with common Internet services such as DNS and SMTP
• Experience working with customers
• Ability to work both independently and as part of a team
• Keeps up with new technologies and developments
• Good written and verbal communication skills
• Able to commute to Leeds, UK for team meetings

I wanted one that worked well with Linux, preferably Ubuntu Netbook Remix, had SSD rather than hard disk, and built-in 3G connectivity.

I’ve picked the Acer Aspire One (AAO) A110. It was available in the UK from Tesco in this spec with 1GB of RAM for GBP 179 – a bargain.

It came with a truly dreadful pre-installed build of Windows XP Home. Very slow and very much not recommended. Ubuntu Netbook Remix is, on the other hand, superb.

I’ve installed the pre-release Ubuntu 9.10 “Karmic”. Here’s what I’ve found that’s specific to the A110. I’ve written up these notes in the hope that they’ll be useful to someone else thinking of running Linux on an AAO. While there is a wealth of information about it out on the Internet, it’s not all collected together in one place.

• The 3G unit is an Option GTM380 (USB ID 0af0:7211). SIM card goes in behind the battery in a very strange orientation – connectors facing outwards – but the correct orientation is the only one it will click home in. This is a good card and works well out-of-the-box in Ubuntu. I’m using a “3″ PAYG SIM in it, with the “50p for a day’s Internet” offer, but it’s unlocked for all networks – if 3 isn’t available, I can pop in the SIM from my own phone very quickly.
• The wireless toggle switch on the front works in a slightly unexpected way. When “disabled”, both the 3G and Wifi interfaces still appear to the OS and can be configured – but their radio interfaces appear to be disabled so they can’t communicate.
• The 3G Wifi, sound, webcam, keyboard and synaptics touchpad all worked fine out-of-the-box. There are widespread complaints on the Internet about the poor quality of driver support for the Atheros
  chipset the wifi uses, but it’s fine for me in Ubuntu Karmic.
• The left-hand SecureDigital card slot works as shipped, but the right-hand (multi-card) one is not detected. To fix this, edit the kernel command-line (in /etc/default/grub) and append “pciehp.pciehp_force=1″, then run update-grub2 and reboot.
• The above SD slot fix also fixes suspend; without it, the AAO hangs on resume.
• The SSD is quite a lot slower than a traditional hard disk, but uses less power and is more robust. To compensate for the slowness there are a few things we can do.
  • Mount the root filesystem “noatime”. This stops it from recording the last time every file has been accessed – a functionality few people need. Add “noatime” to the options for “/” in /etc/fstab to do this.
  • By default, Linux tries to combine hard disk activity involvin parts of the disk which are close together. Normally, this is faster because it reduces the amount of (slow) seeking the disk has to do. The SSD is solid-state, so seeking is free – we can get quite a speed-up from disabling this behaviour by adding “elevator=noop” to the kernel commandline. In the new Karmic grub2 this is controlled from
    /etc/default/grub, and you need to run “update-grub2″ after editing it.
  • If you want to take this a bit further, you can reduce the amount of syslog logging, or have syslog log to a tmpfs (memory) filesystem.

• The BIOS will control the internal fan adequately, but it’ll end up turned on quite a lot. It’s pretty quiet, but you can silence it completely by turning it off unless the AAO’s innards are properly warm.
  Beware if you play with this that it may be possible to cause permanent damage to the AAO by overheating if you set these values incorrectly. You may also render your AAO inaccessible by causing it to become just pleasantly warm, which results in your cat going to sleep on top of it.
  • Fetch the “acerhdf” source from http://piie.net/index.php?section=acerhdf; I’m using 0.5.17 with Ubuntu’s 2.6.31 kernel.
  • You’ll need the Ubuntu linux-kernel-headers package installed, and the C compiler & libraries; if you install the “build-essential” package, it depends on everything you’ll need and it’ll all get installed for you.
  • untar, “make” and “make install” the acerhdf module.
  • As of 0.5.17, the module behaves slightly differently to how its README file suggests. What you now need to do is:
    - “modprobe acerhdf verbose=1″
    - Watch the kernel log (dmesg) to see if it’s outputting succesfully
    - If it is, then add the module to your /etc/modules with your desired parameters – I’m using “acerhdf fanon=75 fanoff=70 verbose=1″
    - Enable it by adding a line above the “exit 0″ in your /etc/rc.local: “echo -n “enabled” > /sys/class/thermal/thermal_zone0/mode”. It will then take effect at next reboot
• BIOS flash – if you have anything before v3309, upgrade to get worthwhile fixes (eg to the card readers). Alternatively, Packard Bell and Gateway 2000 both make a model of Netbook which shares hardware with the AAO.I like the Gateway 2000 BIOS because
  • It changes the BIOS logo to a cow-coloured cube.
  • It provides a better choice of screen brightnesses, specifically giving the option of a really low brightness level, which saves battery power and is still ample for low-light conditions.
  • Fetch it from here – note that this probably voids your warranty:
    http://sites.google.com/site/maclesblogspotcom/BIOS/PBG

Useful AAO links

• AAO blog http://macles.blogspot.com/
• AAO Ubuntu pages https://help.ubuntu.com/community/AspireOne
• AAO forums http://www.aspireoneuser.com/forum/

Some non-AAO-specific suggestions

• Throw out Firefox and get Google Chrome installed. The Linux version is now more than ready for everyday use.
• If you want remote-control of your Netbook (eg as you configure it), the VNC Server package for the Ubuntu desktop is called “vino”. It’s not installed by default in UNR.
• I strongly recommend removing the “quiet” and “splash” options from the Kernel command line – again in /etc/default/grub. This removes the pretty graphical effects at boot-time, but allows you to see what’s happened if something goes wrong.

nginx … is vulnerable to a buffer underflow when processing certain HTTP requests. An attacker can use this to execute arbitrary code with the rights of the worker process  or possibly perform denial of service attacks by repeatedly crashing worker processes via a specially crafted URL in an HTTP request.

New versions of our nginx packages that address this security vulnerability are now available.  nginx 0.6.39 (with the fair balancer module) is available from the Brightbox apt repositories – running the following command will get you the latest version:

sudo apt-get update
sudo apt-get install nginx

Our more experimental nginx-brightbox package has also been upgraded to 0.6.39.  This includes a number of nginx addons, such as the upload module, geoip module, and Phusion Passenger 2.0.5.

All versions of Rails above and including version 2.0 are affected. There are two new official releases to fix this, 2.3.4 and 2.2.3.  If you’re still running Rails 2.0 or 2.1 and can’t upgrade, patches have been provided by the security team but need applying manually.  In this case, we’d recommend vendoring the rails gems and then applying the patches.

More details from the security team here.

The next event, on Wednesday 9th September at The Crypt in Clerkenwell, will be a Coding Dojo which sounds like fun! Don’t forget to register as early as you can if you’re going.

You’ll work closely both with our Development and Technical Teams to develop our customer control panel and other backend systems. We’re looking for someone who, in addition to being a great coder, will be an integral part of the team and an organised and enthusiastic project manager.

The role is full-time and you can work from home, from our office in Leeds, or a bit of both (the rest of us do a bit of both).

Send a hello, a CV and salary expectations to jobs at the Brightbox UK domain. CVs should be in an open format, preferably PDF or plain text. Closing date is Friday 11th September 2009.

As always, recruitment agents should e-mail our special recruitment company email address: root@localhost

Job Description

• Work under the Technical Director and with our other developers to:
• Maintain and extend our “cloud” management systems
• Maintain and extend our billing system
• Build the front end for our next generation of deployment systems
• Help with application consultancy (advising customers how to design and scale their apps)
• Work on side-projects that help the community and promote Brightbox (such as isitruby19.com)
• Extract code to be shared with the community as open source/free software
• Invent and develop new ideas for services and products
• Project manage several concurrent projects
• Work from home or our office in Leeds

Qualifications

• Great Ruby on Rails coding skills
• A track record of implementing live RoR sites
• Experience of test driven development using RSpec
• Experience of deploying Rails using tools such as Capistrano
• Experience of project management desirable
• Proactive developer able to work independently as well as part of the team
• Suited to working in an agile, flexible environment
• Good written and verbal communication skills
• Living within 2 hours of the UTC time zone

We’ve got shirts in a range of sizes – standard unisex Ts from small to XXL, and women’s shirts in Medium & Large.

If you’re a Brightbox customer and want to add one of these super-stylish charcoal garments to your wardrobe, send me an email (louisa @ brightbox.co.uk) telling me your details and what size you would like, and I’ll get one in the post to you as soon as possible.