OIT SysCore

In the interest of not destroying anything during the first couple days of the semester, it’s time to document one of the more complicated bits of our infrastructure here at UMBC – email delivery.

We had two service problems today which caused much headache. So much for a quiet friday...

bbss or "booboo" is now running SP1 for blackboard 6.3

Of course, that whole krb/tcp thing was a bit of a red herring. That *was* a problem, and I'm sure it didn't help. But, the real problem was within Sun's directory server.

Added server-side TLS on the mxin.umbc.edu machines. Encrypting mail is good, ya.

(now we just need to toss that out to all of the clients! :) )

www.umbc.edu can now serve content via https. Currently, access to https URLs will simply return a redirect back to the non-https content. Areas can be configured so that they accept https connections in the 'umbc_ssl.conf' configuration file (it's obvious, see examples...)

Update
Also enabled the php accellerator, which as installed, but never turned on for www.umbc.edu's sites.

The ListProc software on listproc.umbc.edu will be taken offline on the night of 9/11/2005 to rebuild its users database, a process which will take several hours.

Mailing lists will essentially be down during this period.

bfs6.afs.umbc.edu is online, with 2x 72G /vice partitions. This server is temporary, and will be removed from service once some more Sun V20z's arrive and we can move this stuff to our fabric-based storage.

(it was the old "hfs7", and was generally reliable)

Planning on making the following changes to the mxout (smtp.umbc.edu) server cluster.

• Enabling multiple queues based on intended delivery address; filtering stuff destined for the "central" OIT mail servers and stuff destined elsewhere


• Switching to using persistant queue runners. There will be two configurations; one for the "external" mail that takes advantage of host connection statistics, and one for the internal that doesn't.
  

This is a presentation given at a NERCOMP Identity Managment SIG regarding the basics of UMBC's SSN migration plans over the next year or so. It overly simplifies some things as to not get mired down into details, but the basic outline of the problem and intended solution is there.

As with everything posted on this blog, this is not official OIT communication. This was a presentation given as a case study, and not yet officially OIT's plans. Anything you read is subject to change without notice.

Go Go Powerpoint, Away!

This is our production uPortal environment, which contains both a production, and a pre-production test environment. (There are other instances that are not as, well, complicated that we do development work on)

The basics: Two sun v20z's behind a loadbalancer. Each instance (prod & test) run behind an apache server to handle static requests and SSL. Dynamic uPortal
content its proxyed to a loopback-only socket that Tomcat is listening on. For requests which require legacy MyUMBC functionality through a proxy'd uPortal channel, a connection is made back to the front-end Apache instance to a loopback-only socket which contains an instance of the legacy MyUMBC system running under FastCGI.

The uPortal instances (on both servers) run out of the trees:
/afs/umbc.edu/admin/www/portal/test and /afs/umbc.edu/admin/www/portal/prod. Each contains it's own copy of Tomcat, the JRE/JDK, and apache configs. Apache is currently running the uber-004 build, which is a slight variation of the 003 build tweaked to run on Solaris 10x86.