The Love Shack

So I’ve been fighting with my iPhone for months. Ever since the 2.0 update, I have been dealing with lots of annoying issues trying to get the sync to work properly. The most notable were my phantom calendars. iTunes couldn’t see any of my iCal calendars, but it *did* see about 20 calendars that hadn’t existed in a month. This made my calendar altogether worthless on the iPhone. Add to this the 20-minute backup/sync operations, and I was getting properly fed up.

I tried a number of times to restore my iPhone from backup, but those problems just came back with the restore. And Apple has been thoroughly useless with this issue. So after a bit of digging, I found a solution. My calendars now work, my backup/sync takes about 30 seconds, and everything is great. Note that I have no idea what the possible ramifications of this operation are, but It Worked For Me ™. These directions are assuming you’re on OSX. I’m sure that it’s similar on Windows, but I don’t know where the appropriate folders are stored.

If you have TimeMachine set up, I’d strongly suggest doing a backup before you start. If you don’t have TimeMachine, get an external drive, set up TimeMachine, do a backup, and then start.

1. Do a “Restore” in iTunes to wipe out your iPhone. After the wipe is done *do not* restore a backup just yet.
2. Shut down iTunes.
3. Open Finder, go to your home folder, then Library -> Application Support -> SyncServices.
4. Delete (or move) the Local folder.
5. Start iTunes, and restore your iPhone from the most recent backup.

One the restore is complete you should have all of your contacts, etc back. In my case, I was doing this to fix the calendars, so I had to go back to the Info tab and tell it to sync my calendars again.

After you do the initial sync to copy all of your music back (which can take a really long time), every subsequent sync should be about 30 seconds or less. At least they are for me. YMMV.

It’s as though the Mozilla guys knew that Google was cooking up Chrome and wanted to make sure that Chrome didn’t steal all their glory. So about a week ago, they gave us Ubiquity. If you need to know why Ubiquity is cool, I’ll let their page do the talking. But, if you already think it’s cool, and have it installed, you should visit RubyURL.

I took a quick break from working on Boxcar stuff today and, after a bit of hacking and a RubyURL API update (generously provided by Robby), we now have a working Ubiquity command for RubyURL. How easy is it to use? Well, take a look:

If I’m not careful this blog is going to turn into an OSX tips and trick blog before too long.

So, you have more than one Mac machine, you lucky [son|daughter]-of-a-gun! And you’ve got MacPorts installed on both since you’re a complete geek. But you’re getting tired of installing (or, more specifically, compiling) the packages on each of the machines. Especially if you have an older powerpc-based machine, this can be really time consuming. (A recent build of gnome-terminal and all dependencies on a PowerBook took 6 days!)

So, what’s a [guy|girl] to do? Well, you share your packages of course! But… how? Well, after spending hours today beating my head against the keyboard trying to figure it out, I’ve finally got a solution. Now, I know you’ll all be shocked by this, but the documentation for MacPorts sucks! Thankfully, there are some very helpful folks in their IRC channel.

So, now that I have suffered, you don’t have to. I took the time to write up a howto on the MacPorts wiki. So without further ado, I present:

Sharing MacPorts archives between multiple computers

Enjoy and don’t hurt your brain like I had to.

I’ve spent quite a bit of time struggling with getting Synergy to work to my satisfaction in OSX. (Leopard, 10.5.3 to be exact)

Problem number 1. Running as a daemon doesn’t work. It crashes after a few seconds and OSX prompts you to report the error to Apple. So you have to run it as a foreground process using the -f flag. The problem with this is that you have to keep a terminal handy. So I decided to run it in a screen session so that I could keep it running when I’m not around. Unfortunately, if you start it in a screen session (or via ssh for that matter), the clipboard sharing stops working. I don’t know why, but it does. (If you do know why, please comment and let me know!)

So after quite a bit of struggling, and trying a dozen different solutions, I finally found one that works. Start it in the foreground in the background. That is, start synergys or synergyc with the -f switch, but then put an & (ampersand) after the command to automatically background the task. At this point, you can close the terminal and leave synergy running in the “background”. Of course, YMMV. While this has been working fine for me, if you’ve got a better solution, I’m all ears.

For those who can’t make heads or tails of the preceding paragraph and just want the damned thing to work, start synergyc using:
synergyc -f your.computer.name &
and start synergys using:
synergys -f &
That should get you up and running with full clipboard support.

Note that in my case I was connecting two OSX desktops together. Different combinations of OS’s may yield different results, but I get the feeling that regardless of what OS the other computer is running you’ll still have the same problem on the local OSX machine.

Tim Dysinger put up a great article the other day about simplifying Rails app deployment. He briefly goes over some of the SSH configuration options that you can use to simplify things, particularly when using ssh-agent. There are a few other things that I use to greatly simplify my life, particularly since I use ssh for almost all of my work, not just deployments.

1. Automatically load up ssh-agent and prepare your keys on login.

   OSX and most Linux desktop environments (Gnome, KDE, etc) have a “keyring” that stores system passwords and things for you in a relatively secure fashion. You unlock the keyring with a master password and you get access to stored passwords. ssh-agent can interact with these keyrings to automatically load up your ssh keys at login. You just unlock the keyring once, and your keys are all ready to go.

2. Use short names in your .ssh/config

   Sometimes you’ll be stuck working on servers with extremely long names. Or, worse yet, servers with no DNS name at all where you have to remember the IP address. In this case, you can use a host/hostname combination in your .ssh/config file to give you an easy to type name.

   host = shortname
   hostname = reallylong.nameplusdomain.com

   And, for bonus points, if your current login name doesn’t match the remote login name, you can add a user = remotename line. Now, instead of typing:
   ssh remotename@reallylong.nameplusdomain.com
   I can just do:
   ssh shortname

3. This last one is a potential security risk, but it can be handy when you’re deploying to a machine who’s host key changes regularly. I run into this all the time when preparing new release candidates of our Rails Boxcar images at work. I add stricthostkeychecking = no to my config. If I connect to the same server multiple times and it has a different host key (or no host key stored locally yet) I won’t have to manually approve it. Particularly handy in conjunction with Capistrano since cap will usually choke and exit with an error instead of prompting you with the “Add host key” message.

So I don’t really care for CentOS. It’s a project the builds binary packages from the source provided by Red Hat as part of RHEL (That would be Red Hat Enterprise Linux) and then gives them out for free. Great concept. But it’s distributing Red Hat, and the Red Hat folks don’t even like them. That’s like being the unwanted bastard son of a leper.

But, I strongly support their freedom to distribute those packages if they so please. Now, thanks to the oft-criticized but well-worded GPL, Red Hat is obligated to release the source for any modifications to open-source software that they create. This is what allows a project like CentOS to exist. But it turns out that the folks at Red Hat are not happy about someone else making no money off of the money that they made off the people who made no money. So they were kind enough to send their legal attack-dogs after these folks.

But, as GrokLaw has taught us, the snarling and slobbering of legal attack-dogs makes for great entertainment. Among the choice morsels contained within the letter, we have this gem:

Moreover, our client does not allow others to provide links to our client’s web site without permission. Your use of the RED HAT marks while linking to redhat.com suggests that Red Hat somehow sponsors or endorses your company which is false and misleading.

Now, you may have noticed that in a very uncharacteristic move, I’ve linked to every instance of the words Red Hat and RHEL within this article, sometimes gratuitously. This is because I consider this statement, and Red Hat’s position on this matter to be an affront to free speech.

It may not be legal for someone to claim to represent Red Hat. However, if they have something to say about Red Hat, whether that something is positive or negative, they have the right to say it and they have the right to make clear who it is that they’re talking about by providing a relevant reference, such as a link.

So, to you, Red Hat, I say fsck you! Seriously… you seem to have some errant bits floating around spewing out garbage which is tarnishing an otherwise pristine corporate whore reputation filesystem. How do you expect to get clients for your trade if you’ve got these creepy little critters crawling around your nether-regions? So, please, do us all a favor and get yourself checked out before straddling any more servers. Mmm-kay? Great.

For the record, I have no connection to Red Hat. I do not work for Red Hat, I am not supported by Red Hat, and I have never purchased a Red Hat product in my life. Nor do I intend to, at any point in the future, seek or accept employment with Red Hat nor purchase any Red Hat products, including, but not limited to, RHEL (Red Hat Enterprise Linux).

If I hear one more person pronounce the word “daemon” as “damon”, I’m gonna go crazy. Well, maybe not. Probably too late for that already.

But, either way, it’s quite annoying. I really don’t understand why people are so uncomfortable with saying the word “demon” when talking about computers. They look at “daemon” and think, oh that can’t possibly be the same word as “demon” because that’s bad, so I’ll just pretend it’s something different. Well, sorry, it’s not.

Or, perhaps, they’re thrown off by that letter “a” in there. Now, the fact that the proper historical spelling is dæmon (note the letter æ) should be a slight hint. The “ae” in “daemon” is a digraph meant to represent “æ” since most computer keyboards don’t have a convenient way of typing the letter. So what other words use that letter?

How about: cæsar, æthereal, encyclopædia and hæmoglobin? There are certainly quite a few more, but I don’t feel like turning this into a book. So, let’s look at these words:

Cæsar (Caesar or Cesar)
You wouldn’t order a cAser salad, would you?

Æthereal (aethereal or ethereal)
This one should be particularly noticeable for IT folks. I don’t typically use Athereal to sniff network traffic.

Encyclopædia (encyclopaedia or encyclopedia)
If you look on the side of that big thick book on your shelf, you’ll notice that it is written “Encyclopædia Britannica”. Yet most of us know how to pronounce that word. And, while you’re at it, look up daemon in there.

Hæmoglobin (haemoglobin or hemoglobin)
This is one of those great examples of a word that has been simplified in American English to more accurately reflect the pronunciation. The “a” was removed entirely to simplify the word. Much like removing the “a” from “daemon” to give us “demon” in American English. Imagine that…

So, as of today, I have accepted an offer to work for The Man. Not The Man as in, “The Man is keeping us down”, but as in “You are The Man!”. Except, in this case, it’s more like The Company. Starting soon (hopefully Friday, if everything is ready to go) I’ll be working for Planet Argon. I’m being brought in as a sysadmin for their hosting operations. There are lots of really exciting opportunities going on here not only in the world of Ruby on Rails hosting in particular, but hosting services in general.

Companies like DreamHost have really redefined what one-click installations are all about, but I’m looking to take that further. Not just one-click hosting, but one-click virtual servers. Imagine filling out a form, submitting some billing info, and having a full-blown, ready to go virtual server available for your use (with root access to boot) within a few minutes.

With technologies like Xen allowing lightweight virtual machines, I’m hoping that we’ll soon be able to make this a reality. No more being confined to your $HOME, and trying to install software that isn’t supported by the hosting service within those confines. You’ll now be able to install software as it was MEANT to be installed, and just have it work.

With more and more Web 2.0 (is that cliché yet?) applications coming up, and with more and more developers designing said applications, it’ll be even more important to have an easy and reliable platform for hosting these applications. It’s obviously going to take some hard work and time to get it done, but I think it’ll really be a very positive step for the industry as a whole. Stay tuned for more about this.

Obviously, these are just my opinions and not the policy of Planet Argon, yadda, yadda. Same goes for any future work-related posts. But it’s a very exciting opportunity, and a very exciting time to be getting involved into this portion of the business.

Ok, so I’ve been encoding my DVD’s for viewing on my mythtv box and I’ve gotten tired of always tying up my desktop while I do so. So I set up a little headless box in the closet (encoder) to just encode away while I’m doing other stuff on my main machine (thief). But, now the problem. I want to use ogmrip to do the rips, and I want to use the GUI.

So with a bit of digging, I found an ideal solution (that takes a little bit of work to set up). I use xvfb to provide a local X server that’s very lightweight, and then I run xmove inside it. I then start ogmrip connected to the xmove virtual server, and move it to my desktop to start it running. Once it’s started, I move it back to the xvfb server and get on with my work.

So the setup that I had to do to get this to work was as follows:

1. Configure my local X server (on thief) to accept TCP connections. In my case, this involved editing my ‘gdm.conf’ and setting DisallowTCP=false

2. Install xvfb and xmove on the remote server (encoder). apt-get install xmove xvfb

3. Start up xvfb. Using xvfb-run wasn’t working right for me, so I did it manually from the command line. Since I want to be able to refer to the output later I run it inside a screen session. So I do screen -S xvfb Xvfb :0 -screen 0 1024x768x24 The -S option to screen just gives it an easy name to use later when reconnecting. Note that using a bit depth greater than 24, while shown in the man page for xvfb as being valid, caused the startup to fail each time.

4. Once xvfb is running, I detach from the screen, and then do export DISPLAY=:0 Now we just need to create an .Xauthority file and start up xmove. So I do xauth generate encoder:0 . trusted followed by screen -S xmove xmove and then, once again, detaching from the screen once it’s started up ok.

5. Now it’s just a matter of updating DISPLAY one more time export DISPLAY=:1 (since :1 is the display that xmove uses by default) and starting up an application. Just for testing, I start up xterm and see nothing. (Which is ok, because it means it’s running in the xvfb server.)

6. Then it’s just a matter of doing xmovectrl -moveall thief:0 If this fails with an error you probably need to allow remote connections on the remote machine. So, in my example, I would open a terminal on thief and do xhost +encoder

If you’d like to have your applications open by default on your local machine, you can just pass the -server option to xmove. So, in the above example, instead of doing screen -S xmove xmove I’d do screen -S xmove xmove -server thief:0

And that’s it. With this setup I currently have ogmrip running on encoder and encoding a DVD, while I’m typing this on thief. Later, when I want to check the status of the rip I can connect to encoder, do another xmovectrl and off I go. Cool stuff!

I just threw together a little script I call rdiffdir to allow me to make rdiff deltas of entire directories easily. All it really does is create a tar archive of the directory and use rdiff on it. But it’s easy to use (well, for me at least ), quick, and it gets the job done. For those wondering why I don’t just use rdiff-backup or, rsync, it’s because I don’t want to keep both copies of the directory. rdiffdir allows me a per-directory “snapshot” that takes only as much space as my changes. With a 3 GB directory, with 100K worth of changes, you begin to see how much space it can save. More importantly, it also reverts renames and other changes that a simple file-by-file comparison wouldn’t do. So just by moving or renaming a directory I won’t suddenly triple the size of my dleta.

You can grab it from the Software link above, or if you’re just too lazy, here’s a direct link for version 0.5. If anyone finds it useful, or if you have any questions, comments, etc, feel free to leave a comment here to contact me via the About page.