ftw!
Home Blog Archives RSS
November 14, 2005
¶ BSO SRI
The summer between my junior and senior years in high school, I attended the Brandeis Summer Odyssey SRI program. I forgot what SRI stands for, but it was basically a geek camp of 13 high school students. We signed up to be some professor's research bitch for eight weeks and agreed to love it. I asked to be placed with a computer scientist and ended up in the lab of a cognitive scientist / psychologist. The research sucked, and I vowed to never enter the field of cognitive science, but the camp was a blast.

Since then, I've learned that three of us have entered a graduate program at MIT. Makes me wonder what the other 10 are up to now.

I suppose a deeper question might be - how much did the high school program affect our career choices five years later when deciding between graduate school and industry? Did the program nurture our scientific curiousity, or were we there because we already knew (subconsciously) where we were going? ehh.... whatever.
November 24, 2005
¶ beating airport security (sort of)
situation: When I'm sending stacy off at the airport, it would be nice to extend the time we have together as much as possible. Saying goodbye at the security checkpoint just doesn't seem right, and it would be fantastic if I could wait at the gate with her until the boarding call when she actually gets on the plane.

note 1: Many airlines, such as JetBlue and Alaska Airlines, now offer the option to check-in online from home. This option is enabled 24 hours before the scheduled departure time, and lets travelers print their boarding passes from home.

note 2: Traditionally, there are three points in the air-travel process where ID and a boarding pass are required: the ticket counter for checkin, the security checkpoint, and the departure gate when boarding. Most departure gates only require the boarding pass, and do not check IDs.

solution: Restrict all travel to airlines that offer online checkin. Call the traveler Alice, and the companion (non-traveler) Bob. Bob wants to accompany Alice all the way to the departure gate but would normally be turned away at the security checkpoint. Instead, Alice checks in online shortly before her scheduled departure. Alice then makes a digital copy of her boarding pass and modifies it (using Photoshop or Gimp or whatever) so that it has Bob's name on the pass instead of her own. She then prints out both the original and the modified boarding passes. Bob now has what appears to be a valid boarding pass and can make it through the security checkpoint since the security officers only perform a cursory visual inspection to see that the name on the boarding pass matches the name on the presented ID. Bob can then accompany Alice through the checkpoint to the departure gate. Since they checked in online, they don't need to present their IDs to a ticketing agent. Also, since Bob does not try to board the plane, he doesn't need the boarding pass any longer.

notes: This is almost certainly illegal. This is a mental exercise only, and I don't actually recommend trying it.

corollary: With the use of a fake ID, it's possible to fly under a completely bogus name. Furthermore, it's possible to fly without a record of ever having traveled using that fake ID. Say you have a fake ID for the name Charlie. Purchase a plane ticket for the name David, and do the online checkin. Doctor the boarding pass so that it has the name Charlie and pass through security using the fake ID and the modified boarding pass. Destroy the modified boarding pass. Security checkpoints do not record the IDs used, so there will be no record of having passed through security using that pass. Travel with the unmodified boarding pass that has the name David on it. I'm not sure why you'd actually want to do this, but it's fun to think about...
November 25, 2005
¶ User-friendly failover mechanism via removable media
I've recently realized that USB memory keys make great switches.

Take the example of a small organization that has a primary file server with multiple backup servers. The backup servers periodically retrieve updates from the primary file server and have the exact same configuration as the primary with the exception of ip address and hostname. If the primary server fails (e.g. due to a hard disk malfunction), then one of the backup servers needs to be promoted to replace the primary. Let's restrict ourselves to situations where this failover doesn't need to be immediate, and a few minutes of downtime is acceptable.

To do this with a USB memory key, configure each server so that it periodically checks for the existence of a special file /media/usbdisk/PRIMARY-SERVER. If the file is detected, then the server promotes itself to act as the primary server and reconfigures its network settings appropriately. Otherwise, the server demotes itself to a backup server that retrieves updates from the primary. The important thing to note here is that for many Linux distributions (e.g. Debian, Ubuntu), /media/usbdisk is the mount point for USB memory devices - when a USB memory device is inserted into the computer, its contents immediately show up at /media/usbdisk. Now, all you need to do is purchase a cheapo memory key from the local computer store and create an empty file on it called PRIMARY-SERVER, and you have an instant switch that lets you choose which machine to promote to the primary server.

So why does this matter? Probably the best feature about a scheme like this is that the failover process can be completed in a matter of seconds by even the most technically incompetent person. It's simple and intuitive. If you're using your software that relies on the file server and you notice that the file server isn't responding, you just walk over to the server room and move the "switch" to another machine.

The reason I care is that I help run the computing infrastructure for a small organization. They have a handful of technically unsavvy employees and require a file and database server. I'm happy to setup and configure the servers for them at my leisure, but I can't be on-call if a server fails and they need it replaced immediately. Now, when a server does fail, they simply move the switch and disconnect the failed machine. Since computers are cheap now, they can get triple redundancy with a simple failover mechanism for less than $1,000. When a server needs to be replaced, they send it my way, and I set it up when I have time. Then I just send it back and they plug it in.

Since the failover is so simple, it would actually be good practice to periodically switch primary servers just to ensure that the backups are still working. One of the biggest problems faced in server failures is that the backups don't work when they're most needed, precisely because they're not regularly tested. In a system like this, I would rotate the primary server switch every week or so, just to make sure that all systems are functional.
• Powered by bBlog