The Life of a Sysadmin

The two Adaptec 39160 SCSI cards came in at last, so I had a chance to play around with the Promise VTrak 15100 last night...though only for a couple hours, and without much luck. I could create a test array on the VTrak (I've got four drives in there now for playing with), but I was unable to get the FreeBSD box to see it. I played around with camcontrol devlist and camcontrol rescan for a while, but no joy. For fun I tried booting Knoppix 3.6 and had the same result: the box found the SCSI card, but not the array the Promise firmware said was there. Possibly important datapoint: the Adaptec BIOS found the Promise at Channel B, ID 1, but said it was not a hard drive. Hm. I'm putting this down to ignorance and inexperience right now; this is the first time I've played with external drive arrays, SCSI hard drives, and FreeBSD/Linux. I may need to resort to reading the instructions from Promise (though they're pretty thin...). I got a look at the network wiring plans for labs for our new place (have I mentioned that work is moving in June?). Sweet: three labs, 70-odd drops, managed switch in each and 2 x Cat6 from each to the server room. The offices won't be nearly so wired, which is a shame, but at least there's this. I also had a chance to look into Asterisk. Right now we're desperately short on voxmail (less than half the staff has it) and have just run out of places to hook up more handsets. The phone equipment we have belongs to the other company on the floor (they used to have the whole floor, but kind of imploded); this means that we're reluctant to put many into upgrading something we don't own, but the move is an excellent chance to start fresh. Unfortunately, I don't think Asterisk going to work out for us. Asterisk looks great -- from what I understand, and that's maybe half of what I read -- but we've bought a crapload of Meridian/Norstar handsets, and it looks like they speak their own special, non-Asterisk compatible protocol. ('Course, all this is just from half an hour's reading...) The simplest thing to do is plunk down for a Meridian/Norstar compatible...thing to do voicemail and such. PBX, I guess. There are ways around this. Some people put Asterisk between their Norstar PBX and the Central Office, and do some magic to make that work. Trouble is, we don't have a PBX right now -- just the handsets. Another option is to sell the handsets (at least one company has offered to buy whatever we want to sell) and buy VOIP phones, or just buy a bunch of adapters that turn our current phones into regular analog phones. This would require hiring some kind of consultant or contractor, though; I don't know nearly enough about this to try doing this on my own. It would be one thing to try it at home (hm...no, after the PVR), but I just don't have the chops to try it at work. Anyone know an Asterisk/VOIP guy in Vancouver? -- Actually, I think I know one guy who might do this sort of thing; I should give him a call. Managed to clear a bunch of stuff off my todo list today -- ordered $500 worth of patch cables, PO for more software licenses (ugh), RMA for some wrong stuff I ordered, yadda blah -- but that's the easy stuff; I've still got network upgrades, the Vtrak, we're running out of Unix machines (o the irony, as we gradually shift to a Windows shop), two big software upgrades to install, and maybe ten new people being hired over the next month or two. I've reminded my boss that I still need help. If anyone out there is strong on Windows but still can do Unix, and you're in/near Vancouver, BC, let me know; I need a fellow sysadmin who can take a problem from either side of the fence.

A few tips for installing Matlab on Debian:

1. Debian does not mount devpts by default (at least, not on my installs). You'll need this. Run: mount -t devpts devpts /dev/pts and then put it into /etc/fstab.
2. oscheck.sh, part of Matlab's many startup scripts, attempts to run /lib/libc.so.6 in order to get the version. I had no idea this could be done. One email I found on Google suggested changing the line in the script that ran libc to one that just took the version from strings...but then Matlab support (who were great, btw) suggest chmod +x. That never occured to me...I mean, it's a library, right? But it worked.
3. Debian (my installs, anyway) mounts /cdrom with the noexec option. This causes an error when you try to run /cdrom/installer: /bin/sh: bad interpreter The solution, of course, is to mount the CD like so: mount -o exec /cdrom

Re: that last step: Don't forget to do this for the other CDs! Shocking confession: I did forget, and I'm pretty sure the graphical installer did not catch this. I was left with a nominally successful install that simply did not work when I tried to run it graphically: it would hang at the splash screen and eat up 99% of the CPU time. I fucked around with strace, tracked down file descriptors and I don't know whatall until I finally tried reinstalling on a local machine. The install was as root, but root couldn't connect to the X display so I ran it as a text-based installer...whereupon I noticed that it complained that it couldn't run the installer on the second CD. Well, fuck. Another problem I had was with the path: for some reason it wasn't set up correctly, and when I started I got errors about colordef: undefined function. When I tried to follow the suggestion and run restoredefaultpath;pathdef I got an undefined function error for that, too. Matlab support provided the solution for that: remove the old toolbox/local/pathdef.m, run genpath.sh (a script downloaded from their website), and run Matlab again. It seemed to take a few restarts of Matlab before the new path took, but now that it has everything seems to be working again. Again, thanks to Matlab support for helping me out...prompt, patient and helpful.

1. Someone found my blog by Googling for "what in fucks name do i need to open .ELF files".
2. When I do that search myself, the Google AdSense banner that comes up says "You Can Break Free From internet pornography quickly and easily if you really want to."

Welp, Promise has come through on the first part of the GPL: they've put up the source code on their FTP server (look around, not that hard to find...) for Busybox and a Linux kernel. Looks like the kernel tarball is a copy of 2.4.18, and Busybox is 1.00-pre3. I'll be grabbing original copies of each and see if I can find any differences. In the meantime, I've put up both on my website (though see below re: further GPL obligations, and note that I do not vouch for or guarantee the integrity of these tarballs -- for all I know, I've got a bunch of cunningly renamed source files for SoBig). --Woohoo, there's even .config files in both! Next step is to convince them that Sections 3a and 3b (hand out the source with the binaries, or offer to hand out the source for the binaries) is just as important as giving me a copy. But kudos to Albert Dy, Technical Support Manager at Promise, for working with me on this.

From the article Fewer permissions are key to Longhorn security:

Microsoft said it would encourage the use of least permissions in Longhorn by making it easier for users to do common tasks without administrator privileges. For example....allow developers to create per user installations of applications, with user-specific settings saved in the "my programs" folder, rather than a globally accessible program files directory that requires administrative permissions to change....Windows programs commonly save user-specific files to critical areas of the operating system, such as the program files directory or protected parts of the Windows registry, which stores configuration information and is off-limits to regular users...

...splutter...Gee, individual settings saved in areas controlled by individual users...WHY IS THIS NEWS? How is it even possible that this never occured to MS before?

The company also has an opportunity to brand LUA with its own user-friendly features and interfaces, which would be a vast improvement over platforms like Sun Microsystems's Trusted Solaris and Unix, Gartner's Pescatore said. "They are so complex, nobody can use them," he said. "They require every user to be a security expert. But if you look at what Microsoft is good at, it's not inventing ways to do security, but ways to make security easier to implement for security administrators."

Okay, WHAT? What the fucking fuck was that? Have I been trolled? Is this guy secretly laughing up his sleeve at the way my face is turning RED WITH RAGE? Honestly.

1. Where the fuck was Microsoft when they were writing NT/2000/XP? Why the hell are there so many fucking programs that demand admin or power user access simply to use? No, MS did not write all these programs themselves, but it's their damned operating system and their damned culture of "Well of course you're the only one on the computer! Of course you're running as a power use! Of course it won't affect anyone else if you're given too much privilege!" Microsoft has a LOT of shit to clean up, and it's not just in their crappy, crappy OS: it's in the attitudes passed on to users and developers too.
2. "[Solaris and Unix] require every user to be a security expert." No, actually, they don't. That's the whole fucking point. The programs are (generally, yes there are exceptions) well-behaved: they don't need crazy privilege, they save user-specific files IN THE USER'S FUCKING DIRECTORY, and so on. You need one security expert -- the sysadmin (and hey, before anyone kicks I am not saying I'm a security expert or anything like it) -- who sets things up safely. You don't have a glorified text editor (hello, Code Composer!) that requires power user to run it, and you don't have the accompanying conversations about "please don't install that app again".
3. "But if you look at what Microsoft is good at, it's not inventing ways to do security, but ways to make security easier to implement for security administrators." HA! It is to laugh. I can hear you out there wondering why I don't get a copy of Regmon to look at what registry keys CC needs access to, and open up the permissions on that. Excellent question, and I should be dropping everything to do that right now -- point taken. But why the fuck isn't a tool like this included with 2K to start with? Why are all the admin tools MS does provide squirrelled away in different resource kits and download areas, safely kept from the unschooled likes of me?

I'm ranting. There are flaws in my arguments. I don't like or trust MS or Windows very much. I lhave drunk deeply of the Unix kool-aid, and I am horribly, horribly biased. But for the love of all that is holy, this whole article just leaves me agog. Redmond can't be that ignorant, and I mean that sincerely. But what the hell else am I supposed to think? Why has twenty-five years of open, easy-to-find operating system knowledge passed them over? What lamb's blood did they smear over their cubicle doors to prevent the Angel of Death from entering?

(Story hit Slashdot today, and I saw it too late to get this comment in...so this rant hits the journal. You lucky, lucky people.)

Yet another person confusing the presence of a graphical browser with passing the Turing test. O'Reilly's articles are usually excellent, which makes even more confusing the lack of any mention of text browsers or the disabled. Yo, Tim! You listening?

Weird problem yesterday when moving a server: for some reason, amd would not start up properly when it rebooted in its new location. Same network setttings, same chunk of network, so wtf? ps showed that its terminal was con -- console, I presume -- which was doubly weird. I logged into another machine to make sure that was abnormal, and yes it was. amq -f gave the error program not registered, and sure enough rpcinfo -p showed the usual suspects sans amd. Well, the only thing different about this machine is that it's got some jails running (which don't need to be running anymore, but I hadn't had a chance to shut them down). That meant some additional aliases for its outside interface in /etc/rc.conf on the subnet I set aside for this sort of thing. I commented them out, rebooted, and presto -- no more problems. Maybe something to do with picking which interface to listen on?

Is it safe?

I don't know what I did right, but I've had a lot more luck with the Promise VTrak 15100 this time. I got a chance to work with it more on Monday, and this time it just worked. For the record, what I'm using for testing is a P4 running FreeBSD 4.10, an Adaptec 39160 card, and the VTrak with 4 disks. I had set them up in one RAID 5 array on Saturday, and was unable to see the disks at all. This time, I deleted that array, created a new RAID 0 array of one disk, rebooted FreeBSD, and bam -- da0 was right there in dmesg. I set up another RAID 5 array of three disks, ran camcontrol rescan all, and there was da1. Very strange. Strangeness continued: the two disks were sloooooow when I first used them. The first array was about 250GB, and the second was 450GB; running newfs took 7 and 14 minutes__, respectively. To make sure it wasn't something specific to formatting, I ran dd if=/dev/zero of=/mnt/test bs=100m count=100, and the times were similarly ridiculous: between two and three minutes, compared to 2-3 seconds on a local, IDE-based drive. WTF? I decided to reboot the VTrak, and the problem went away: the dd test took about 3-4 seconds...slower than a local IDE drive, but acceptable. Still no idea what might've been going on.

but I was finally able to track down the original for this picture. It's absolutely amazing...just like this and this. Strange how you change. I used to read and re-read Huckleberry Finn 'til I wore out my copy, wishing I could've lived in 19th century America. Now I'm afraid I (or my species) won't live long enough to get into space, and wish I could be part of some grand colonizing effort.

Holy crap, I'm busy these days. First off, it's MS patch week. That means I'm in here on a Saturday afternoon patching by hand. Yes, you're right, it's very ugly; this is why I'm trying out a couple of things that I hope will make it easier. The first is Daisy, a program (and by the way, the next time someone says "solution" when they mean "program" ah munna punchem inna cock) from the University of Virginia Virginia Tech (thanks, Joe) that

• automates Windows patches, and
• is Free Software. Yay!

It has a couple problems that seem mostly due to the program they use to scan for missing patches -- always seems to say that the same three patches are needed, whether or not they've been applied -- but overall I'm quite happy with it.

The next thing I'm trying is running Daisy remotely, by installing Cygwin and SSH on each of the machines. Unfortunately, this isn't working so well; the same command-line options that work from a local shell (whether Cygwin or cmd) just don't when I'm logged in by SSH: it says that it can't see that any patches have been applied, tries to download 'em all from the local repository I've set up, and is very unhappy when they're not there.

Next thought is to try installing crontab and shutdown with Cygwin and use crontab to run Daisy (or other patches) locally. That has problems too: Cygwin looooooves updating everything, and if you've (say) installed Cygwin a year ago and haven't bothered updating it since, it runs around trying to download newer versions of everything. What's more, there's no way to turn off that behaviour in the installer...very annoying. I think I'll try installing crontab and shutdown individually (managed to find a script a while back to do that properly), and see how it goes. Of course, since I've just applied all the patches for this month, it's gonna have to wait.

Which is fine, because second, I found out on Thursday that a dozen people are moving to a temporary office for two months, they'll be there May 2nd, and I have to make sure they can still work while they do that. A bunch of them are doing nightly regression tests; this means their files will need to be here, but a 1Mb/s cable link and X forwarding is gonna be mighty painful. (Or so I'm told...why they can't just use SSH and vi for everything is beyond me...grumble...)

I called around to see if anyone could set up a temporary LAN extension over fiber or some such, for two months, with two weeks' notice. HA! Not a chance: a six-month contract and a six-week lead time was the best anyone was willing to offer. But hey, not a problem -- the new place is maybe 150 metres away as the crow flies, and we've got line of sight in between here and there -- hell, I can see the corner office from here.

So I called up Telus and asked them if they could do this. "Sure can!" said the bright young man I was dealing with, and you could hear the wind from his enthusiastic nodding. "We'll do 802.11g between here and there. It's perfect! And it only takes 8 weeks to do a site survey!" I reminded him of my two week deadline. "Not a problem! We'll just convert it after the move to wireless Internet access over your entire office! The boardroom, the desktop, the kitchen...and we remotely monitor it to prevent intrusion! We'll use whatever authentication standard you're using! We try to stay away from WAP, but we can use WEP if you like!" Sigh...okay, how much? "Forty-five thousand dollars. How soon do you think you'll be able to take advantage of this opportunity?"

Fortunately, I found another ISP that's interested in mounting an antenna on the roof just to be able to offer their service to other tenants. Looking good so far. And since they offer gigabit Internet access for $500/month, I'm thinking the price can't be that bad. (Yeah, gigabit 'til the first router that isn't theirs. But still.)

Third, I'm still trying to get the Promise VTrak up and running here. Still running out of space, still haven't had much time to play around with it. Well, except for today. Starting to find a couple things that are annoying (besides the GPL violations, I mean). First off, it looks like changing the cache policy on a logical drive (ie, from write-through to write-back) requires a reboot of the array itself (!) to take effect. Second, even without changing the write-back policy, it looks like a reboot of the array makes a newly-created logical drive orders of magnitude faster -- ie, bringing it up to an acceptable speed. (I'm not certain of that, though, so grain of salt etc.) Third, no MIBs/OIDs -- whatever the proper term is -- for SNMP are shipped with the documentation...still trying to get this out of Promise.

I'm starting to make a bit of progress on the NWR04B -- almost to the point where I could comfortably say it's crashing. Yay! The problem so far has been that I wasn't getting any output on the serial port when (presumably) Linux was booting. Some judicious insertion of ARM assembly code into the kernel image showed me that it was at least running, but I had no clue what I was doing after that. I managed to follow the path of the assembly code through head.S, which is the very, very first bit of anything that gets run when you've got a compressed kernel. This is so early that it takes a while even to get around to decompressing the kernel. After that, I was able to follow it through to misc.c, where decompress_kernel gets run. There's some puts statements in there (like puts ("Uncompressing Linux...");), so how come I wasn't seeing anything? Well, because puts wasn't defined as anything. puts is defined in head.S as some assembly code to write a string to the serial port, but that wasn't referenced by misc.c; attempts to #include it failed horribly. There's an #ifdef STANDALONE_DEBUG that defines puts as printf, but attempts to build a kernel using that didn't work either. But follow the bouncing ball:

• arch/armnommu/boot/compressed/misc.c #includes asm/arch/uncompress.h
• which is actually include/asm/arch/uncompress.h
• which is, once you follow the symlinks, include/asm-armnommu/arch-cx84200/uncompress.h
• which defines puts as cx84200_puts
• and uncompress.c defines that as being an empty function
• but the equivalent definition in arch-samsung defines it as a bunch of calls to `putc```
• and that is defined as CSR_WRITE(DEBUG_TX_BUFF_BASE, c)
• so the equivalent for arch-cx84200 would be CSR_WRITE(UART0_BASE, c)
• because UART0_BASE is defined in hardware.h as 0x90000000
• which I knew from reading the datasheet is the chunk of memory where you drop stuff when you want it written to UART0, aka serial port 1.

Whew! So I tried that, and hey -- I got garbage on the screen! But not very much: I was expecting something like "Uncompressing Linux..." and instead got maybe 20 characters of garbage. I took another look at the assembly version of puts, and one of the things it does is waits for 20,000 clock cycles -- which at 60MHz is a third of a second. Try adding a loop to count down 60,000 cycles (what the hell), and hey! more garbage -- though still a finite amount, and it stopped after maybe 5 seconds or so, and still nothing intelligible. What the hell's going on? I tried this:

static void cx84200_puts(const char *s)
{
        while(*s != '\0')
                cx84200_putc(*s++);
        cx84200_putc('F');
        cx84200_putc('I');
        cx84200_putc('X');
        cx84200_putc('M');
        cx84200_putc('E');
        cx84200_putc("\n");
}

and now I started to get garbage that had FIXME tossed in for good measure. A quick cat /dev/ttyS0 > logfile (have I mentioned that I love Unix?), and whaddaya know: I'm getting precisely four FIXMEs. If I threw an extra puts ("FIXME"); into misc.c, I got five, not six -- the string going to puts doesn't come out, but the extra putcs I put in do work. For the moment, this is where I'm stuck. The garbage/extra characters I'm seeing don't seem to have any relation to messages I might expect ("FOO", "Uncompressing Linux...", etc. There's places for the kernel to crap out after that, but I don't think there's any before. And why the hell am I seeing all the garbage, then a perfectly intelligible "FIXME" after that? What is happening to the strings to get them all fucked up?

Less and less impressed with Promise. Here's what I had done: while doing some copying onto a logical drive, I yanked one out. I wanted to see what would happen, what would need to be done, and so on -- I don't want to be figuring this out for the first time when it happens. Well, it started beeping, and the event log said that the logical drive was critical. Start rebuilding, right? Wrong: policy for that drive was set to non-auto-rebuilding. Try turning that on, and it doesn't work: keeps saying it's non-auto-rebuilding. Manual for the VTrak:

if your fault-tolerant logical drive goes offline, go to the Promise website (www.promise.com) and download a document called_Array Recovery Procedure_.

Damn good thing I'm not doing this for real. Go to www.promise.com and type "array recovery procedure" into the search bar. The result:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot use a CONTAINS or FREETEXT predicate on table 'product' because it is not full-text indexed. /search_insert_eng.asp, line 34

Fuck me. Use Google to find the document, which has instructions for the UltraTrak, the predecessor to the one I've got. Hope it still applies and read on. It sez to reboot the array (!) in order to trigger the rebuild (!!). Sure enough, it works. Oh, and have I mentioned they still haven't sent me the SNMP OIDs/MIBs after six weeks of calling their technical support manager? FUCK ME.

Still trying to figure out what the hell is going on here, and why it won't print the messages I expect it to (while still printing the FIXME I stuck in at the end of the puts routine w/o any problems). I've been looking at the disassembled zImage, and I'm scratching my head. Here's the deal: shortly after power-on, the decompress_kernel routine is run:

000074 EB000915 BL      &000024D0

In C, decompress_kernel looks like this:

ulg
decompress_kernel(ulg output_start, ulg free_mem_ptr_p, ulg free_mem_ptr_end_p,
                  int arch_id)
{
        output_data             = (uch *)output_start;  /* Points to kernel start */
        free_mem_ptr            = free_mem_ptr_p;
        free_mem_ptr_end        = free_mem_ptr_end_p;
        __machine_arch_type     = arch_id;

        puts("EMXIF");
        proc_decomp_setup();
        arch_decomp_setup();

        makecrc();
        puts("Uncompressing Linux...");
        gunzip();
        puts(" done, booting the kernel.\n");
        return output_ptr;
}

At 0x24D0, we've got some initilization, some register saving, and then the puts routine is called:

0024FC E59F0034 LDR     r0, &00002538
002500 EBFFF769 BL      &000002AC

This is the first call to puts: puts("EXMIF"); (which is FIXME backwards; I had it frontwards at first, and wanted to see if the output was any different if I changed the string; it's not). puts looks like this in C:

static void cx84200_puts(const char *s)
{
        while(*s != '\0')
                cx84200_putc(*s++);
        cx84200_putc('F');
        cx84200_putc('I');
        cx84200_putc('X');
        cx84200_putc('M');
        cx84200_putc('E');
}

(more checking to see what works) and like this in ARM assembly:

0002AC E1A0C00D MOV     ip, sp
0002B0 E92DD810 STMFD   sp!, {r4,r11,ip,lr,pc}

Save the registers for later...

0002B4 E1A04000 MOV     r4, r0
0002B8 E5D43000 LDRB    r3, [r4, #0]
0002BC E24CB004 SUB     r11, ip, #4
0002C0 E3530000 CMP     r3, #0
0002C4 0A000004 BEQ     &000002DC

r0 held the argument, and it's moved to r4. Check the first byte to see if it's zero (ie, if we're printing a null string), and jump ahead if it is. Not sure what we're doing with r11 here.

0002C8 E5D40000 LDRB    r0, [r4, #0]
0002CC EBFFFFEB BL      &00000280
0002D0 E5F43001 LDRB    r3, [r4, #1]!
0002D4 E3530000 CMP     r3, #0
0002D8 1AFFFFFA BNE     &000002C8

Load the first byte again into r0, then go to 0x280 (putc) with it. Increment r4 and see if it now points to a zero. If not, go through the routine again.

0002DC E3A00046 MOV     r0, #70
0002E0 EBFFFFE6 BL      &00000280
0002E4 E3A00049 MOV     r0, #73
0002E8 EBFFFFE4 BL      &00000280
0002EC E3A00058 MOV     r0, #88
0002F0 EBFFFFE2 BL      &00000280
0002F4 E3A0004D MOV     r0, #77
0002F8 EBFFFFE0 BL      &00000280
0002FC E3A00045 MOV     r0, #69
000300 EBFFFFDE BL      &00000280

This is the printing of FIXME at the end of puts.

000304 E59F0008 LDR     r0, &00000314
000308 E20000FF AND     r0, r0, #&FF
00030C EBFFFFDB BL      &00000280

Put 0x314 into r0, AND with 0xFF, then call putc again.

000310 E91BA810 LDMDB   r11, {r4,r11,sp,pc}
000314 00042548 ANDEQ   r2, r4, r8, ASR #10

And I think this is where we fall off the end of puts. Finally, a quick look at putc, first in C:

static int cx84200_putc(char c) {
        int i;
        int j = 10;

        CSR_WRITE(UART0_BASE, c);

    for (i= 0; i < 60000; i++)
                ;
}

(j left over from another bit of debugging) and assembly:

000280 E1A0C00D MOV     ip, sp
000284 E92DD800 STMFD   sp!, {r11,ip,lr,pc}
000288 E24CB004 SUB     r11, ip, #4
00028C E3A02CEA MOV     r2, #&EA00
000290 E2822060 ADD     r2, r2, #96
000294 E20000FF AND     r0, r0, #&FF
000298 E3A03209 MOV     r3, #&90000000
00029C E5830000 STR     r0, [r3, #0]
0002A0 E2522001 SUBS    r2, r2, #1
0002A4 1AFFFFFD BNE     &000002A0
0002A8 E91BA800 LDMDB   r11, {r11,sp,pc}

So here are my many bits of confusion:

1. That first call to puts should have r0 pointing to EXMIF, right? Only it doesn't: 0x28A0 is where you can find this string, and r0 points to 0x2538. There's no ASCII there, and certainly no copy of the string I want. If I change the instruction so that r0 points to 0x28A0, the thing crashes badly -- just spews out hexdumps of something (presumably memory).
2. That last call to putc from puts, where r0 points to 0x314. WTF? It explains why I'm seeing H% at the end of the strings, but as far as I can tell it certainly shouldn't be doing that. Again, there's nothing around 0x314 that would explain why we're trying to print it.
3. And in putc, what is with AND r0, r0, #&FF? As far as I can tell, this has absolutely no effect on r0: it's a NOP.

I can only think of three things:

• I'm wrong.
• The disassembler I'm using has a bug.
• GCC has a bug.

If anyone has any insight to share, please let me know. This is really bugging me.

At last, Promise sends over the MIBs for the VTrak 15100. I've put 'em up with the kernel and busybox sources. Still waiting to hear when they're going to comply with the GPL re: offering source.

I got the iBook, I got the Slashdot t-shirt, I got the beard...but do you think I can get a wireless signal? Oh no. Thanks, Broadcom. But hey, enough complaining. Time for an update. The wireless ISP is gonna do a point-to-point link between windows of our old and new temporary offices. Should give us 100Mb/s access or so. Which is good, because for a while I thought I'd have to walk down to London Drugs, grab some Linksys routers, and install my own firmware to do it. Which would have been a lot of fun...but would have been a fuck of a lot to get ready in, like, three days. Now I just have to get OpenVPN talking at either end, get Shaw installed, and set up a firewall. Oboy. And then there's the troubles I've been having with our backup server. A while back I decided to start racking all the boxes we've been using as servers -- transfer the hard drives to proper servers, then use the old shell as a desktop for a new hire. Welp, the backup server was the first to go, and man it's been a headache. First off, I didn't take care of cooling properly, and the tape drive (HP Ultrium 215, for those paying attention) suffered a nice little nervous breakdown and kept spitting out the tape. I tried downloading the HP diagnostic tool, but it only runs on Linux and the server runs FreeBSD -- neither Linux compatibility mode (not surprising) nor a Knoppix disk (kept hanging) allowed it to work. So I had no real idea what was going on other than the drive was too hot for my liking. But HP, bless their souls, came to the rescue. Once I made it through their speech recognition voicemail tree hell, they just sent out another one -- they didn't even bitch about not being able to run the diagnostic tool. Not only that, it came the next day, and we don't even have any special contract with them -- that's just warranty. Thumbs up for them. But now I've got different problems: the damn machine keeps seizing up on me. See, I've got this 500GB concatenated Vinum array of three disks that I use as a copy of yesterday's home directory for people, and I'm trying to move it to a four-disk RAID5 drive on the Promise array. I tried using rsync, and it just froze...but eventually. I thought maybe rsync was spending too much CPU time figuring out what to transfer, so today I tried using dump | restore -- and sure enough, it froze again. I plugged in a monitor, hoping for a panic or something, but nope -- just unresponsive. I've found some mention in the FreeBSD mailing lists about possible problems with write caching and the Adaptec 3960D SCSI controller (which I thought was a 39160 SCSI controller, but I guess not). I'll have to see if that does the trick or not -- but in the meantime I'm wondering how I'm gonna get yesterday on the Promise. Of course, figuring out why it's crashing in the first place would be even better... But it's not all bad news: earlier this week, the support manager at Promise that I've been dealing with called to tell me that the word had come down from on high. Yep...Promise is going to follow the GPL and properly release the Linux and Busybox source code for the firmware that goes into the VTrak 15100. Hurray! I'll have to watch, of course, and make sure it shows up...but it sounds good. "Let's put it this way," said the manager. "It's on my desk for me to do. And I don't want it there for long." To the home front, now. As if I didn't have enough on the go, I've blown my tax return on the makings of a MythTV backend: 2.4GHz P4, umpty-GB hard drive, the PCHDTV-300 (get it while you can!), generic 128MB Nvidia (no onboard video on this mobo, or I would've stuck with that), a Hauppauge PVR-500MCE, and a nice Asus mobo in an Antec case to tie it all together. Random notes:

1. I like the case-- no sharp edges, very well put together, easy to assemble, and pretty damned quiet. Nice.
2. I think the graphics card was causing problems -- the machine kept seizing up for no apparent reason, and when I opened the case to have a look the heatsink was almost burning hot. (Memory was my first guess, but I'm running Gentoo on this and all the compiles went fine -- kernel, gcc, qt...'as a lotta compiles.)
3. The ivtv project lists the PVR-500 (dual tuners! yeah, baby!) as in alpha, but a fair few people have reported success with it. Me, I'm getting the finest MPEG-2 recordings of static you could ask for...but then, I'm pretty sure I'm doing something wrong, and I simply haven't had a chance to work on it since getting it assembled last weekend.

And now for something completely different: new mottoes for Harley Davidson: "Harley-Davidson: Because social contracts are for weak pussy-ass losers with small dicks." "Harley-Davidson: Because those other people aren't really human. Not like you and me." "Harley-Davidson: You deserve it. So do they." "Harley-Davidson: Because if you pissed in their faces, you'd be arrested." "Harley-Davidson: Because 'Fuck you!' is just too damned hard to remember." "Harley-Davidson: Because 'Fuck you!' is just too damned eloquent."

Problem: Screen, installed from ports on a 4-series FreeBSD box, start taking 99% of the CPU (!). Solution: Build from ports. Don't know why I didn't try that sooner. Also: an ampersand ends a command in Bash the same way a semi-colon does. Thus, this is wrong in a Makefile:

all:
        foo & ; \
        bar

And this is right:

all:     
         foo &\
         bar

Whee!