The Fugue

xmltv is cool. Slow, but cool. Here's how I got the complete olympic lineup so I don't have to deal with the shoddy nbcolympics.com site:

# sign up for zap2it's data direct service, per the instructions in the
# tv_grab_na_dd man page. Then configure tv_grab_na_dd
tv_grab_na_dd --configure

# grab through the 30th
tv_grab_na_dd --days 17  > dd.xml

# do the magic incantation to get the guide
cat dd.xml | tv_sort | tv_extractinfo_en | tv_sort | tv_grep --on-after now > guide.xml

# now grep out the olympics
tv_grep -i 'olympic' guide.xml | tv_to_latex > oly.tex

# produce the pdf
latex oly.tex
dvipdf oly.dvi

Do it while you're eating breakfast or reading slashdot or something, it takes a lot of CPU and RAM, but it is something you can do in the morning before work, for example.

I made 1-up, 2-up, and 4-up versions. They are 12, 6, and 3 pages, respectively. Choose per your ocular prescription and paper conservation preference.

Ok, I guess I shouldn't say "complete", since apparently the listings are only through the 25th at this stage. I'll blog the last few days in plenty of time to plan your VCR/TiVo/attendance.

I had the hardest time convincing things to route properly from my home network to my work network, over the VPN (racoon<->netscreen25).

Here's what my routing table used to look like:

166.70.37.148/30 dev eth1  proto kernel  scope link  src 166.70.37.150 
172.17.0.0/24 dev eth0  proto kernel  scope link  src 172.17.0.3 
default via 166.70.37.149 dev eth1 
default via 172.17.0.3 dev eth0  scope link

So even though ping 172.16.59.143 would go over the VPN, it would have a source of 166.70.37.150. This was unacceptable, and was messing things up although it kind of half-worked. The following fixed it:

# ip route add 172.16.0.0/12 via 166.70.37.149 dev eth1 src 172.17.0.3
# ip route get 172.16.59.143
172.16.59.143 via 166.70.37.149 dev eth1  src 172.17.0.3 
    cache  mtu 1500 advmss 1460 metric10 64

I'm a big fan of the Terminus font, and an even bigger fan of Vim. Recent versions of Vim Debian packages are built with GTK2 instead of GTK1. GTK2 apps use TrueType fonts and in general make fonts in X even more complicated than they already were. I must have my terminus while in gvim, and it just wasn't there by default. Here's the trick:

$ dpkg-reconfigure fontconfig  # answer yes to "Use Bitmapped fonts by default"

I'm using GNOME at work, and got sick of the "user friendly" window non-manager Metacity, so I started investigating other options. Despite much smoke and mirrors to the contrary you really can use other window managers in GNOME these days (this is 2.4). Sawmill is nice in theory but I have an aversion to lisp syntax (although I love the language theoretically).

FVWM is one of my favorite WMs from the configurability standpoint. Its weakness is as a desktop. I don't require much from a desktop: quicklaunch, dock (panel is OK, slit is best), and do it without taking a lot of space. FVWM can almost cover the first two with some work, but it flat out fails on the last point. But I digress. The point is that I decided to use FVWM as my window manager in GNOME and I am loving it.

One of the great things about FVWM is that it groks all the keystrokes and modifiers. So I can use that windows key for window manager functions and leave Alt alone, so applications that use Alt will actually work. My Happy Hacking keyboard has cute little diamond keys that are supposed to be Meta keys. They output the Super_[LR] keycodes. Alas, for whatever reason, mod4 wasn't getting bound to them, as you can see here:

fugalh@gwythaint:~$ xmodmap
xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock      
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x6d)
mod1        Alt_L (0x40),  Alt_R (0x71)
mod2        Num_Lock (0x4d)
mod3      
mod4    
mod5

This is the secret:

fugalh@gwythaint:~$ cat > ~/.xmodmaprc
add mod4 = Super_L Super_R
fugalh@gwythaint:~$ xmodmap ~/.xmodmaprc

Throw that last command in your ~/.xsession to complete the trick. Now things like the following work in your ~/.fvwm/.fvwm2rc:

# do the alt-drag and alt-resize thing
Mouse 1 FSTW 4 Move
Mouse 3 FSTW 4 Resize

Update

I think I was wrong, the problem was probably GNOME in the end. Not only does GNOME annoyingly complain about my having an ~/.xmodmaprc, but it apparently does its own xmodmap based on the keyboard settings, which wipes out my custom xmodmap. So the solution is to set the keyboard to Generic 104-key PC in Keyboard Preferences.

On FVWM and GNOME

You probably want the following basics in your .fvwm2rc for GNOME 2.4: Style "gnome-panel" NoTitle, !Borders, NeverFocus # this emulates the default FVWM root menu. Notice the D context (see fvwm(1)) Mouse 1 RD A Menu MenuFvwmRoot

Oh and by the way, you need FVWM >= 2.5.x for GNOME 2.x, or a patch and a module for FVWM 2.4.x.

So you want to start up a screen session with multiple processes running in multiple windows, e.g. for monitoring logs. And you want to do it on reboot.

# $HOME/backuplogs.screenrc
screen /opt/tivoli/tsm/client/ba/bin/dsmadmc
screen -t dsmserv ssh tea 'tail -f /var/log/dsmserv/current; bash -l'
screen -t tea ssh tea 'tail -f /var/log/dsmsched/current; bash -l'
screen -t marvin ssh marvin 'tail -f /var/log/dsmsched/current; bash -l'
screen -t vogon ssh vogon 'tail -f /var/log/dsmsched/current; bash -l'
screen -t dent ssh dent 'tail -f /var/log/dsmsched/current; bash -l'
screen -t prefect ssh prefect 'tail -f /var/log/dsmsched/current; bash -l'

# crontab entry
@reboot screen -dmS backuplogs -c $HOME/backuplogs.screenrc

I've been struggling with how to get IE to do the wpad thing, and found crazy log entries like this:

172.16.59.232 - - [17/Apr/2004:17:40:57 -0600] "GET /wpad.da HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"
172.16.59.232 - - [17/Apr/2004:17:41:24 -0600] "GET /wpad.da HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Win32)"

Yes, that's from IE (which is apparently pretending to be Mozilla). Note that it's trying to get wpad.da, not wpad.dat. So I symlinked wpad.dat->wpad.da and it still didn't work. Google wasn't much help; most people were successful with just a symlink or copy. Finally I noticed the problem: I had a case mismatch in the name of my function, and a missing paren. Compilers and run-time syntax errors have spoiled me I guess. Now if I could just get IE to time out that cache...

In the meantime I did the windows update thing and got some kind of service pack or patch or something. Nothing that indicated IE would be changed, but apparently it was because IE is now properly requesting wpad.dat again.

Incidentally, if you're trying to configure dansguardian you need to test it, right? Well it's odd that there aren't more test files out there. This one works nicely for me: http://falcon.fugal.net/dgtest.html.

I was migrating a bind9 setup from Debian to SuSE and couldn't get the transfers to work. To make a long story short I had to put ipv6 addresses in my allow-transfer entry, e.g.:

allow-transfer {
    ::ffff:172.16.59.5; 172.16.59.5;
};

I have no idea whether the second ipv4 entry is really necessary but I don't want to be burned.

A probably-preferable alternate solution is to comment out the line:

listen-on-v6 { any; };

and leave the allow-transfer the way it was (ipv4-style).