The optimist in me would like to point out that my aforementioned stupidity regarding my toasting of Serenity has an upside: in the process of rebuilding my network and moving services around, I was able to rename all of the machines to conform to my new naming convention: famous Canadians.

So here's the list:

• Dallaire (gateway and firewall) - Roméo Dallaire is a Canadian senator, humanitarian, author and retired general best known for his work as Peacekeeper in Rwanda during the genocide.
• Trudeau (web, dns, imaps and fileserver) - Pierre Elliott Trudeau brought us our Constitution, our Charter of Rights and Freedoms, was a champion of national Unity and had a pair of big brass ones when it came to doing what he knew was right, opposition be damned. He is my favourite Prime Minister.
• Douglas (laptop) - Tommy Douglas was the founder of Canada's nationalised health care system as well as the NDP. Champion for a range of socialist causes, he was depicted as a rebel in the CBC's Greatest Canadian series, I felt it appropriate that he get the laptop :-)
• May (desktop) - Elizabeth May is a long time environmental activist and the present leader of the Green Party of Canada and the primary reason that I'm a supporter. She is all kinds of awesome.
• Geist (my ps3) - Michael Geist is the Canada Research Chair in Internet and E-Commerce Law at the University of Ottawa. He's a Canada's #1 copyright reform advocate, and I couldn't resist the irony of attaching his name to a Sony product.

Now here's the thing. The last two people are not nearly as strong as the first three. I mean, don't get me wrong, May and Geist are awesome people, but I feel as though the both of them haven't really done enough to be compared to the other three. I'd like to hear a list of suggestions for different names, hopefully related to their function if possible.

There are also 3 more computers on their way (low-watt replacements for Trudeau) so while one of them will still bear the Trudeau name (the webserver), there are essentially 4 machines up for naming rights:

• A domain server / DHCP server
• A fileserver
• My desktop (gaming, movies & development)
• My PS3

So here's where you come in: I want a list of names to use for the above. Tell me why your Canadian is a good choice: Riel, Pearson, McClung, whomever you like, but tell me why. I'd also like to have some women in the mix if possible -- it just feels kinda weird to have all my machines be male :-)

You may have noticed some sketchy uptime on this blog lately. For a few days there, my site would be online for a few hours, then drop offline for a few then return. It's done horrible things to my traffic as well as my personal productivity.

You see, my router, Serenity was falling apart. The little compact-flash card I was using was starting to flake out and I was seeing data corruption, segfaults and lots and lots of kernel panics. Not fun. This could be managed with the occasional reboot, but that's not a fix. No I had to buy a new cf card and rebuild serenity from the ground up.

This sounds more difficult than it is really. I just hopped down to London Drugs, bought a new card ($23 for 2gb! Looks like SD really did win that race) brought it home and opened up the box with my trusty screw driver, moved a few parts around and replaced the card. The only thing left was the install and configuratioin... except I got stupid.

The case fan was unplugged. I'd removed it months ago 'cause it was making noise and I wanted a quieter house. However, the CPU was *really* hot, so I thought it might be a good idea to test out if the noise was really tolerable or not. I took the little power wire and plugged it into a free set of pins and sure enough, the fan came on -- the server also rebooted.

I'd plugged one of the power cables right into the motherboard on some unlabeled pin. There was some scary-sounding beeping, and then the smell of burnt metal and plastic... even smoke. My curiosity, coupled with a stupid mistake (learn your cables Dan!) had had quite literally "toasted" my router.

So I'm now using my wireless router (originally just an access point) as my primary router and I'm already not liking it. I'd gotten used to handy things like IP blocking, and routing non-standard ports to standard ports to get around lame security on other networks -- all of it gone. However getting a replacement for serenity is looking to be around $400 so that's not going to happen anytime soon.

So let this be a lesson to you kids: be careful when playing with expensive hardware... one mistake and you really could fry your board :-(

It happens, especially in recessions and when it does, there's often little or no warning. You come into work on a Friday, work through the day, and at the end of the day, as you're heading out of the office, the boss comes to you and says something to the effect of: "Sorry, but you're done here."

Not long after you manage to get over your panic attack, your boss drops another bomb: you're not allowed to access your computer again. All of your personal email and/or files that you have on there are going to be backed up into hard drive somewhere and gods know what the sysadmin is going to do with it.

Now one might argue that if you're putting personal stuff on a company computer, the company owns that stuff, and legally speaking, you might be right, but morally, it's your stuff that you access at work because work takes up the vast majority of your day. It only seems fair that if they're going to give you the boot with zero notice that you have a chance to keep your emails and IM conversations with friends and family private.

So, in case you've ever wondered what might be a good way to keep your data more-or-less safe in such situations, I thought that I would post a little how-to here.

Option One

Don't put personal information on your company computer. It will save you all kinds of hassles, even if it does make life at work considerably less bearable.

Option Two

If you're going to put personal information on your company computer anyway, the best way to secure it is to have your computer continuously check a remote source (under your control) for instructions. You can then leave the instructions blank until Something Bad happens. For example, on a Linux machine:

1. Create a tiny script file (call it "remoterun" for the sake of this example) and put this in it:

         #!/usr/bin/env sh
         curl -s http://somesite.com/instructions.txt | sh

   Now make it executable.
2. Log into the server hosting somesite.com and place a file called instructions.txt in the document root. It can contain anything you want to execute on your machine. I recommend the deletion on your home directory (so long as there's no company data in there) and the removal of your personal account from the box. If you choose though, you can be a little more zealous and delete your music files, any background wallpapers you if you want. Just don't delete anything belonging to the company or they will be well within their rights to come and kick your ass in all kinds of unpleasant ways. Here's an example of a simple instructions file:

         # Delete my music
         rm -rf /opt/share/music
   
         # Delete my account
         userdel --force --remove daniel
   
         # Delete the remoterun script
         rm -f /path/to/remoterun

   This part is very important: Do not put anything in this file that you do not wish to run immediately. The above would nuke your personal data, so only put destructive instructions in the file when you actually want to delete stuff. Until then, you can just leave it blank.
3. Now that you have an instructions file, you just need to make sure that your office computer runs the remoterun script every hour or so. That way, the machine will run your instructions within an hour of you setting them up on somesite.com. In Linux, you can do this with cron:

   # crontab -e

   That will allow you to edit the crontab for the current user (be root, it's best for this kind of thing). Now you just add the crontab line:

   00 * * * * /path/to/remoterun

That's all there is to it. Every hour, your office machine will connect to somesite.com and execute whatever instructions.txt says. Windows users, I'm afraid you're on your own but the theory is the same.

Now remember kids, use your powers for Good, not Evil. I've provided the above so you can be a responsible person while protecting your private life from someone who shouldn't have access to it anyway. I hope that you will do the same.

I know that I'm in Korea and I "should" be out seeing the sites, but I have to explain that the primary reason for my visit here was less to see Seoul and more to see Shawna and just... relax. Since Shawna works during the day, I took the morning and after noon off to just do nothing yesterday and today I'm catching up on my crazy-sized email backlog. I'll be going out around 11am though with a friend of Shawna's to do some exploring and pick up a temporary phone.

For the moment though, I just wrote a rather long email to my uncle to help him with his Google ranking and figured that since this was the second time I've had to go through all of this with someone, that it might be a good idea to post it all here for future reference. If you think that I've missed anything, please let me know and I'll update.

Google bases your page rank on a few things: linkage, content, and formatting. I believe that it's even in that order. I'll explain one at a time.

Linkage

The number of links to your site and the ranking of the origin sites. So for example if "Bob's blog" links to you, that link is worth significantly less than if it were from Amazon.com or Slate etc. More links is better, and Google will even attribute the content of the origin site to your own. In other words, if a site about Pizza links to you, Google will assume that you have something to do with Pizza. So the best links to get are things *within your field* rather than from anywhere lest you run the risk of diluting your rank with non-relevant rankings.

Content

This is the easiest, but a lot of people miss it. First of all, so-called "rich media" isn't recognised by Google (and pretty much all other search engines too). Flash, Youtube, Silverlight etc. won't get read by Google so don't make your site dependent on such formats. Instead, lots of relevant content with links to other sites and proper use of keywords with which you want to be found.

For example, on my dad's site, he wanted to be found with the keyword "optical" but we never once used it on his site. Instead, we used "optician". As a result, he was #1 for "optician Kelowna" but had no mention for "optical".

It's also important to note that grammar is important. You can't just fill up the page with abnormal uses of keywords you for which want to be indexed. Google pays very smart people a lot of money to write code that will recognise poor-grammar-as-planted-keywords so don't mess with a good thing. The truth of it is that if you have a good site with relevant content, people will find you, link to you and your rank will improve over time.

Format

Back when I was in school we were taught that the format of your code was relevant to your search ranking. I'm not sure of how true this is anymore but it's a good practise nonetheless. Do put headers in header tags (<h1>..<h6>), put text in the alt="" portion of your <img> tags and don't try to screw with them by putting a bunch of keywords in a text block and then hide it by making the text the same colour as the background or by hiding the box altogether. They hate that and their scripts catch you, you risk being delisted.

Lastly, a handy thing to do is to install Google Analytics. It will do fun stuff like track page hits by hour, week, and month as well as give you country of origin stats, search engine references etc. It's awesome and it's free (as in beer, not Freedom).

I inherited an old iBook from a coworker a vew weeks back and finally got around to trying to install Linux on it. In my many trials however I discovered how to reset the passwords on an existing OSX install (10.3+) and I thought that I should log it here for my own records:

1. Hold command-S when booting
2. /sbin/fsck -y
3. /sbin/mount -uw /
4. /usr/libexec/register_mach_bootstrap_servers /etc/mach_init.d
5. cd /var/db/netinfo; netinfod -s local
6. /sbin/SystemStarter

I'll append to this post as I work my way further through the mac-cruft ;-)

DEFAULT CATCH

One fun problem I ran into immediately following the boot was that just hitting "enter" at the boot: prompt resulted in a DEFAULT CATCH! code=300 error. Attempting to manually launch the 3 available kernels all failed as well, the first two (labeled G5) dumped the aforementioned error, and the last one (labeled ppc32) just made the screen go blank. So I did what any good geek would do: I trolled the intarwebs for that error message.

Unfortunately most of the information you find on that error pertains to a very old mac problem regarding the size of hard drive partitions and a whole bunch more suggested I upgrade the firmware to make it work. However to do that I'd need to install OS9 (the iBook was running 10.3) just to run the update. That, my friends is Apple "support" :-(

Well downloading a torrent of os9 just to install it for a 20min firmware upgrade seemed a bit crazy, even for me, so I went back to the attempted Gentoo install and lo-and-behold, I had a brainwave: the ppc32 kernel was working, but the video signal (being pushed over a proprietary Apple dongle to my old monitor) was freaking out at the default drivers being used. The following command worked:

boot: ppc32 video=ofonly

And then it was 3am. I shall continue this post later :-)

One of the reasons I switched to Arch Linux was that I didn't want to have to compile all of my packages anymore. However, in leaving Gentoo for the Arch world, I also gave up a certain amount of ease of customisability (is that even a word?). Gentoo does, after all, excel in letting you do whatever you want to your machine and there are some circumstances where that's pretty important... even for users like myself.

Such a situation presented itself when I realised that the KDE binaries shipped with Arch do not include debugging support. This is obviously in place to improve performance, but for a bleeding-edge product like KDE, this also makes it very difficult to offer a good bug report. Thankfully, Arch's build system (abs) allows you to compile any program you want and install it with the package manager with little trouble... so I did just that.

Below is a quick script I wrote to rebuild all of my KDE binaries with debugging enabled. It's commented so you know what's going on:

  #!/usr/bin/env bash

  # Create a workspace if it isn't already there
  mkdir -p $HOME/abs

  # Fetch a list of kde packages from pacman
  PACKAGES=$(pacman -Qs kde | grep -v '^ ' | sed -e 's/ .*//' | sed -e 's/local\///' | grep '^kde')

  # Loop through the package list
  for PACKAGE in $PACKAGES; do

    echo $PACKAGE

    # Copy the package to your workspace
    cp -r /var/abs/extra/$PACKAGE $HOME/abs/
    cd $HOME/abs/$PACKAGE

    # Edit the PKGBUILD file to use debugging
    sed -i -e 's/DCMAKE_BUILD_TYPE=Release/DCMAKE_BUILD_TYPE=RelWithDebInfo/' PKGBUILD;
    echo "PATCHED"

    # Make the package
    makepkg -s

  done

Once you've built all of those (it'll take a long time... KDE is huge), you can install each one with pacman:

  # pacman -U PACKAGENAME-VERSION-i686.pkg.tar.gz

It's also a good idea to recompile qt as well. For that, you just add -debug to the configure list in its PKGBUILD file.

For more information, please visit the Arch Linux wiki page on ABS.

For the longest time, I've been fighting with this problem:

$ ssh someserver.ca
Received disconnect from 123.123.123.123: 2: Too many authentication failures for username

It never asked for my password, it just flat-out failed. After some digging, I realised that the force behind this was my use of ssh-agent, a daemon that holds onto the myriad of keys (and their respective passwords) that I use to access all of my servers. It turns out that by default ssh-agent attempts to use every key you've got to access a server. However, because the destination server usually rejects login attempts > 6, the whole thing blows up before it ever gets to the "enter your password" step.

The solution is this handy one-liner in your ssh client config (~/.ssh/config or /etc/ssh/ssh_config):

  Host *
    IdentitiesOnly yes

Contrary to what you might think this means, IdentitiesOnly doesn't force the use of identities, rather it tells the client to only use identities explicitly defined for this host. This way my client uses identities assigned to a host via the config, and if one isn't set, it isn't used.

Why this isn't the default is beyond me.

I think that it's been more than 12 hours. More like 14... it's all a blur really.

I started today with a lofty goal: do a complete system wipe of Moulinrouge, my file/web/mail server that hosts pretty much all of my life... including this site. I decided to take the last step in my abandonment of Gentoo Linux in favour of my new love, Arch Linux, the process of which only added to the difficulty. I also moved my DNS and DHCP servers to Serenity my firewall machine as I'd gotten tired of the various exceptions I had to make to host those services with Moulinrouge.

Strictly speaking though, the whole thing went rather well. I had rsync'd my entire filesystem over to the 1TB USB2 drive, and the Arch install ran with no problems at all. The biggest hiccup came when I realised that Exim isn't packaged with MySQL support in Arch, so I had to do a manual compile for that one using ABS. A pretty cool experience I might add, though frustrating when you condiser how common such a setup may be. For those interested, I followed a helpful forum post on what needed to be changed and created a simple patch file for PKGBUILD so I can use it again later:

# pacman -S abs
# abs
$ mkdir -p $HOME/abs
$ cp -r /var/abs/extra/exim $HOME/abs/
$ patch $HOME/abs/exim/PKGBUILD PKGBUILD.patch
$ cd $HOME/abs/exim
$ makepkg
$ pacman -S exim-4.68-5-i686.pkg.tar.gz

The other fun bit I discovered was SSH's ability to not only run its own version of secure-ftp (sftp), but also run it in a chroot environment with ChrootDirectory. This required a lot of experimentation so I thought that I'd post a few notes here:

• In a chroot environment, logging is not possible until OpenSSH 5.2. Don't try, it'll only cause you pain.
• You cannot chroot a user into her or his home directory as the "new root" must be owned by the root user. Instead, what i found worked well was setting up a series of user directories owned by root under /srv/http/untrusted/username which then had the user's websites inside.

Here's my sshd_config snippet:

Subsystem  sftp  internal-sftp

Match Group untrusted
  X11Forwarding no
  AllowTcpForwarding no
  # Won't work 'till 5.2
  #ForceCommand internal-sftp -l VERBOSE
  ForceCommand internal-sftp
  ChrootDirectory /srv/http/untrusted/%u

Lastly, PHP in Arch is very different from my experiences in Gentoo, Unbuntu, Debian, Suse and Redhat. Even FreeBSD was more intuitive. For starters, Arch uses some less-than-common defaults in php.ini:

• error_reporting = E_ALL
• magic_quotes_gpc = Off
• short_open_tag = Off

Then, when you try to start up Apache, you find that it's not loading PHP. To make that happen, you have to add the following to httpd.conf and reload your webserver:

LoadModule php5_module modules/libphp5.so
Include conf/extra/php5_module.conf

After all that though, you'll notice that MySQL and a suite of other extensions you're used to seeing as part of PHP aren't there. If you stopped by this site earlier for example, you would have seen the glaring errors complaining that mysql_connect() didn't exist. To make all of that work, you have to go back into php.ini, scroll down to the bottom and un-comment the various extension lines... among them:

extension=mysqli.so

There were other fun problems, but this post is already quite long and it's almost 5am now. Must get some sleep so I can finish it all up tomorrow!

In a recent rash of system re-installs, I've learnt the hard way what not to do. I'm keeping this list here for my own future reference in the hopes that I might save myself future headaches.

Before doing any wipe and re-install, the following should always be done:

• Export bookmarks
• Export kwallet
• Export contacts
• Commit all subversion sandboxes
• Backup /home/*
• Backup /usr/local
• Backup /etc
• Backup subversion repositories
• Dump databases

On a personal note, I apologise for my lack of blogging lately. I have a lot about which I want to post and I've been having trouble finding the time. I shall endevour to do better.

I'm struck suddenly by the number of things to which I've committed myself in my "off" hours:

1. My Municipal Collective idea
2. Stephen's girlfriend's site (just HTML layout etc.)
3. Wordpress fix for Stephen's Civics Education Network site
4. Mapping project for the VPSN
5. A complete rewrite of this site (it's been 2years)
6. A ticket selling project with my brother

Aside from #1, all of the above are technical in nature and require a serious amount of attention. Looks like I had better put a dent in these this weekend.