MOTD

Real time apache hit meter. Displays number of hits per second on each line. Could probably be made more pretty with ANSI codes and whatnot. It only has one second of resolution which is a bit of a shame. Using something other than date could help that. I wrote this on a BSD system so GNU date may be better for this. Tuning the -10 passed to head varies the frequency of updating the output, and resolution a bit. And if you want to just check a part of the site or certain clients toss a grep (or some other selector) in between the while loop and the tail.

tail -f access_log |
    (while true; do
        echo "`date +%s` `head -10 | wc -l` `date +%s`"
     done) |
    awk '$3 != $1 { print $2 / ($3 - $1) }'

So why in the hell do people feel the need to put our browsers through redirect hell to download a tarball? Listen up fuckers, I don't want to download your crap ass SERVER software on my WORKSTATION. I need it on the SERVER.

GAR GAR GAR.

This chunk of code allows you to add a little artificial slow down to your bash scripts. Add it to the top of the shell script and watch ... everything ... pass ... by ... real ... slow.

Especially useful with set -x.

sleep_some () { sleep 1; }
trap sleep_some DEBUG

So this is probably a no-no to someone, but it is an intriguing trick. At the beginning of your shell scripts try this on:

cat $1 |
    ... <rest of code>

So let's say you want a program to take input from stdin or from the command line argument. Viola! There you go. If someone does specify an argument then it waits for stdin. Or if you do specify an argument it just handles it. I can imagine a few reasons why it probably isn't good for production code. But damn I like it.

tee with compression:

#!/bin/bash

tee >( gzip -c9 > $1 )

Makes typos work for you. Caution: May cause major system damage if used erroneously.

While attempting to hack up a proxy arp daemon thing that would cook my emergency bacon I got frustrated. I was attempting to transcend the ethernet header and examine the arp packet. For some strange reason the only illumination to be gathered from the arp packet was that it was full of NULL bytes. Extreme frustration set in, at which time I thought to myself, "Screw this pony! This thing has to work without stupid userspace tools!"

A more subtle crafting of google search terms lead me to the astonishing revelation: Linux won't answer ARP for an IP on an interface if the routing table says that the packet should be routed back out of that interface! Well of course not! If it did that you could blackhole all sorts of network traffic without even really trying. The solution of course is to make it think that it is routing it elsewhere (in my case the loopback device), and then the iptables can step in and do the right thing.

So the lesson learned here is: if you do strange voodoo with your packets you need to think about non-voodoo things that the OS may be trying to save you from.

Proxy Arp appears to not be working for me (2.4.18 and 2.4.24). I'm pretty sure that something is wrong, but I seem to be at a loss for finding actual useful documentation on actually debugging what is wrong. And now I'm about to hotwire something up in scapy or some crazy hax0r tools just to get it to work. GAR GAR GAR!!!While doing this it occurs to me that I really should put the HURD on this box soon.