Today’s the day where we launch our new myUMBC web portal, essentially turning it loose on the unwashed masses and making the world (well, the campus at least) our big, happy beta-test community. As part of this, we’re kindly leaving the old portal around for awhile, because we anticipate stuff will be broken. The new portal will live at http://my.umbc.edu, which (for now) the old portal currently occupies. That means that if we want to keep the old portal running, we have to move it to an alternate URL.

Now, our old portal has been active since 1999, at its current URL. It’s a big, old, bloated beast, and it’s very happy staying where it is. Getting this thing moved is somewhat akin to booting a 35-year-old freeloading kid out of the house. That is, you can be sure it will resist.

In this case, it was a tedious matter of chasing down all the references to the portal’s top URL, and making sure it gets changed everywhere it needs to. Then restart, wonder why it doesn’t work, and determine that the web server no longer has read access to the Webauth cookie. Then fix logout (it’s absolutely mandatory, when making any change like this, that logout stops working. It’s like death and taxes).

Great news is, it appears to work now. Off to fix some other stuff.

Getting some strange behavior from FastCGI regarding signal handling..

Platform is SunOS 5.10 on Intel, Perl 5.8.6, mod_fastcgi version 0.67. Seems like the FastCGI accept routine is somehow blocking the delivery of signals. If I set a handler for SIGTERM, then call FCGI::accept(), the signal is ignored until the accept routine exits (which happens when a new request comes in). So basically, when I send SIGTERM to the process, it ignores the signal until I go to my browser and hit the app URL. Then, the signal handler is invoked.

The consequence of this is, basically, none of my shutdown scripts are working right, because they all work by sending SIGTERM to the FastCGI processes.

The really weird thing here is, if I don’t set a signal handler at all, the SIGTERM immediately terminates the process. It’s only when a handler is set, that I have problems. I’ve tried a couple ways of coding the FastCGI loop:

while (FCGI::accept() >= 0) { ... }

vs.

my $request = FCGI::Request();
while ($request->Accept() >= 0) { ... }

Same results with either method. I have no problems using an old-and-crusty version of FastCGI (0.49) on our old-and-crusty SGI hardware. I’ve glanced at the new code that does the accept, and there’s nothing there that looks like it’s holding or blocking signals. Could this be an OS thing? I dunno, but if I can’t fix it I’m going to have to come up with some kind of workaround to kill and restart the processes..

Today was lotsa fun. It started out with the National Student Clearinghouse. I decided to get a “real” development instance going where I could connect to them as a student, demo it to Academic Services, etc. I ended up wrestling with their stupid referrer-based security scheme again. I took my existing clearinghouse script, which was working fine, and added Webauth authentication to it. I figure I’ll have the script verify the user’s Webauth credentials, then do an LDAP query to get the student ID, then pass that to the remote site. That way, my local script will have some authentication built in. Well, that broke it. On the initial authentication attempt, Webauth adds a query parameter called WebAuthExtAction (which the client is supposed to decode, and use the result to set a cookie). Great, but that changes the HTTP Referrer string, which breaks the clearinghouse crap. Hey, but they changed their site so it actually tells you what’s going on now, rather than just booting you out. Have to at least give them props for that, it saved me some head-scratching. OK, first attempt at fixing this: I’ll check for a WebAuthExtAction parameter, and if it exists, I’ll append it to the initial referrer string that I send them. Nope, that makes the referrer string too long, and the clearinghouse code can’t deal with it. Second attempt: look for the WebAuthExtAction parameter, and if it’s there, redirect the browser back to the same script, omitting the parameter. Bloody convoluted, but it works. Fortunately, in production, we won’t have to deal with this, because the prod code will run from the same web server as the portal, and the user will always have valid creds when they come to the site. Aargh.

Then there was fun with myUMBC itself. In an attempt to speed things up on the myUMBC web server, I decided to redo the Webauth ticket-logout script that it was using, and make it part of the myUMBC app itself. That way, logouts will go to the FastCGI processes, reducing overhead (the script needs to connect to the database, among other things) and hopefully speeding the machine up. This actually worked OK eventually, but of course, it broke things at first. Turns out I was short-circuiting the FastCGI loop without resetting certain global variables, which of course is a big no-no. But, that was good for a few choice expletives.

When does Christmas break start again?

I’m working on redoing UMBC’s Online Schedule of Classes page. The current version is generated by a big, messy Perl script that reads the raw data uploaded from the HP3000, formats it, generates pages for all the individual disciplines, and then generates the top-level page (which contains links for each semester along with links to various informational pages). What’s the problem, you ask? Well, all of the HTML (except for a few PHP includes for headers, footers, and style info) is hardcoded into the Perl script. You can make modifications to the generated HTML pages, but they get immediately overwritten the next morning when the script runs to regenerate them. Any time someone needs a permanent change (which happens frequently, because the Academic Services folks are always tweaking their informational links, particularly during advance registration), it has to go through me. This is a hassle both for me, and for the folks who need the changes made.

The Perl script is old. It dates to 1996 or so. The model it uses is outdated. It needs to be rewritten so that the Academic Services folks can manage the content themselves. The whole thing is just begging to be rewritten in PHP or some other embedded language, but unfortunately I don’t have time (or staff) to sit down and make a major project out of this right now. So, for now I’ll settle for slow, incremental improvements.

My first tweak was to rework the script so that it uses PHP includes to read the auxiliary links for the top-level page. That way, the AS folks can manipulate auxiliary links themselves, and they will show up instantly (rather than having to wait until the script runs overnight). This is a quick win, and should eliminate the bulk of the busy-work I have been doing to support this. However, I’m not sure it’ll work perfectly, because the AS staff are using Dreamweaver to edit all of their HTML content, and I’m not sure if Dreamweaver can edit partial HTML files, or if it’ll try to add its own tags all over the place. As with everything around here, time will tell, and we’ll tweak things down the road as necessary.

Can I just say that I hate configuring passthrough authentication to outsourced sites on remote web servers?

Rule 1: The company’s step-by-step setup instructions will not apply to your particular system configuration.
Rule 2: It never works the first time.
Rule 3: See rule 2.
Rule 4: Debugging is impossible, because the error logs are on the remote site.

It’s kind of like playing pin-the-tail-on-the-donkey: Put on blindfold, spin around a few times, try some stuff, and maybe you can get it to work. If not, call the rep. The rep is invariably non-technical and will have to pass the request on to a developer. The developer may or may not get back to you with useful info. Or maybe an error log. Or something. Then, you try again.

Oh, and I forgot….
Rule 5: Once you eventually do get it working, it will work for awhile, then break at the most inconvenient time possible, when the vendor decides to make some change to the remote site without telling anyone. Thus, it becomes a perpetual maintenance-hassle-waiting-to-happen that hangs over your head for, well, forever.

I just, finally, got the passthrough authentication to work with the National Student Clearinghouse. Basically, their stuff works like this: Post several magic variables to their web server. Server sends back a form that includes an encrypted token. Form uses javascript to auto-post itself back to NSC web server, which brings up the student’s clearinghouse view.

To make a long story short: It’s very picky about the HTTP_REFERER. We gave them the URL of our development server ahead of time. In the initial request, the referrer string that the script sends must begin with the URL we provided to them. Fine, I can use LWP::UserAgent to post the initial request, and set the referrer to whatever I want. I was still missing one piece though: In the second request (the auto-post form which is sent to the browser), the referrer must exactly match the referrer that I sent in the first request. Of course, NSC’s documentation conveniently doesn’t mention this.

Example: If I give them ‘http://devel.umbc.edu’ as the development URL, then my initial referrer must begin with that. I can send ‘http://devel.umbc.edu/cgi-bin/blah.pl’ and it will accept that. On the second request, I have to send it exact the same referrer string as I did in the first request, or it won’t accept it, even if it matches the development URL. Got that?

I probably made this harder on myself than it needed to be, by trying to get cute and fudge the referrer header from a URL other than the development URL I gave them. But it’s a bit annoying to have to jump through these hoops to make the thing happy about the referrer, given that it’s a really bad idea to rely on the referrer for any kind of security purposes in the first place.

Oh well, let’s hope I don’t have to do this again for awhile.