Busy and productive month

One of the challenges that George and I confronted soon after I arrived at UMass was how to provision computer services to students. At the time, the Biology Department had two servers -- a Sparc 10 and a Sparc 20, I think -- and all accounts were built at the comment line manually by George once on each server. The Intro Biology course was among the first that wanted to have accounts and, with a population of 700 - 800 it was going to require some automation.

A brief aside: when I described what we were doing to Jack Wilson, who was then the director of UMass Online, before he became president, he asked why accounts weren't being generated centrally and I explained that there were no central accounts that students could be depended on to have because the fees to support the technology services were optional and some significant fraction of students chose not to pay them. That meant that, as an instructor, if you wanted to be certain students would have a particular resource, you needed to build it yourself. We also didn't have any means of associating student usernames with individuals nor any standard way for us to check students' authentication either. But I digress.

George and I discussed what to do and drew up a plan to synchronize accounts between the two servers and to build student accounts only on the BCRC server. In order to avoid collisions with existing usernames, we added a digit based on the year of enrollment to the end of a username generated by munging first initial and last name together: the system would start out with sensible versions and then try various other permutations until it found one that was unique. Once a username was assigned to a student, they would get the same username from then on. George could then script building accounts and I mostly used imap to let students authenticate against the system.

A key challenge was resetting passwords. We chose to set students' initial passwords to their student number. I wrote a password changing script that used poppassd and we encouraged students to change their password. If a student forgot their password, I would reset it based on email from their @student account or if they visited my office with ID. The whole system was not perfect, but it worked reasonably well.

When we started using smb authentication for shared file space and printing, we had to start setting smbpasswords at the same time as unix passwords. Then, we added a new server in the ISB that needed to have some accounts replicated. Then we started building replacement servers for the Department and BCRC. At that point, I finally prevailed on George that we needed to have a central authentication system to bring some sanity to passwords. It was a constant problem for people to try to figure out which system they were authenticating against to debug problems: "Let's see... This is your smb on wahoo which should be the same as your SMB password on marlin, which might be the same as your email password, but might be different."

Last spring I set up ldap for the first time and we ran a pilot project in the ISB. We built all our usual accounts, but set samba on wahoo to authenticate against ldap. The original plan had been to merge our account generation stuff for undergraduates with the similar efforts in Chemistry. We share so many students and have shared resources in the ISB that it makes sense to merge how we provide authentication. Their system wasn't ready in time to use for last Spring, so we ran our pilot project. Then we were supposed to merge our systems over the summer, but we found at the last minute that we couldn't use their set up (because they hadn't built ldap with crypt or turned on the apple ldap schema we were using), so we postponed and reused the pilot work from the spring. I had hoped to make the merge happen over intersession, but there was another fly in the ointment.

While we had been using the student number as a password, Chemistry had been using it as a username. During security discussions with OIT, they indicated that we probably shouldn't be using the student number at all -- but especially not as the username. OIT does now provide accounts to all students now and furthermore they were willing to give us rosters with student usernames and to open a means for us to check student authentication for the purpose of setting the same username with either the same or different password at the student's choice for our use.

Over break, I set up a new authentication server for ongoing ldap services and build a password setting script that let's students authenticate using pubcookie and sets our ldap password. I had hoped to get the structure consistent with Chemistry but we couldn't get a response from them in time, so we just went forward with the same structure we'd been using for our pilot project. But we also migrated all of our permanent accounts into the system, rebuilt the account generation scripts to use the new roster format (which includes the NetID), modified everything to point at the new ldap server, and built 3750 student accouts. So far, the system is providing authentication for samba file service and printing on two servers, our print-release system, and duck.

There's still more to do: we still have to get shell service on the servers to use the authentication system, and I'm planning that we'll also use it for our course websites and, little by little, pretty much everything else. If we can ever get on the same page with Chemistry, we'll have to go back and tweak everything to use a different DN. Hopefully, we can do that over the summer. But we've made substantial progress in a very short time.