roguelazer's website

My iPhone 3G experience started this morning at about 5:50 AM, when I left my dorm to get an iPhone 3G. I hiked over to the Montclair Transcenter and picked up the 6:30 OmniTrans Route 66 bus heading Eastward. At about 7:05, I stepped off the bus, thinking I was there. Unfortunately, I was at another bus stop in front of a Best Buy with a gas station next to it — about a mile and a half shy of the Victoria Gardens Mall, where the Apple and AT&T stores were. A half-hour of hiking later, and I was there.

I passed by the AT&T store, which had about 20 people in line in front of it. However, I have a terrible history with AT&T customer service, so I figured I'd go to the Apple store. I was #45 in line at the Victoria Gardens Apple Store, next to a nice guy named Matt who was reading Aldous Huxley's "Brave New World". It was 7:43 A.M. now, and the Apple store was set to open at 9:00.

At about 8:25, an Apple store employee came out to ask us if we had any questions. Now, some background. I am on a Family Talk plan, with my Mum as the primary. I called AT&T last week to see what I would have to do to get an iPhone, and they instructed me to have my mother add me as an "Authorized User" on our account, then it would be smooth sailing. I did this. Now, I tend to be an unsure fellow, so I asked the Apple store employee whether I had done the right thing. I had, apparently, not. According to this employee, Apple would not activate any phones purchased without the account primary present. Seeing as how my mum is about 3000 miles away right now, that's not really feasible. I got a bit huffed, as you might imagine. He said that I should try the AT&T store, although he wasn't sure whether they actually had any iPhones in stock.

So, frustrated, I headed over to the AT&T store, where the line had grown to about 45 people. I begrudgingly stepped to the back of the line, where I chatted with a nice woman named Angel who, apparently, works Customer Service at a casino. After a couple of minutes, the store manager came out to see if anybody had any questions. I flagged him down and explained my situation. After a moment's thought, he told me that it'd be no problem, and I could purchase my iPhone. Score one for AT&T.

At almost exactly 9:00, the AT&T store opened up its doors and started taking people four at a time (there were only four non-managerial employees, from what I could see). I was a bit worried that they wouldn't have any in stock when I got there, but the friendly manager assured me that they would. As I crept up the line (enjoying complimentary ice water, score another for AT&T), the manager kept taking head counts and assuring us that he still had iPhones in stock.

Finally, I reached the front of the line. Lo, they still had iPhones in stock! Admittedly, they were out of 16G models, but that's okay with me. A four minute transaction later, and I had my new iPhone 3G. Contrary to popular opinion, AT&T did an excellent job of customer service, and Apple sucked royally.

Next up: Activation

I've just purchased an iPhone 3G. I'll now make a few posts about my ordering experience.

Relying on the numbers of my friend Martin Pyne, the 2008 Democratic Primary is over and Barack Obama is the winner. Woo!

So, I got bored this weekend and installed Firefox 3 (beta 5, if it matters to you). It works pretty well — it's certainly faster than Firefox 2. However, there are a couple of annoying bugs that I'd like to post the solutions to for posterity:

If you use a dark theme (like I do), then many textarea and input form elements will be unusable because they will have a dark foreground color and a light background color. The solution to this is to add a userContent.css to ~/.mozilla/firefox/ /chrome. There are lots of guides on the Internet for this file, so I won't go into it. However, the difference from Firefox 2 is that now any sections that you want to actually be interpreted for reskinning "native" controls (like form input boxes) need to have a -moz-appearance: none !important; rule. There should, however, not be any @namespace directive.

The other annoying thing is that the Awesomebar thinks links should be green. Don't get me wrong, I like the awesomebar, and I like links, and I like the color green. But green really doesn't work with my theme. So I reskinned them, using the userChrome.css file in the same directory as userContent.css. Copying the example will get you the @namespace directive, which is important in this file. Then, the following lines will get you some nice blue-ish links (this color looks good on a dark background):

.ac-url-text {
    color : #8888cc !important;
}

You can thank grep for the relevant style class. Anyhow, I'd be interested to hear any of your opinions on Firefox 3. Otherwise, have a nice week-end.

I've mentioned sudo in these tips before. It's a neat little utility for executing commands as somebody else. Well, today I bring you a handy guide I found on using sudo. I already knew most of the stuff, but some of it was new, and it looks pretty good as a starter for new users. So enjoy this article on sudo basics by A.P. Lawrence.

Sorry readers, no *nix Tip of the Day today. Just a brief word about the recent Debian OpenSSL vulnerability.

I'm sure you've heard about Debian's OpenSSL "Disaster". The short of it is that while fixing a questionable line in the OpenSSL/OpenSSH key generator, the Debian maintainer accidentally removed most of its entropy generation ability. Debian users with OpenSSL and/or OpenSSH keys should go regenerate them now. I'll wait.

Anyhow, the other interesting thing I wanted to post about was this. It's some interesting math showing why you shouldn't be using DSA keys anyway.

Oh yeah, and I'm done with classes and finals now. :-)

tee is a handy little utility that probably all of you know about, but I just found this year. Consider the following scenario: you're maintaining your Gentoo Linux system and you need to add a line to /etc/portage/package.unmask. So you type

sudo echo "sys-kernel/gentoo-sources" >> /etc/portage/package.unmask

right? Nope! The way shell parsing works, that turns into

(sudo echo "sys-kernel/gentoo-sources") >> /etc/portage/package.unmask

which is most certainly not what you want, since you probably don't have permissions to /etc/portage/package.unmask. The solution is the tee utility. It would be invoked like the following:

echo "sys-kernel/gentoo-sources" | sudo tee -a /etc/portage/package.unmask

Well, this was a short post. Oh well. :-)

An important part of a *nix system is a good terminal emulator. For some, this means the classic xterm. The same xterm that's happy to use 7 MiB of resident memory for each instance. Or perhaps you run a full DE like Gnome and are happy to use gnome-terminal and enjoy 19 MiB of resident. Personally, I use rxvt-unicode (urxvt). It's a very lightweight version of rxvt which has neato features like full Unicode support and a daemon mode that lets you pool multiple instances. For example, my urxvtd processs is using 41 MiB of resident, but hosting 9 urxvtc clients (a little over 4 MiB per client). It's several sorts of awesome.

Now, another important part of the terminal emulator infrastructure is the terminfo library (successor to termcap). This library contains terminfo definitions for pretty much every terminal emulator out there and allows the shell to make intelligent decisions about things like fonts, colors, and sizes. Unfortunately, I said "pretty much every terminal emulator" for a reason. rxvt-unicode is not one of the terminal emulators that is part of the standard library. Thus, my prompt, which normally looks like [11:06] <roguelazer@CaveOfBirds> ~ % ends up looking like 33mCaveOfBirds> ~ % when I log into a server that I've never logged into before.

So, what's the resolution to this problem? It took me a while to find out, but the key is the tic utility (which stands for terminfo compiler). Terminfo descriptions are distributed as a (almost) human-readable source format. urxvt's can be found here. Once you've acquired a source file, simply run tic on it. If you run tic as a normal user, the compiled terminfo description will be installed to ~/.terminfo; if run as root, it will be installed system-wide in /usr/share/terminfo.

As usual, come back later for some new and exciting tips.

Continuing on my theme of SSH tips, today's Tip of the Day talks about the awesomeness of SOCKS proxying. As some of the more savvy among you may know, OpenSSH supports full Layer-2/Layer-3 VPN functionality using a tun device. This is an incredibly useful feature if you're off-site and need like-local access to home, work, school, or somesuch. But it requires root access, and is more than a little bit of a pita to set up. If all you need is access to things like the web, e-mail, and instant messaging, there's an easier way.

SOCKS is a transparent proxy protocol. Basically, you just tell your applications (like Mozilla Firefox or Pidgin) to connect to a SOCKS server, and all of your traffic is automatically redirected. If you're on the wrong side of a restrictive firewall, or not in the right intranet, and you have access to a SOCKS server, that's great. But most of us normal humans don't get access to a "real" SOCKS server.

And that's where yet another awesome OpenSSH feature comes in. OpenSSH has a single-flag SOCKS server built right in. Say your school computer is called, erm, remote, and you have a user there who is creatively named user. Now say you're off-campus and really want to look at the on-campus-only student roster. You could screw around with TCP forwarding over SSH, or perhaps try to run links on your school machine. Or you could just type ssh -D65500 user@remote (note: the "65500" part is not important. Any number between 49152 and 65535 can be used with no problem). This creates a SOCKS proxy that goes through remote, but listens on port 65500 on your local machine. So now you open up Firefox's Preferences, go over to Advanced->Network->Connection->Settings, and put in a SOCKS Host of "127.0.0.1" port "65500". It doesn't matter whether you select v4 or v5 for this purpose, since OpenSSH supports both.

Congratulations, you're now talking to the internet through a transparent proxy. When you're done, just restore Firefox's old settings and quit SSH.

Check back later for new and exciting things to do in the *nix Tip of the Day series!

Today's *nix tip of the day involves SSH and the magic that is Agent Forwarding.

SSH, as some of you know, is a handy way to connect to *nix systems in an untrusted environment. Its primary use is to allow one to remotely access a remote system and get a shell, securely. Basically, encrypted telnet. Of course, SSH has tons of other useful features (like tunneling, proxying, and multiplexing), some of which might come up in future Tips of the Day.

One of SSH's greatest features is its public/private key system. Basically, using private keys, you can allow much more secure access to a remote machine. If you trust your local machine, you can even allow passwordless access to remote machines if you have an unencrypted private key. Of course, this is a bad idea if you think people might be able to compromise your local private key, which is why SSH private keys can also be encrypted with a symmetric cipher (basically, a password). Using this gives you all of the in-transit security and power of private keys, but all of the local security of password authentication (something you have + something you know sort of deal). They're covered a great deal more in a retroactively-posted tip of the day — read back a bit.

This is all well and good, but there are times when typing your SSH key's passphrase is annoying. For example, the Z Shell allows for tab-completion of remote filenames over ssh (when using scp, for example). It is an awesomely useful feature that makes remote filesystems feel local without any of the muss of sshfs. However, if you have an encrypted private key (or password authentication), typing your password every <TAB> can be a pain. Hence, ssh-agent.

ssh-agent is a program that you will generally run as a wrapper around your session (this is done automagically on linux if you're running gdm). If you want to test this stuff, you can just run exec ssh-agent $SHELL from a terminal and then execute all of the commands from this tip in that shell. Now, let's say that you've put your private key in the standard ~/.ssh/id_rsa, and it's encrypted. At your newly-ssh-agent'ed shell, type in ssh-add ~/.ssh/id_rsa and type in your private key's encryption passphrase when prompted. Congrats — you can now ssh from this shell to any machine containing your public key without any password at all. Isn't that awesome? Try it out. I'll wait.

...

Now, this is well and good. But let's say that you just ssh'd to example.com using your super-duper ssh-agent, and you want to ssh from there to your other server at example.net. Do you need to copy your private key onto example.net and then type the passphrase there? That might be a bit risky, especially if you don't really trust the admins of example.com. I mean, the key is encrypted, so you're probably okay, but what if they're running a keylogger? Well, as long as you're using OpenSSH (which you most likely are), you're fine, thanks to the magic of agent forwarding. Log out of example.com, and then run ssh -A username@example.com. Note the -A. This turns on agent forwarding, and means that your login at example.com temporarily has the same access permissions as your local machine. So you can happily ssh user@example.net and get the happy password-free access without anything else. You can even agent-forward from example.com to example.net and build up a chain of secure authentication credential forwarding all the way back to your local machine. It's awesome.

Well, that's my tip for the day. Check back again in the future for more exciting things that other people have said and done before.