I compiled and installed a new kernel for HEIWA to bump up the amount of memory dedicated to networking.

Periodically we'd been getting "Mbuf cluster allocation failed" kernel messages and networking would hang for a couple of minutes. HEIWA is running FreeBSD 4.4, prior to the introduction of dynamically sized kernel parameters. I increased maxusers to 256 and set NMBCLUSTERS to 32768. We should see better performance out of this now.

Periodically run netstat -m to see what the network memory statistics look like. Previously we'd maxed out on mbufs and mbuf clusters and had gotten a large number of requests denied and a smaller number delayed. We should see no requests denied or delayed and we shouldn't ever have a peak buffer or cluster usage that hits the max.

The Sola 5000 UPS blew some circuitry this morning, prompting a repair call and moving the upgrade up.

This looks similar to the problem it had shortly after installation when some circuitry blew out. The repair technician has ordered replacement parts for express delivery to Dayton tomorrow morning. While he's here doing the repair, he'll also install the 12 KVA upgrade module. We'll still need to schedule downtime to install the maintenance bypass switch as planned.

The replacement drive for the CD server arrived and was swapped.

Apparently drive 6 is the middle slot on the left drive cage. I'm guessing that the configuration in the drive cages is something like this:

|5-6-7|8-0-0|

(where the farthest on the right labeled with 0s are unoccupied).

I originally replaced the drive in what I labeled slot 7, and it then claimed that both 6 and 7 had failed. Since the RAID array is made up of drives 5 through 8, I'm guessing that the above configuration is correct (it doesn't seem to make sense that 5 and 8 would be swapped).

The system is currently rebuilding the array and will continue to do so until tomorrow sometime.

The air conditioning went out around 2 AM this morning, and around 8 one of the drives on the CD server failed due to the heat. We have a replacement being shipped to us for delivery tomorrow.

The ambient temperature was about 95 this morning, and that cooked drive 6 on the CD server (farthest right drive in the left drive cage). A call to MDI tech support (1-800-228-0891) netted one replacement drive being express delivered to us. We should be able to swap the drive and have it rebuild by Friday.

I've done some more testing of OpenLDAP, and have found that FreeBSD's lack of a flexible name switching service might be a significant limitation in LDAP's usefulness.

FreeBSD 4's limited PAM support presents additional problems. While a pam_ldap module does exist and can be used to authenticate most services, programs such as passwd(1) do not have PAM support, and cannot authenticate against or change password information in an LDAP directory.

FreeBSD 5 has somewhat better support for LDAP. passwd(1) has LDAP support, but there still is no name support for LDAP, so UIDs and GIDs cannot be mapped to usernames after authentication. What this means is that while LDAP can be used to login (authentication), it cannot be used to determine ownership of files (authorization).

These limitations could be worked around by creating a set of scripts to synchronize an NIS map with an LDAP directory, and have authorization functions go over NIS rather than LDAP. Since passwords are only required during authentication, no password information need be stored in the NIS map, which would significantly improve its security.

Red Hat Linux has complete support for LDAP. With the nss_ldap package from PADL, LDAP can be listed in the nsswitch.conf(5) file, in the same manner that NIS and other name lookup facilities are presently. Presumably other Linuxes, System V-based Unixes such as HP-UX, and commercial BSDs such as AIX have similar methods of adding LDAP support.