Email Offline At the Home of Sendmail 179
BobJacobsen writes "The UC Berkeley email system has been either offline, or only providing limited access, for more than a week. How can the place where sendmail originated fall so far? The campus CIO gave an internal seminar (video, slides) where he discussed the incident, the response, and some of the history. Briefly, the growth of email clients was going to overwhelm the system eventually, but the crisis was advanced when a disk failure required a restart after some time offline. Not discussed is the long series of failures to identify and implement the replacement system (1, 2, 3, 4). Like the New York City Dept. of Education problem discussed yesterday, this is a failure of planning and management being discussed as a problem with (inflexible) technology. How can IT people solve things like this?"
Re:Telnet (Score:2, Interesting)
facebook also gives me an email address
When did this start happening? Does it actually interoperate with other email services?
IT cannot solve this (Score:2, Interesting)
it's like saying IT can do heart surgery or IT can provide pscyhological counseling to a trauma survivor. IT is IT, it is not management and it is not leadership. IT is IT.
of course, shit rolls downhill, and leaders nowdays are incompetent buffoons who gain their positions largely through bribery, kickbacks, extortion, and other 'features' endemic to societies where the rule-of-law breaks down thanks to a greedy, corrupt elite.
again, IT cannot fix that.
The failure is leadership, planning, budgeting... (Score:4, Interesting)
I've only heard from people on one side of this but the story that I hear is that in the past, many departments had their own IT, mail servers, web, etc. When the campus built its centralized computing services facility, there was great pressure on departments to move to the central system. There was some griping about the costs for central services often exceeding the internal costs the departments formerly had but there was, I'm told, much need to justify the expense of and to pay for the new center. I've heard that some departments have been able to resurrect their internal systems to get through the outage.
Perhaps someone with more inside knowledge than I have can fill in and/or correct information from both sides of the story.
That slideshow is pure management-spin right from the opening "look how complicated and difficult this is..." I love how the "solution" to a system that is soon to outstrip its capacity is to stop expanding (and, it appears, properly maintaining) said system and hope it doesn't implode before you can toss the potato to an external party (who can then take the blame). Guess I was never learned at that school of capacity "planning".
Re:Telnet (Score:4, Interesting)
When I was admining at a small college, we DID NOT provide email for students, only for staff. We ran a listServe (sympa) and if the students gave us their personal email address, and checked a box, they would be added to a mail list for every class automatically..
Any student that didn't have an email would be sent to the library, where they would be shown how to sign up for a hotmail, yahoo, or gmail account.
We had students thank us, since they have gone to other schools, and though it was silly to have to check yet another account, when they already had 3 or 4.
The ONLY reason colleges give out emails is because they have been doing it since before email was a common thing. There is no actual reason for it.. (but I have heard some neighboring colleges give very, very very good sounding arguments on why they needed to drop a few hundred grant on a SAN and exchange)
Re:Hate Being First .... (Score:4, Interesting)
As a mail administrator for a big system, I completely agree with you.
The biggest problem was that they had everything on a single SAN, so when they ran out of IOPs, there was no spare capacity anywhere, and nowhere to mitigate it to. I've had people try to sell me on putting all our systems on a SAN too "it's so simple to administrate. It has plenty of IOPs, see, look at these shiny numbers". Fine when it's empty and you're only hitting the battery backed cache.
Which is why we have hundreds of separate little disk sets managed with templated configurations rather than any single points of failure. I'm really glad to be there!