Autojump: Faster than ‘cd’

Here’s a cool tool: autojump, written by Joel Schaerer (thanks, Joel). I spend much of my day as a programmer navigating around in the linux filesystem. Built-in tools like ‘pushd’ and ‘popd’ are nice, as are subprocesses — e.g.

 (cd ~/Download && wget http://somewhere.com/path/to/file)
… and when it finishes downloading, I’m still in the directory I was in before the download was started.

Now there’s autojump to add in to the mix. After I ‘cd’ to various directories, later, I can type ‘j Down’ to cd to my Downloads directory. Very convenient. I just wish it were built into every distribution of linux.

Linux tty auditing

Since RHEL 5.4, and in recent Fedora releases, it’s possible to audit what users type at their tty (command prompt), thanks to the work of Steve Grubb, a RedHat employee.

Edit /etc/pam.d/system-auth and append the following, but not both:

session required pam_tty_audit.so disable=* enable=root
session required pam_tty_audit.so enable=*
Wait for users to log in and type into a terminal. Later, to see audited tty input, run:
aureport --tty
When a user logs in, the pam module tells the kernel to enable tty auditing for a process and its children. All tty input is logged, but it may not be incredibly easy to read (it includes backspaces, control characters, etc.). I’m unclear as to when and how often the kernel flushes out accumulated tty input to the audit log. The records are identified with a type of TTY in /var/log/audit/audit.log.

In addition to tty auditing, RedHat patched their bash shell so that it neatly audits each and every command line it executes, with a record type of USER_TTY. It’s prettier to read than raw tty auditing — and it’s easy for a user to bypass by using a shell that doesn’t send its commands to the Linux audit system, like zsh, or a custom-built unpatched bash. Maybe that’s why “aureport –tty” doesn’t show USER_TTY records.


The Linux auditing system is powerful. It’s possible to write rules that watch for modification to certain files, or that log the use of certain system calls. See the “audit.rules” manpage for more information.

Easy updates with iOS and Linux vs bomardment from Windows

When I want to check email on my iPod Touch, I simply unlock it, load the email application, and read messages. What a joy. The tool works and works for me. It is my servant, instead of me being its servant.

Compare that to my corporate Windows Laptop. I open the lid and unlock it, wait for corporate anti-virus (I think) to chew through the I/O on my machine for several minutes. Then I can read my email using the unimpressive and slow Lotus Notes (I’d rather be using Thunderbird, Outlook, or speedy mutt).

Or compare to my home Windows Laptop. I open the lid, log in, and am bombarded with requests from several programs to install updates. I just want to check my email, not be attacked with annoying “update me!” windows. I see one from Thunderbird, another from Adobe Flash, another from Mozy and another from Firefox. By the time I’ve upgraded, sometimes I’ve forgotten what I wanted to accomplish in the first place.

Apple has it right with updates for the iPod Touch: They stay out of my way until I want to bother with them, and then they’re all manged together.

Linux has it right: A single package manager updates everything, in one shot, including from third parties.

I’ll continue to use Windows. There are other benefits, even though third-party updates are annoying.

The dog ate my grub.conf; unwanted LVM indirection

In September, I updated packages on my Fedora 14 machine using ‘yum’ (Yellowdog Updater Modified), and rebooted. I was greeted with an unfriendly grub prompt. Boot was broken, and I didn’t know why.

Normally when I want to rescue a Linux system, I use the Fedora install DVD’s rescue mode. Unfortunately, my DVD drive stopped working just after the warranty expired. So I booted using a Linux-on-a-USB image that I carry around with me.

I planned on replicating the rescue mode experience by manually mounting the partitions in /mnt/sysimage, then chroot, and then run ‘grub-install’ to fix things. And that’s what I did, except for a few snags.

The first snag is that I had installed Fedora with default partitioning options (something I rarely do), and it had helpfully used LVM to configure my disk drive. LVM adds a layer of indirection, so I had to figure out how to mount an LVM volume instead of a disk partition. As a general rule, I never use LVM on desktop or laptop machines because I don’t like the additional complexity, especially when I’m trying to mount a drive to recover data.

The next snag is that Linux uses UUIDs for hard disks these days, instead of helpful, human-readable labels. In the good old days, Linux distributions would label the root partition, the home partition, and others. But not when I let the installer work its default magic. So, I had to figure out which volume contained my root partition, my boot partition, and so forth.

Once I mounted my partitions properly, I was ready to “chroot /mnt/sysimage”, and after I did, I ran “grub-install”. No luck. This was the third snag.

I realized that /boot/grub/grub.conf was empty. And grub-install doesn’t fix the problem — it can’t populate information that is completely missing, like knowing what disk UUID to use for the root partition.

“No problem,” I thought, “I’ll just restore from backup…”. Except, I didn’t have a backup. As a general rule, I back up /var, /home and /etc, but not /boot. Now I know better.

Surely, I thought, there should be a copy of grub.conf that the package updates had left around. But there wasn’t.

Such a critical file, and there was no automated backup. No “restore point”. No way to recreate it from data in /etc. What an oversight!

This is the first time I can remember having had an update eat my grub.conf file, and I’ve been running Linux since before distributions switched to grub as a boot loader. On the other hand, maybe I jumped to to an incorrect conclusion — it’s possible that the updates didn’t eat my grub.conf. Regardless, grub.conf was empty and my system wouldn’t boot.

It seems to me that something this important should have been designed with more resilence.

There were two ways to fix it, as far as I could see. One is upgrade from Fedora 14 to Fedora 14 (thus preserving my data). The second is to recreate grub.conf by hand, and for that, I needed an example — a template. I used the one at http://forums.fedoraforum.org/showthread.php?t=227358. My boot up screen isn’t as pretty as it once was, but it is functional.

Lastly, I made copy of /boot/grub/grub.conf. Now where did I put it?…

Gnome 3: Not quite ready for prime time

Just over a week ago, I installed Fedora 15. After using Gnome 3 for two days, I decided that I’m better off using Gnome 2, KDE or XFCE.

With Gnome 3, I like the ability to type the name of the application I want to run instead of hunting for it in a menu. This is a feature I’ve enjoyed for the past five years with Windows Vista, so it’s refreshing to finally have it appear in Gnome.

With Gnome 3, however, I miss the following:

  1. A system monitor applet. When my system starts to feel slow, I pay attention to CPU and I/O wait overhead.
  2. Multi-monitor support when changing workspaces. When I move to a new workspace, Gnome 3 only moves one of my two screens to a new workspace. The other stays the same.
  3. Quick launch icons. I use them for Firefox, gVim, Eclipse, and other frequently used apps.
I expect that Gnome 3 will be improved rapidly, and Fedora 16′s Gnome 3 will more productive.

Update: There’s a list of ways to tweak Gnome shell to make it almost bearable: http://forums.fedoraforum.org/showthread.php?t=263006. In particular, by installing and using “gnome-tweak-tool”.

Misc Linux things: PATA or SATA, mutt and mailcap, tarsnap backup

The other day, I wondered whether the drive in my laptop was PATA or SATA. Fortunately, I didn’t have to tear it apart to find out. I simply wandered over to stackexchange.com and asked the question. Here’s the answer:

lspci -d $(cat /sys/block/sda/device/../../../vendor):$(cat /sys/block/sda/device/../../../device)
readlink -f /sys/block/sda/device/../../../driver
I’m a long time user of the mutt email client (as well as Thunderbird). At some point, viewing the HTML attachment (with the ‘v’ key) stopped invoking ‘lynx’ via my mailcap file. It turns out that the developers of mutt added an internal viewer, and moved mailcap support to the “m” key. I took the time to switch from using ‘lynx’ to using ‘links’. Here’s the entry from my $HOME/.mailcap file:
text/html; /usr/bin/links -dump -force-html %s; copiousoutput; nametemplate=%s.html
I’ve been gradually looking for an online, off-site Linux backup tool for  the past few years. I tried spideroak, but wasn’t pleased with the giant log files it kept in my home directory, and it wasn’t designed to back up files outside of my user account. Lately, I stumbled on another promising tool: tarsnap. I haven’t tried it yet, but I will. Pricing looks reasonable, and since it “deduplicates” storage, it means that I shouldn’t be backing up the same thing repeatedly. Here’s how one person configures tarsnap to keep up to X daily backups, Y weekly, and Z monthly.

Fedora 14, SSH ports and SELinux

SELinux in Fedora 14 is configured to constrain the ports on which SSH can listen (see the bug report). The solution:

setsebool -P sshdforwardports 1
This allows SSH to listen on ports besides 22, and to forward ports. Reading the bug report is interesting. In my opinion, OpenSSH has an outstanding security track record, and we probably don’t need additional SELinux policy to constrain it. It’s probably wise to practice security in-depth (to have more than one line of defense), but it creates a large road bump for most SSH power users. From what I read, it sounds like most people still disable SELinux.

Teriffic Linux Books

One of my QA coworkers had The Linux Phrasebook sitting on his desk. I noticed it was by Scott Granneman, and immediately thought, “if it’s by him, it’s got to be good.” As I thumbed through the pages of the book, I was impressed at the practical coverage of command line utilities including yum and rpm, apt and deb, etc. I highly recommend this book. It’s small so it’s easy to keep on hand.

For anyone wishing to write applications that take advantage of all that Linux has to offer, I recommend The Linux Programming Interface (also available from Amazon), aka TLPI. I used to recommend Stevens’ Advanced Programming in the UNIX Environment, but now I recommend TLPI because it is more comprehensive and just as readable. It’s not a small book, so a PDF makes it easier to keep on hand. I purchased my copy through the publisher, NoStarch with the coupon code “Mamaku” that gave me 30% off and a free PDF. The order total came to $80.00, including shipping.

Awesome Linux profiling tools: top -H and pstack

When I needed to figure out where the performance bottlenecks were in some Linux software, I found helpful answers at http://stackoverflow.com in the form of two tools: 1. naming threads in combination with “top -Hp <pid>” and 2. “pstack <pid>”. The first was helpful in watching which threads were consuming the most CPU. The second was useful in sampling the application over time to find the hot spots and their stack traces.

  • How to name a thread in Linux (or a process) — use prctl().
  • How to use stack sampling to find performance problems — use pstack.