Emergency repairs with GRUB
This server lost its boot drive today, which occasioned a certain amountof flailing. We use mirrored drives, but there were two problems: thedead disk wasn't actually dead , just puking, and the second diskhadn't been set up to be bootable (although it had a fully populatedcopy of the /boot partition). The first problem was dealt with byyanking the drive's power plug out, but the second one took more work.
Although GRUB people may hem and haw about it
Weekly spam summary on April 29th, 2006
This week's statistics are distorted by a Wednesday noon system rebootthat had the effect of resetting some of them. Having said, that, thisweek we:
- got 11,083 messages from 230 different IP addresses.
- handled 15,463 sessions from 840 different IP addresses.
- received 88,321 connections from at least 28,538 different IPaddresses since Wednesday noon .
- hit a highwater of 38 connections being checked at once,
Another little script: field
In the footsteps of the first little script , here'ssomething I call field :
#!/bin/shfn=""for i in "$@"; do nf='$'$i if [ -z "$fn" ]; then fn="$nf" else fn="$fn, $nf" fidoneexec awk "{print $fn}"(The exec is another way around the Linux bash issue .)
You give it one or more
Some first impressions of Fedora Core 5
I've recently been playing with Fedora Core 5 (I know, I'm a bit behindthe times) on a new Athlon 64 machine. In the spirit of my firstirritations with Fedora Core 4 , here are somevery early, very preliminary impressions of Fedora Core 5:
- the
hciddaemon (part of the Bluetooth stuff) consistentlycrashes on system shutdown on x86_64 machines. Since Idon't have any Bluetooth stuff, I'll be removing the bluez-utils
A picture of what university IT is like
I've written before about how university IT is peculiar and convoluted . Now,courtesy of the UC Berkeley Campuswide Information Strategic Plan2004-2005, comes a lovely description of this complicated environment:its Campus IT Plan: Critical issue 5: Governance, funding,structure section.(Other sections of the report are also interesting; I've got somereading to do.)
I'm pretty sure you could reuse that section more or lessas-is to describe the University
Common web spider mistakes
It turns out that a lot of web spiders crawl my website here, andbecause I read my web server logs more than the average monkey I'vegotten to see a number of web spider mistakes over and over again.These mistakes are so common that it's a rare day when I don't seeat least one of them in the logs.
(These are mistakes as opposed to stupid spider tricks because they are so clearly wrong by the basic rules of HTTP.)
So, stupid web spider
Linux's %iowait statistic
The iostat manpage documents %iowait as:
Show the percentage of time that the CPU or CPUs were idle duringwhich the system had an outstanding disk I/O request.
It turns out that the manpage is wrong, which I found out by reading thekernel source because I was curious about what exactly it measured.
The actual definition of %iowait is the percentage of the time thatthe system was idle and at least one process was waiting for disk IO tofinish . (This is true for both the 2.
People are social
People are social. We like to show off, to talk, to be heard, and byextension to share. There's every sign that "look at me" is a corehuman drive, along with its kissing cousin "look at this".
This sounds like an obvious thing, but then a number of people turnaround and wonder why there are so many people using LiveJournal (and ina prior era, making homepages on GeoCities). The former explains thelatter: we blog because people look
Some CBL stats for the week ending on April 22nd, 2006
As mentioned in this week's spam summary ,this week I decided to change our SMTP frontend's configuration to getstatistics on the CBL that were better thanmy previous quick SMTP connection stats . Nowthat this week's up, the results are in:
- the CBL rejected 41% of our incoming SMTP connections this week.
- 75% of the connection we rejected were rejected for being in the CBL.
- more tellingly, 85% of the IP addresses that we rejected atconnection time were rejected
Weekly spam summary on April 22nd, 2006
This week's statistics are atypical, because in pursuit of better CBLstatistics I moved our CBL check before all of our other connection timechecks (including our greylisting) and pretty much stopped adding IPaddresses to our kernel filters during the week.
Bearing that in mind, this week we:
- got 12,845 messages from 226 different IP addresses.
- handled 17,723 sessions from 788 different IP addresses.
- received 141,631 connections from at