Apparently Japanese language Internet Explorer (I believe) is unhappy with SquirrelMail 1.4.0, so I made the old version (1.2.9) available under the /squirrelold URL.

Some students in Japan complained that they were getting blank pages upon initial connection to the SquirrelMail login page. This corresponded with the introduction of 1.4.0, so after determining that it was the Japanese browser and that I couldn't really debug it at present, I enabled the /squirrelold URL (primarily accessible from the root webmail server page). Reports are that this works.

I replaced the hubs forming the private server network with a Summit 24e switch.

The Summit is reclaimed from one of the dorms after replacing the dorm hub and switch hardware with Dell switches. The private net is now fully 100Mbps switched using good hardware.

We upgraded SquirrelMail to 1.4.0 on Monday morning.

Ian Kelly did most of the work getting the new version ready to go and making sure plugins were compatible. On Monday we found a bug in the HTML code for the mailbox list which made Squirrel unusable on Netscape 4.7. A patch had been submitted to the developers list but was not in CVS, so I copied it to our installation. We may need to watch for that when we upgrade.

I set the Vexira updater daemon to update itself every two hours.

With a recent release of a new virus that got through during the time between updates, I decided that having more frequent updates on the mail server was important. The Windows 2000 updates on MIR are still daily.

I set the connection timeout parameter to 0 to disable connection timeouts on the server.

This seems to have been the cause of all the connection "closed error 11 (Resource temporarily unavailable)" errors, which were in turn probably the cause of MacOS X boxes not being able to authenticate properly. The previous setting was 10 seconds, and the average idle time for connections that ended with this error was between 9 and 10 seconds (sometimes greater than that, but if we're talking about an alarm that a thread sets, then it could very well be greater, or it could also be that some sort of keepalive traffic had been sent but not logged in the access log).

Tue Jun 17 14:20

We haven't had any more errors in the LDAP logs and MacOS X logons are working consistently now.

slapd, the LDAP daemon on ASHTI, has now died twice unexpectedly. I have written a short script to make sure that its PID is still present in /proc every minute and to restart it if not.