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.

Now that we’ve entered the brave new world of SSN remediation, it’s time to think about taking another step with myUMBC: We should stop using HP-ID as the primary key for legacy session management, and use UMBC Campus ID instead. Here’s why…

All of our web proxy channels which use the old portal as a back end, rely on the legacy code for session management and authentication. These channels, by design, often contain content above and beyond stuff that involves SIS. However, they rely on the SIS database, and the presence of an HP-ID, to work. Only a subset of people at UMBC have HP-IDs (at last count, there were 280,645 people in our directory, of which 274,244 had HP-IDs). People without HP-IDs have issues rendering these channels and taking full advantage of the portal. To get around this, I generate “bogus” HP-IDs for these folks to use as a primary key in the session management table. That makes things “sort of” work for them, but there are still problems — for one, the link ACL stuff in the legacy portal doesn’t fully work because it does LDAP queries against the HP-ID.

How do we address this? Well, the ultimate answer is to stop using HP-IDs as the primary key, and switch to campus IDs. On the surface, this seems easy. However, it’s actually a huge can of worms, because of sloppy development in the past. Rather than doing any code-sharing back then, our developers all wrote (or cut-and-pasted) their own code to manipulate the session table. As a result, we have 5,000 (slight exaggeration) apps that will each need to be updated to the new scheme. We’re paying now for cutting corners then.

I guess I should look at this as an opportunity to clean up some of this old code and get all the apps using a single library. But, that takes time, which means that this won’t be happening right away. In the meantime, I guess we’ll continue to limp along and deal with the no-HP-ID users as best we can.

I’ve just discovered Oracle SQL Developer, and it looks like it’s going to really make my life easier. I’ve been using an old, crusty version of SQL Navigator for my SQL visualization needs, and it’s always worked, but I’ve never been crazy about it. For one, the UI is very klunky — the mouse wheel doesn’t work, and it doesn’t auto-scroll when I expand collapsible lists. So I end up doing a lot of click-and-drag scrolling, which is annoying (keep in mind this is a really old version of the software; hopefully these issues have been resolved in more recent releases). And, the software is Windows-only, so I have to remote desktop into my Windows box to run it. This gives it a cramped feel, because the remote desktop has a lower resolution than my main display, and I can’t resize it to be as big as I want. And last but not least, our firewall requires me to run it over a VPN connection, and the VPN kicks me off after 12 hours, fubaring my connections and requiring me to restart it daily. Extremely annoying.

Enter SQL Developer. It looks promising. It runs on Windows, Linux and Mac. The GUI is much slicker than the version of SQL Navigator I was running. At the same time, Rob gave me the tip to run it over an SSH tunnel to a machine on the DB server’s trusted network, which means I can bypass the VPN. Wins on all counts.

Installation was straightforward, after I figured out how to point it at the correct JDK. It requires Sun’s JDK1.5, but it initially was ignoring my JAVA_HOME environment variable and using an older version. I poked around the initialization script and found that it was using the directory search path to find the JVM. I added the JDK1.5 bin directory as the first thing in my search path, and then it worked. Then I set up the SSH tunnel:

ssh trusted-host.umbc.edu -L 1522:oracle.server.umbc.edu:1522

After that, I was up and running. It looks great. Stay tuned for further impressions.

Woo-hoo! SSN Remediation happened over the past weekend, and we’re back up and running. I really think this is going to be a big win over the long term.

On the myUMBC side of things, there wasn’t much I needed to do. Just update my code in two places (one on the uPortal side, and another on the legacy Perl side) to go after the new “HP-ID” instead of the SSN. Then there were a few minor tweaks to some wording and input fields, and that was that.

This morning we brought all of our services back online, and turned them back loose on the masses. There were a couple hiccups:

1. It broke PlacePro (I guess the real question here is, what doesn’t break PlacePro). Quick fix: a couple extra lines of code to pass the real SSN to PlacePro, rather than the HP-ID. Since we’re abandoning PlacePro in favor of another vendor, I doubt we’ll undertake a wholesale remediation effort with them; we’ll just cut over later this summer, and then have them wipe their database.I thought that the National Student Clearinghouse stuff would be similarly broken, but it turns out I implemented that totally separately and it appears not to be affected.
2. I missed a couple places in the code where I was explicitly going after the socialSecurityNumber LDAP attribute, which broke a couple of things in minor ways. Another quick fix.

Other than that, things have been relatively quiet, and I’m just sitting around here waiting for the axe to fall. Keeping my fingers crossed..

I should have seen the writing on the wall 5 years ago..

I’m busy fixing the online Student Parking Registration app, which has been sorta broken ever since the uPortal launch. Student Parking is a unique application. It’s the only app we have here that:

• Communicates directly with the HP3000 mainframe via TCP sockets, and
• Is not part of the monolithic ‘myUMBC’ Perl codebase.

Combine these two, and you get “never-ending headache”. Five years ago, when the app was written, I had vague misgivings about it being developed this way, but due to a combination of laziness and busy-ness, I didn’t say anything about it. So it went up, ran for five years, and broke with the new portal. And now, I’m stuck doing what should have been done with it from the start: I’m essentially rewriting it and building it into the myUMBC Perl codebase. Once that’s done, it’ll be reliable, it’ll have better error handling, it’ll deal with mandatory PIN changes, it’ll have a UI consistent with the rest of the myUMBC SIS functions, etc. etc. In a nutshell, it’ll work the way it’s supposed to, and I’ll be able to stop treating it like some high-maintenance colicky infant.

It doesn’t help that there are like 10 copies of the code floating around in various places, either. Half the fun was tracking down the version that was actually running in production…