Sometimes one needs to make a PDF with fancy features (e.g. color gradients) available for online viewing. In Firefox, a click on the link to the PDF will open it in PDF.js, which will warn you if it has features it can’t quite deal with. PDF.js will still try to render it. That can lead to visual artefacts and/or be very slow, neither of which are desirable and can be confusing for users.

There is a way to disable PDF.js server-side, and force Firefox to open a download popup box when user clicks on a PDF:

AddType application/octet-stream .pdf

Unfortunately, that makes Chrome (on Windows only, for some reason) really unhappy: it will open a blank new tab and not download the PDF file.

So, here’s how you tell Apache 2.2 to only change the Content-type header for PDF files when the User Agent says ‘Firefox’:

  <IfModule mod_setenvif.c>
    BrowserMatchNoCase firefox pdf=stream
  </IfModule>

  <IfModule mod_rewrite.c>
    RewriteCond %{ENV:pdf} stream
    RewriteRule .pdf$ - [T=application/octet-stream]
  </IfModule>

The BrowserMatchNoCase sets an environment variable called ‘pdf’ to the value ‘stream’ (which is an arbitrary choice). That environment variable is checked by the RewriteCond line; if it matches ‘stream’, the RewriteRule on the next line changes the Content-type header.

This can be done in a less convoluted way on Apache 2.4 with the <If> directive.

* October 2004 – purchase Shuttle home server with 2x 200GB disk (200GB useable)
* May 2007 – upgrade to 2x 500GB disk (500GB useable)
* September 2009 – upgrade to MSI Wind with 2x 1TB disk (1TB useable)
* June 2012 – upgrade to 2x 2TB disk (2TB useable)

Looks like my upgrades are roughly 2.5 years apart. Interesting!

I bought one Hitachi HDS723020BLA642 (that’s model ’0f12115′, a 2TB SATA3 drive with 64MB of cache). Well, actually I ordered model ’0S02861′ which is SATA2 and only has 32MB of cache, but for some reason Amazon shipped me the faster one. Ah, well, I’m not complaining. The other drive is a Western Digital WD20EARX (that’s also 2TB SATA3 drive with 64MB of cache).

It’s worth noting that the two 1TB drives that are being replaced (WD10EADS-00L) have been rock solid over the past 2.75 years, despite a *lot* of data being written to them (nightly backups of more and more servers, which is also why I was running out of space…).

So now I have two SATA3 drives in a system that is SATA2 only. That’s too bad. On the other hand, this machine now has 10x the amount of disk space that its first incarnation had, back in 2004. Nice!

To celebrate, get 50% off all e-books at oreilly.com – today only! Use the code DRMFREE.

I found a migration script at norwinter.com, which I improved a bit. It will handle wiki pages with full history as well as attachments. It won’t preserve who committed revisions, however – that is hardcoded in the script. So, this is still a hack.

Usage instructions:

a) copy your MoinMoinWiki data/pages directory to the server that runs your redmine install
b) put the migrate_from_moinmoin.rake script in lib/tasks/ in your Redmine install
c) edit the migrate_from_moinmoin.rake script, replace both instances of YOUR@EMAIL.ADDRESS
d) run rake redmine:migrate_from_moinmoin RAILS_ENV=”production”
e) provide a unique redmine project id and the path to your MoinMoinWiki data/pages directory

And here is my version of migrate_from_moinmoin.rake.

This script worked well enough for me to import MoinMoinWiki version 1.5.7 to Redmine 1.2.0.

The machine booted into Grub’s rescue mode. Grub 2′s rescue mode is nice, but not exactly intuitive (no ‘help’ or ‘?’ command), and documentation for it is apparently not easily found via Google.

This is what was eluding me for a while:

In rescue mode, only the insmod, ls, set, and unset commands are
normally available. If you end up in rescue mode and do
not know what to do, then see "GRUB only offers a rescue shell."

That’s from the Grub manual at gnu.org.

The steps involved in recovery are documented in the same manual. Basically you need to set the prefix and root variables, and then insmod the ‘normal’ module and run it.

The packaging was not too great; while all disks were well packaged individually, the big boxes that contained the individual drive boxes were flimsy. As a consequence, one of the disks got rather damaged (the one on the right):

I don’t know what it got hit with, but it must have been a pretty serious blow. The aluminium enclosure of the drive is severely dented and even cracked; the white line in the image below is an actual crack in the metal:

Back in October 2009 I added 130 TB of disk to another cluster, which looked like this, prior to install:

That was 65 times WD2002FYPS.

So this time around – almost 18 months later – we get 27% more capacity using 15% fewer drives. Got to love the computer industry and the progress it makes.

The ‘Average CPU Power’ is based on ‘average’ use, which is explained on Wikipedia.

According to Wikipedia, the Thermal Design Power is the maximum power consumption for thermally significant periods running worst-case non-synthetic workloads (cf. this article). If we assume that the bulk of the electrical power consumed by a CPU is converted into waste heat, then the TDP can be a reasonable approximation for the amount of electrical power a CPU would consume under a worst-case, real-world load.

I used cpuburn to generate such a load. There was no IO load on the system during the tests. I measured power draw with an off-the-shelf Kill-a-watt, so these results should be taken with a grain of salt.

The data indicates that the idle vs. full load power consumption difference for one CPU is 70 to 75W.

If we assume the power consumption under full load is 115W (the TDP for the processor), then idle power consumption would be 40 to 45W per CPU. That would put idle power consumption at 35-39% of its TDP for this particular CPU.

In order to do the same thing under Rails 3, I had to make a few adjustments. First of all, you need the rails3_acts_as_paranoid gem, which is a total rewrite of acts_as_paranoid for rails 3. Add these lines to your Gemfile:

gem 'rails3_acts_as_paranoid'
gem 'acts_as_versioned'

Then put a file in config/initializers with these contents:

module ActiveRecord
  module Acts
    module Versioned
      def acts_as_paranoid_versioned(options = {})
        acts_as_paranoid
        acts_as_versioned options

        # Override the destroy method. We want deleted records to end up in the versioned table,
        # not in the non-versioned table.
        self.class_eval do
          def destroy()
            with_transaction_returning_status do
              run_callbacks :destroy do
                # call the acts_as_paranoid delete function
                self.class.delete_all(:id => self.id)

                # get the 'deleted' object
                tmp = self.class.unscoped.find(id)

                # run it through the equivalent of acts_as_versioned's
                # save_version(). We used to call that function but it is a
                # noop when @saving_version is not set. That only gets done in
                # a protected function set_new_version(). Easier to just
                # replicate the meat of the save_version() function here.
                rev = tmp.class.versioned_class.new
                clone_versioned_model(tmp, rev)
                rev.send("#{tmp.class.version_column}=", send(tmp.class.version_column))
                rev.send("#{tmp.class.versioned_foreign_key}=", id)
                rev.save

                # and finally really destroy the original
                self.class.delete_all!(:id => self.id)
              end
            end
          end
        end

        # protect the versioned model
        self.versioned_class.class_eval do
          def self.delete_all(conditions = nil); return; end
        end
      end
    end
  end
end

I wonder if there is a more elegant way to achieve this…

Note: code updated at 2011-05-28 to make sure :dependent => :destroy on has_many associations does the right thing.

-rw-r--r-- 1 root  root  1.1G 2010-10-31 20:19 10125-127-2010-10.error

After:

-rw-r--r-- 1 root  root   11M 2010-10-31 20:19 10125-127-2010-10.error.bz2

Bzip2 reduced the file to 1% of its original size. Not bad!