Skip navigation

Many of these articles, as well as new articles, have move to

Following up on my article on single booting Solaris on a MacBook Pro, what follows are almost identical instructions for single booting Ubuntu 10.04 Lucid Lynx on a MacBook Pro. There are two key differences with this procedure:

  1. A Master Boot Record (MBR) partition table is not necessary to boot Ubuntu.
  2. The hard drive must be blessed after installation.


  1. MacOS X Install DVD (any version, OEM or full)
  2. Ubuntu 10.04 Install CD (server or desktop)


  • Using a MacOS X Install DVD format the disk with a single partition. (Phase I)
  • Boot from the Ubuntu 10.04 Install CD and install Ubuntu. (Phase I)
  • Boot from the MacOS X Installation DVD once more and bless the hard drive. (Phase II)

Read More »

I’ve encountered this error several times while running daemons (or detached processes) in Mac OS X – most recently within a Python scripted called from our continuous integration daemon:

gaierror: [Errno 2] Temporary failure in name resolution

Initially I thought I was facing a glibc bug. However, according to Python’s Build Bot system, I’m not the first person to run encounter this error. Luckily there is hope. The fix: Run your process as group daemon.

Here’s an example launchd plist for a Mac OS X Bamboo Agent running as group daemon:
Read More »

The following steps describe how to get Solaris 10 (or any other Intel based OS, including FreeBSD (tested), Linux (tested) and Windows) installed as the primary (single boot) OS on a MacBook Pro. After fighting with the non-trival method of installing Mac OS X and setting up Boot Camp, it turns out you can simply format the disk with a Master Boot Record (MBR) instead of the default EFI. Please read through this entire procedure before you attempt this method.


  • Using a MacOS X Install DVD format the disk with a single partition MBR.
  • Boot from the Solaris 10 Install DVD and install Solaris.
  • Download and install Marvell Yukon Ethernet drivers using a USB stick.

Read More »

My associate Comm-Lead (aka and I performed a FRS radio check on our way home from downtown. We used store bought 12 (14?) channel Motorola talk-about FRS radios. We took two different routes from work to home, here’s a map:

View FRS Test Route in a larger map

The map is somewhat self explanatory, but here’s some notes. We had very good coverage until Curi hit Duboce and Market. At that point I could pick her up if I turned the squelch all the way down. For the remainder of the trip I could tell there was a background signal but I could not make her out out until she reached the hill on 17th  and Clayton at which point I was at Masonic and Fell and received an excellent signal.

It seems from our test that in a flat part of the city, the expected range of FRS is about 4-6 blocks.

The idea to consume tcptrace with Splunk came to me after seeing Darren Hoch‘s OSCON 2009 presentation Linux System and Network Performance Monitoring. In his talk Darren shows how he diagnosed home networking issues using tcptrace. Here’s his description of tcptrace:

The tcptrace utility provides detailed TCP based information about specific
connections. The utility uses libpcap based files to perform an analysis of
specific TCP sessions. The utility provides information that is sometimes difficult
to catch in a TCP stream. This information includes:
• TCP Retransmissions – the amount of packets that needed to
be sent again and the total data size
• TCP Window Sizes – identify slow connections with small
window sizes
• Total throughput of the connection
• Connection duration

The data coming out of tcptrace looks like this:

TCP connection 1:
        host a:
        host b:
        complete conn: no       (SYNs: 0)  (FINs: 0)
        first packet:  Wed Jul 22 19:58:34.489567 2009
        last packet:   Wed Jul 22 19:58:35.164233 2009
        elapsed time:  0:00:00.674666
        total packets: 395
        filename:      testdump1000
   a->b:                              b->a:
     total packets:           147           total packets:           248
     ack pkts sent:           147           ack pkts sent:           248

Complex? Yes. Edible by Splunk? Hell yes.

Read More »

Awe! Memories! My first ‘sploit:

Date: 1/23/97
System: MacOS
Application: TrueBasic

A error has been found on any system running MacOS and any
version of TrueBasic that includes the “unsave” command. The unsave
command is used to erase or delete any file on the Macintosh HD. What this
allows any user to do is erase ANY file even if behind security programs
such as “On Guard” and “At Ease”.


! Begin Kiss Off v1.0 by Xservo <>
!       NOTE: Replace "MacHD" with the name of your Macintosh Hard Disk
unsave "MacHD:System Folder:Control Panels:On Guard"

This program will erase On Guard from the Macintosh Hard Drive named
“MacHD”. Such a exploit can also be acccomplished with the “OPEN” and
“ERASE” commands.


Xservo <> {*}
Powered by RHS Linux 4.1 {*} PGP Key on request (and do use!)

The total cost for this project is less than $50. The parts you’ll need are:

  1. 1x Musicians Gear Standard Speaker Stand @ $29.99
  2. Radio Shack 5-foot Antenna Mast @ $14

To assemble:

  1. Remove the inner steel tube from the speaker stand and flip it over so that the open end is facing up and the capped end is facing down.
  2. Orient the antenna mast so that the narrower section is facing up and the wider section is facing down.
  3. Push the antenna mast into the open end of the steel tube until you feel the mast hit the end cap on the steel tube
  4. Place the joined mast and tube, cap end first, into the speaker stand.

Done. You’ve now got a portable collapsable emergency antenna tripod.

Here are some steps I took to detect the MTU of some of our off-site DSL users.

The MTU for Ethernet is 1500. This is a typical setting for office LANs where there’s no traffic traversing links of smaller size. However, traffic that must cross non-ethernet links, such as DSL, will encounter MTUs of different sizes. When a network device receives a packet larger than its MTU two things can happen:

  1. If the packet has the ‘do not fragment’ flag set the device will drop the packet and reply back to the packet originator with an error message.
  2. If the packet does not have the ‘do not fragment’ flag set the device will break the packet down into identical-but-smaller sterilized packets that fit within the MTU requirements of that link.

Here’s how you can test to see what the MTU is between your computer and a remote computer.

  • In this example I’m going to use my Mac at home to test the MTU to
  • I’m going to use the ‘ping’ command with the ‘-D’ (do not fragment) and ‘-s’ (packet size) flags.

Normally when I ping I see:

playpig(~)$ ping -c 1
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=47 time=256.573 ms
--- ping statistics ---
 1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 256.573/256.573/256.573/0.000 ms

Now I’ll ping with a packet size of 1492bytes:

playpig(~)$ ping -c 1 -D -s 1500
PING ( 1500 data bytes
ping: sendto: Message too long
--- ping statistics ---
 1 packets transmitted, 0 packets received, 100% packet loss

Next I’ll ping with a smaller packet size:

playpig(~)$ ping -c 1 -D -s 1300
PING ( 1300 data bytes
1308 bytes from icmp_seq=0 ttl=47 time=172.396 ms
--- ping statistics ---
 1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 172.396/172.396/172.396/0.000 ms

From our testing so far we can safely assume that our MTU is less than 1500bytes and more than 1300bytes. We can continue testing until we find a happy medium. Lets try 1329bytes:

playpig(~)$ ping -c 1 -D -s 1329
PING ( 1329 data bytes
ping: sendto: Message too long
--- ping statistics ---
 1 packets transmitted, 0 packets received, 100% packet loss

Lets try 1328bytes:

playpig(~)$ ping -c 1 -D -s 1328
PING ( 1328 data bytes
1336 bytes from icmp_seq=0 ttl=48 time=288.600 ms
--- ping statistics --
 1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 288.600/288.600/288.600/0.000 ms

Bingo. Our MTU is going to be a number less than 1336bytes that is a multiple of 8:

  • NO 1336 / 8 = 167
  • NO 1334 / 8 = 166.75
  • YES 1332 / 8 = 166.5

The MTU between us and is 1332bytes.

Here’s some more information on fragmentation:

“Internetworking with TCP/IP”
Pg 81 – 6.7.6 Fragmentation Control

Hi, My name is Greg and I work in IT.

I was born and raised in Fayetteville Georgia. I hope you’ll believe me when I tell you that Fayetteville in the 1980’s was no cultural Damascus. At the time, if you had asked me to conceptualize a rice-cooker I would’ve probably imagined a guy in a chef’s hat running around a kitchen screaming ‘bork bork bork!’ Alas, times have changed, and I’ve moved on…

Read More »