It’s been a busy week around here the past few days…
Solaris 10
On Sunday I did a clean install of Solaris 10 on our SunFire V880 (host to our Voyager system)…then rebuilt a RAID+1 array under Sun Management Console (replacing the older DiskSuite array that was home to Voyager before the O/S upgrade). It took about six hours, much 
of that time spent making a few backups across an NFS link to our XServe RAID array—just in case something went very wrong. I also pulled the Solaris 8 boot drive and replaced it with a new disc before installing Solaris 10 (not only to “reset” the MTBF clock on the machine’s boot drive but also to give me a plan “B” in case the install went sour). About the only problem I encountered was an “unreadable media” error when I put in disc 3 of 5. Went to sun.com and pulled down then burned a new ISO image of disc 3 and continued. The rest of the process went smoothly.
Made one interesting discovery which may or may not be news to more seasoned Solaris administrators. When I brought the machine up on Solaris 10 for the first time, I defined the “new” RAID+1 array under SMC using exactly the same disks and slices as my old DiskSuite array under Solaris 8. Once defined, I decided to try and mount the new metadevice (without building a new filesystem on it). Didn’t know if it would work and was prepared to do a “newfs” and copy my old data back. Didn’t have to do a thing—the new array mounted without a hitch and there was my “old” Voyager partition again.
Moments after I mounted the array, I noticed metastat reporting on the “resyncing” progress. I thought that was odd—why would an array need to resync if nothing had been done beyond mounting? Digging deeper, I discovered I had made a typo when defining the submirror—one of the 15GB slices I included was a hot spare in the old submirror and the original slice was now in the hot spare pool. Had I made that mistake with the primary side of the mirror I would have botched the “immaculate” recovery of data. Since it was the submirror, it just started resyncing itself to the master. Once again the computer was a lot smarter than the operator…
Today an engineer from Endeavor is doing an upgrade of the Voyager software on the server and from conversations we’ve had things are going well. The system should come back online sometime Tuesday. Once we’re sure the upgrade was successful, we spend a little time in client-server hell—updating PC-based clients across most of the staff computers in the library.
Update August 15 (Tuesday). Upgrade completed successfully and the web interface to our OPAC came up on the new server…with redirects from its previous home functioning as I’d hoped. -wg
LDAPtation
Some time back I posted a note about EZProxy and the problems we’ve been having with people who publish information on how to log into systems they’re not authorized to use. As an example, here’s a site in Shanghai that’s working hard to help their readers get cost-free access to information Mason and other universities are paying for:
Actually, it’s not just about getting access to restricted information. The fellow(s?) operating the site at ipopf are actually requiring users to send them a PayPal donation before gaining access to most of their site…so I guess they’re an aggregator of sorts. Here’s their forum:
To combat this sort of thing, today we changed the way EZProxy does authentication—tying it into the new LDAP server on campus. It’s not yet a perfect solution—the LDAP directory doesn’t contain enough information on each person to support really fine-grained access control—but it’s a start in the right direction. My hope is that by deploying a popular enterprise-wide application (our proxy server) that depends on the campus LDAP server, we’ll help put a bit of pressure on those offices responsible for fleshing out LDAP support.
I’m not trying to imply that building a robust LDAP service is an easy job—a university community turns out to be a tangled web of often poorly documented relationships—but if we don’t show a real need for someone doing the work, it will be tempting to keep putting it off.
And finally, today Dorothea upgraded our DSpace installation to the latest software release (1.4). There have been a few bumps but nothing more than you’d expect from an open source JAVA product with a relatively small developer base—one that we’ve chosen to run on a platform that very few sites appear to use (Mac OS X Server).
And it is only Monday…