Just got back from my first outdoor run in what seems like forever, so I’m sure I’ll be nice and sore tomorrow. I’ve really fallen off with the biking (and exercising in general) recently, and I do hope to ride in several more times this year, but this is definitely the time of year when I start to transition from biking to running as my main form of exercise. Which reminds me that I need to pick up a new pair of shoes.

Work has been absolutely insane lately, as it always is this time of year (the kids are back). However this year has been rockier than recent years. myUMBC always gets pounded at the start of the fall semester, and this year we’ve had problems with almost all of our back end systems at one point or another: the HP3000, the Oracle database, and even our enterprise filesystem. myUMBC is kind of like a canary in a coal mine. It relies on a complex, fragile infrastructure of systems and services, and if any one of them goes down, myUMBC is usually the first thing to die. Here’s a rundown of emergency work performed in the last few days to try and keep myUMBC running:

• Late-night database reconfiguration to make Oracle less of a dog
• Shuffling Easipipe around to attempt to fix flakiness on the HP3000 (it didn’t work)
• Reconfigured myUMBC web server to work around IE SSL weirdness
• Turned off Tomcat clustering stuff that wasn’t working and was possibly screwing stuff up

Things seem to be improved today, with the HP3000 thing the only unresolved issue. We’re keeping our fingers crossed.

On the home front, we’ve got tulip poplar leaves all over the place. I would so love to cut those things down. I guess I shouldn’t complain too much, because they at least waited until the end of August. The drier the weather is, the earlier they start dropping leaves. We’re in a semi-drought now, although it didn’t start until mid-summer. If the entire summer had been dry, I probably would have been dealing with leaves in late July. I really need to get a leaf net for the pool.

And of course, the semi-drought likely will end tomorrow with the tropical system that’s supposed to pass through and give us more biblical flooding. It’s really feast-or-famine with rain around here these days, and it seems like it’s been that way for about a year now. Afterwards I guess I’ll have to mow again, which I haven’t done in quite awhile, and haven’t really missed.

If previous years are any indication, we’ve got at best another month of swimming left. And this year, we’ll be at the beach the last week of September (T-minus 3 weeks). So I guess we should toss Michael into the pool while the tossing’s good. On that note, I’m outta here for today.

Well.. after quite a bit of fiddling (what else is new) I managed to get Cisco’s VPN Client working on my Linux box. OIT provides a download for this, but it’s just a tar file of the client software.. no docs or any other info.

Details: I run Debian, and most of my Linux boxes have custom-built kernels; I don’t use the pre-packaged Debian Kernels. For some reason, I’ve found that things “work better” like that, at least for servers. Case in point: I initially tried to build the VPN stuff on a freshly-installed box with the stock Debian kernel, and it bombed spectacularly. I then built a custom Kernel, tried again, and it worked.

I run 2.4.x. Specifically, the two machines I’ve built VPN on run 2.4.32 and 2.4.33. I have no idea if the stuff works on 2.6 or not.

Installation:

1. Untar the distribution, VPNClient.tar.gz, and cd into the resulting vpnclient directory.
2. Become root and run the installation script:
   

   ./vpn_install

   It should be safe to accept the defaults for all of the prompts. One of the prompts is whether to start the VPN Service at boot time. Since I rarely use VPN, I elected not to do this. I ended up with an init script, /etc/init.d/vpnclient_init, which I need to run manually. Presumably, if you tell it to start at boot time, it’ll create the appropriate link in /etc/rc2.d or wherever.

3. UMBC includes two VPN “profile” files, "UMBC OffCampus.pcf" and "UMBC OnCampus.pcf". Copy these into the directory /etc/opt/cisco-vpnclient/Profiles. Make sure they are set to mode 644.
   

   cp UMBC* /etc/opt/cisco_vpnclient
chmod 644 /etc/opt/cisco_vpnclient/UMBC*

4. Check the file /opt/cisco-vpnclient/bin/cvpnd and ensure the setuid bit is set. For some reason, after installing on two different machines, one of them had the bit set and the other didn’t. This file must be setuid root or vpnclient will not run for a non-root user.
   

   chmod 4111 /opt/cisco-vpnclient/bin/cvpnd

5. Try it out:
   

   vpnclient connect UMBC\ OnCampus
   or
   vpnclient connect UMBC\ OffCampus

Problems? Make sure all the files are in the locations they should be (no filenames misspelled etc) with the exact permissions specified above. It’s very picky about this, and the errors it gives aren’t too helpful. strace is definitely your friend here.

In other news.. I think I’m going to try setting up a personal Wiki to document stuff like this. Using the blog for this kind of stuff does work (i.e. I’m documenting stuff that I previously wasn’t, and I have a resource I can refer to for stuff now), but the diary-like nature of the blog doesn’t lend itself too well to organizing information. With a Wiki, I’ll be able to organize stuff for future reference, and I can keep the Blog for the stream-of-consciousness type stuff. I think I’ll try MediaWiki initially, because I’m familiar with it and like its look. My only concern is that it might be overkill, so I’ll have to see what kind of footprint it has.

I bit the bullet today and bought a UMBC Parking Permit. Now, for someone who works at UMBC, this may not seem too remarkable. But, this is the first time I’ve had a parking permit in about 4 years. I’ve always had philosophical issues with the University charging its employees for parking, but that’s kinda beside the point — I originally worked in a remote area of campus (TRC building) with a lot of nearby street parking. So, it was kind of a no-brainer to eschew the permit and just park on the street. A few years ago I moved to main campus, which is about a 20-minute walk from where I was originally parking. But up till now, I remained permit-less. I would either park off-campus and walk the mile or so to my office, or I’d ride my bike in, or have my wife drop me off. It worked, for awhile. Now with two kids, it’s becoming too inconvenient. So, I got the permit. I’ll actually miss the occasional walks to/from my car, but it’ll be nice not to have to worry about getting to my office in bad weather. And, I don’t really feel the need to beat the system any more just to save a few hundred bucks. Sometimes convenience is worth paying for.

In other news, I hacked a bit on Easipipe today. Easipipe is the program that brokers connections between myUMBC and the HP3000 mainframe that serves as our SIS system of record. This is all part of the big project to move all our stuff off of SGI hardware. Easipipe is a big piece of that. It’s written in C, and required a bit of porting to get it running under Solaris. But it wasn’t too difficult after I dusted off my long-neglected C programming skills. Since we have two clustered portal web servers, I’ve decided to try running two Easipipe instances, one on each web server. It required a bit of hacking to prepare the code for the new configuration. The HP3000 listens on a total of 20 contiguous TCP ports. Each web server will use a block of 10 of those ports. The code needed to be hacked so each Easipipe instance could figure out the correct block of ports to use. Right now, I’m doing that by checking the hostname. I’m going to cut over to this setup tomorrow morning, so I can babysit it over the course of the day. I think it’ll work fine, but ya never know.

At UMBC, we have a bunch of web apps which are running on SGI hardware. The SGIs are no longer under maintenance, no longer being upgraded, no longer getting new software builds, etc. etc. Let’s just say “we’re phasing them out.”

I can’t help but feel a little melancholy about this turn of events, having been at UMBC in 1992 when we moved into the new Engineering/Computer Science (now just “Engineering”) building. We got a big pile of money to buy computers and other equipment for the new building. Now, up to that point, our department was primarily a DEC (Digital Equipment Corp) shop. And, we were all lined up to buy lots and lots of DEC hardware with our new-building money. But, DEC’s new baby, the Alpha chip, was not quite ready for prime time in 1992, so they weren’t able to sell us Alpha-based equipment in time for the building to open. So, DEC ended up losing (and subsequently getting bought by Compaq), and SGI ended up getting our money. SGI had just released their new entry-level workstation, the Indigo, and we packed our labs full of them. We also had Crimson servers and eventually, a 16-node Challenge XL. At the time, SGI was well-known for making high-end graphics workstations. They were featured in movies and were widely used by the entertainment industry for animation and special effects. As such, they showed up a lot in the popular press, so in general, the public was “aware” of SGI and their reputation. By extension, with our labs full of SGIs, we became cutting-edge too. It was a busy year, but it was lots of fun, particularly for a 22-year-old geek like me with no life outside of UMBC (hey, at least I admit it 🙂 )

But unfortunately, all good things must come to an end. The mid- and late-90s were not kind to SGI. Companies like ATI, nVidia and 3dfx began marketing cheap, high-end graphics cards for garden variety PCs. The cards got better and better, and SGI lost their edge. People began moving away from SGI’s proprietary hardware and OS, towards PCs running Windows or Linux. Then, the tech downturn hit, and that pretty much killed SGI. Now, pretty much every PC out there has graphics hardware that blows away anything SGI had back in the day.

The upshot of all this, is that we no longer have any SGI workstations at UMBC. However, we still have a few SGI servers plodding along, running legacy web apps, because no one has gotten around to moving the apps off. With the hardware no longer under maintenance, it’s only a matter of time till it dies, so I’m trying to get the apps moved off before that happens. That can be a challenge, because a lot of these apps also need other kinds of attention — for example, conversion from legacy authentication systems to our current campus single signon scheme. And many of them aren’t happy about being moved; lots of hardcoded path names, hostnames, URLs etc.

So it’s a slow process, but I’m slowly getting it done, moving us ever closer to the day when we can shut down the last SGI machine at UMBC… the end of an era.