Biking Work

T-Day Week

It’s a short work week, so I’m working on wrapping a few things up at work ahead of the Thanksgiving holiday. Next week, we have our second virtual Shibboleth training class of the year. These seem to be popular, as the last one sold out, and we’re pushing 30 registrants for this go-around. I think we’re pulling in a new audience that we wouldn’t ordinarily see at our in-person trainings. The online format has given us an opportunity to revamp our course and training materials, which was overdue, and we’ve identified some things along the way that we can use to eventually improve the in-person training as well. I still greatly prefer the in-person format (and the travel) but can definitely see us continuing to offer some online training even after in-person resumes.

Early this morning, I rode my regular pre-COVID commuting route out to UMBC and back, which I try to do every week or two. BGE has been replacing gas lines in Relay since late spring, and the workers have dug up and patched (literally) every single road in town. It’s still ongoing, but seems to be nearing completion. I suspect next spring will bring a massive repaving project. Should be nice once it’s all finally done, but in the meantime, I’m glad I don’t have to commute through there every day any more.

Two and a half years ago, I bought a new commuter bike, A Surly Disc Trucker. It served me well as a 3.5-season commuter bike, until I stopped commuting. Since then, it’s been my go-to bike for road riding, splitting duty with my venerable 2009 Masi single speed. Truth be told, it’s better suited for commuting and long-distance touring than it is for my typical 25-to-30-mile morning road rides. It’s quite the beast, with racks, lights, and full fenders, and it is a great rain bike. But, it’s heavy and kinda slow, and while I still ride in the rain occasionally, telecommuting has made it unnecessary, so I’ve been gravitating towards alternative ways to stay active on rainy days. Once I finally start going back to the office, it’ll be nice to use the Surly for its intended purpose again.



I don’t post much about work on my blog, unless you count the act of getting to and from work on my bike.  This past weekend, UMBC lost power for around 72 hours, and the IT support/admin guys in our area were scrambling around madly the entire weekend, almost 24/7, trying to keep key systems and infrastructure functioning so the University could continue to do business.  Having been a systems administrator for a good spell in the ’90s, I know firsthand what a thankless job it is.  Everyone takes computers and network infrastructure for granted, until it goes down.  When a systems admin does a good job, and everything is working normally, no one notices.  Admins rarely hear from anyone unless something is down or broken. Systems admins are kind of like the white-collar equivalent to the BGE guys who go around restoring power after an outage.  IT infrastructure has become as important as electricity: when it works, it’s taken for granted; when it doesn’t, the world grinds to a halt.

Back in my day, when we didn’t have things like whole-building generators, everything would have just gone down and stayed down during an extended power outage.  This past weekend, save for a few minor glitches, UMBC’s IT infrastructure stayed largely intact and functional.  That’s a testament both to the increased importance of our infrastructure vs. 20 years ago, and the herculean efforts of the support staff to keep everything running.

My role during all of this mess, was just to be available in case one of the services for which I serve as designated babysitter needed attention, as the admins shuffled around the physical hardware to deal with the power issues.  Again thanks to these guys, none of my stuff broke down, and everything pretty much worked as it always had.  If it weren’t for having an unexpected day off on Friday, and the text messages from our emergency alert system, I might not even have known that the power was out.  Remarkable.  If you see one of these guys, make sure to thank them and buy them a beverage of their choosing.

Calendar Pool Work

Saturday update

Got a start on winterizing the pool today, with occasional breaks to shoo Andrew off the pool cover.  I drained the water down below the tile line and added chlorine and algaecide.  The water was nice and clean even after a month of neglect.  Wonder if the algaecide I added last month helped.  Anyways, tomorrow I hope to get out earlier and get the bulk of the work done.  Not sure if I’ll get to blowing out the return lines.  We’ll see.

On the calendar front…  turns out Sunbird is not buggy after all as I had assumed yesterday.  Apple’s iCal exhibits similar behavior.  It appears that if I have events with RECURRENCE-ID properties, somewhere there needs to be an event that “defines” the recurrence with an RRULE or RDATE property.  Oracle Calendar’s output is missing this “defining” event.  I thought briefly about trying to “fix” the recurrences by adding RDATEs, etc. to the iCalendar output, but I think that’s more trouble than it’s worth.  I’m just going to try rewriting the recurring events as separate events, giving them unique IDs based on the start date of the event.  I’ll try it out Monday and see how it goes.

Calendar Work

Calendaring revisited

It’s been a year or so since I gave up on my home-grown calendar sync setup.  It was nice for awhile, then we upgraded our Oracle Calendar server, it broke, I tried to fix it and didn’t get very far, and that was the end of that.  Well, as it happens, there’s been some recent interest in an Oracle-calendar-to-iCalendar gateway at work, so I decided to drag my old stuff out and try again.  And it turns out, things have improved in a year’s time.  First off, the Oracle Calendar SDK seems to be more reliable.  I used to get lots of internal library errors, particularly when trying to download large chunks of calendar data.  But that doesn’t seem to be happening now (I know, famous last words).  And on top of that, the iCalendar output is much cleaner.  For example, recurring events are now properly tagged with RECURRENCE-ID properties, so recurrences “just work” now without any extra work on my part.  There are still a few little quirky things, but by and large, it’s a huge improvement.

Also improved is Sunbird, Mozilla’s standalone calendar app.  It’s still a little rough around the edges, but it seems much more robust than previous versions.  I’d eventually like to use Sunbird as my main calendaring app everywhere, because it’s cross-platform and it allows interactive editing of subscribed WebDAV calendars (unlike Apple’s iCal).  The only stumbling block is my old, crusty Palm PDA, which only syncs with iCal.  Much as I’ve liked the Palm PDAs I’ve used over the years, I’m wondering if it isn’t time to start thinking about something different.  It’d be great to have something with functionality similar to Sunbird’s, in a PDA form factor.  Never going to get that with something that relies on desktop sync.


Retro coding

’tis been awhile.. but I’m currently writing some code (the Student Parking Registration rewrite) that communicates directly with our system of record for SIS, the HP3000 mainframe. I haven’t done this for 6 or 7 years (although I’ve made tweaks here and there, this is the most I’ve done with it since 2000 or so). And I had forgotten how comically antiquated the whole process is. Now, I don’t write code on the HP (God forbid.. it’s all Cobol), but I do interact with a TCP/IP socket-based server that runs on the HP. And, I have to send data buffers over the socket in a format that the HP will understand. It’s remeniscent of FORTRAN, or Assembly Language, or something like it. The HP is very fussy about field width, positions of parameters within buffers, etc. If I’m off by a character, for example, subsequent fields all end up shifted over too far. Suffice it to say, it’s not much like the stuff I’m doing nowadays – Java, PHP, XML, etc. It’s quite nostalgic. It makes me want to go log into the VAX 4000 and run my old 4-bit assembly simulator.

Oh well.. back to work. I’d hate not to finish this, and have 13,000 students unable to be billed by Parking Services next fall. That might affect my next raise…


Kids are back

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.


Cisco VPN client for Linux

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.


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


    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
    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.


Parking Permits and EasiPipe hacking

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.


SGI, we hardly knew ye

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.

Geeky Stuff uPortal

Whew… what a day

Thursday was quite the day of triumphs and tribulations.

It all started out with a successful swap-out of my home Linux server. It had been running on an old, trusty-but-tired Dell P2-300mhz, and I upgraded it to a slightly-less-old Dell P3-450mhz (Linux is far from perfect, but it truly shines at getting new life out of old, scavenged hardware). The upgrade was as easy as: build a new kernel, shut the old box down, pull out all the boards and peripherals, put the stuff in the new box, and boot the new box up. The result was a home server with a 50% faster processor and an extra 256mb RAM (640mb total vs 384mb). Not earth shattering, but a noticeable improvement, and it was easy to do. The trick to doing is this to transplant as much of the “guts” from the old box to the new box as possible, so the hardware configuration stays mostly the same.

Next up was the launch of our new myUMBC portal, which so far has been very smooth, other than the usual little niggling problems that always pop up with these things. We had already been running uPortal in production for six months, and that experience definitely helped ease the transition. The centerpiece of this launch was a complete redesign of the UI, but behind the scenes we also upgraded the framework and layout manager. This gave us an opportunity to start out “clean” with a fresh set of database tables, and to redo a few things which were done sloppily with the initial launch (such as our PAGS group and channel hierarchies). It positions us very well for future releases and gives us a clean platform on which to build future improvements.

Of course, by Murphy’s Law, the air conditioning in ECS picked yesterday to go on the fritz. So the launch was a little sweaty, but it happened anyhow. When I left the office, the A/C was finally getting back to normal, and then I get home and our power goes out. It ended up being out for around 4 hours, from 7:30pm till 11:30pm. Not all that long, but it always seems like forever when it’s actually out, and it made for a pretty sweaty (and surly) day. And of course, BGE’s automated system never gave us an estimate of when the power would be restored, so Cathy packed up the kids to go sleep at her sister’s, and pulled out 2 minutes before the power came back on. Fortunately I was eventually able to get a decent night’s sleep. I must say I’m more than ready for this summer to end. This is the first truly miserable summer we’ve had since 2002, and I had forgotten just how bad 2002 was. Oh well… t-minus 7 weeks till the Outer Banks.