Sun Feb 8 19:09:02 PST 1998 — Sonic now offers technical support on weekends. Our new expanded support hours are 9am to 9pm, seven days a week. We hope that this makes the Internet even more useful for you. -Dane, Eli and the support staff

Sun Feb 8 19:06:31 PST 1998 — We’ve just added three new disks to our Network Appliance filer. Two of these are currently warm spares, and one has been added to the RAID array. Current storage in the filer is about 25 gigs, 76% full. Because of the NetApp’s hot swap capabilities, there was zero downtime during this upgrade. -Dane

Sat Feb 7 10:07:47 PST 1998 — New authentication server online. The authentication server checks passwords. In most cases, when someone (say, Ann) presents a password to one of our servers, that server doesn’t have any idea what Ann’s password looks like.

Instead, the server encrypts the password and passes it to our auth server. The auth server inspects the password and returns a ‘yes’ or ‘no’ response — if the response is ‘yes,’ Ann can retrieve her popmail (or log into her FrontPage web, or transfer files to the FTP server, or what have you.) We find this security model very attractive, because it means we can store passwords on specially protected hosts.

But there is a problem — as we load up our auth server with more and more authentication tasks, Ann discovers that it takes her longer and longer to retrieve her popmail, or log into the shell host, or connect to our network. Clearly, we need a very fast authentication server. Since June, Dane and I have been working on one — and that’s what we’ve deployed this morning: a very fast authentication server. If you’re interested in the details, please visit news:sonic.programmer. -Scott

Sat Feb 7 04:01:05 PST 1998 — I’m testing our new authentication server — folks may notice strangeness with logins for the next hour or two. (Problems should be very rare — less than one failure every 10 minutes. -Scott

Fri Feb 6 18:34:31 PST 1998 — I spent yesterday evening babysitting the hunt group in an effort to find out if we had bad equipment or bad phone lines which were causing fast busy signals. We worked with Pacific Bell to isolate an improperly configured line which was causing users to get an error recording or fast busy signal instead of getting online. We’ve fixed it, and things are looking great here. I hope that this signals the end of our string of telco and equipment problems. Here’s a brief summary: Bad PacBell switch setup of series completion hunting was limited to a small number of lines, so 92 ports were unavailable to customers. Fixed January 13th. Bad USR implimentation of DMS custom switch protocol caused caller-ID blocked originators to get a fast busy signal. Fixed February 4th. Bad PacBell switch setup of BRI to PRI hunt group bridging was not allowing users to reach all of our equipment. 92 new ports were unavailable to customers. Fixed February 6th.

Thanks for standing by us as we worked out these issues! We’re still working on ‘Unable to negotate a compatable set of network protocols’ with the Intelliserver gear, and with some intermittant problems with authentication. -Dane and everyone else!

Fri Feb 6 18:33:00 PST 1998 — Our air conditioning upgrade went very well. The new unit has more than enough capacity for our current heat load, and is working great. We’ve got some photos of the crane lift, and we’ll work on getting those online.

Thu Feb 5 11:53:44 PST 1998 — We’ve had a brief power outage here, and some users connections were terminated. We’re working on a new power plant, but until PG&E and the electrical folks are finished, we’ve got five terminal servers and some modems which are not on protected power. The new power plant upgrade gives us lots of room to grow, plus uninterruptable power for all facilities including air conditioning. Speaking of air conditioning, we are working today on an AC upgrade. We’re replacing an aging 3 ton Carrier unit with a new 5 ton Trane. A massive crane was here at 6AM putting it all on the roof, and they’re still working on hooking it all up. We’re keeping cool, so there’s no worries about overheating currently. This upgrade is what caused the power outage. A loose screw on the power panel bus under the new AC units new breaker caused a short circuit which tripped the facility’s main circuit breaker. To make things even more exciting, Trane shipped us a 3 ton unit instead of a 5 ton, and the installation folks didn’t realize this until it was already partially installed. We’ll have the big crane back here tommorow, and we’ll do the whole thing over again with another unit. It’s been an interesting morning. -Dane

Thu Feb 5 22:21:40 PST 1998 — At 5am Friday morning we’ll be here with the crane again putting up the new Trane 5 ton air conditioner. See earlier MOTD entries for for info on this upgrade. -Dane

Thu Feb 5 22:17:07 PST 1998 — We again spent a large amount of time this evening returning fast busy (reorder) tones to customers. I’ve opened up a new repair ticket with PacBell, and I think we’ve isolated one small configuration problem which is having a big effect. The details: When the analog hunt group (522-1001) fills up, it’s supposed to forward on to the X2 hunt group (522-1002). When the X2 gear fills up, it’s supposed to forward on to our new PRI gear (522-1003). When the PRI gear was deployed last week, we tested the last X2 number (547-3309) and it did indeed reach the PRI equipment if it was busy. Great! However, we found tonight that when the number before that (547-3308) is busy, users get a reorder tone! It sounds like there is something wrong with the way that 3308 is configured, and Fred at PacBell is working on it right now. We’ll keep you posted. Meanwhile, if you’re frustrated with all the reorder tones, you can dial 522-1003 and you should have no troubles. -Dane

Thu Feb 5 22:00:08 PST 1998 — News services were in a deferred posting mode for a few hours this evening while we made minor repairs on the spool filesystem. This goes back to the crash we had at 14:47 today. All posts which users make when we’re in a mode like this are injected into the Usenet system as soon as the filesystem are offline, so both posting and reading behaves the way it should. -Dane