5 lines
125 KiB
Markdown
5 lines
125 KiB
Markdown
|
[Source](http://www.yak.net/carmen/unix_horror_stories "Permalink to ")
|
||
|
|
|
||
|
|
From: ani0349@cs.rit.edu (Anatoly N Ivasyuk) Date: 1 Mar 93 04:54:06 GMT Newsgroups: comp.unix.admin Subject: Unix Administration Horror Stories!!! (part 1 of 4) ============================================================================ The Unofficial Unix Administration Horror Story Summary, version 1.1 \---------------------------------------------------------------------------- compiled by: Anatoly Ivasyuk (anatoly@nick.csh.rit.edu) ============================================================================ Introduction \------------ This is version 1.1 of "The Unofficial Unix Administration Horror Story Summary". I put this together for two reasons: 1) Some of these stories are damn amusing. 2) Many people can learn many things about what *not* to do when they're in charge of a system. As rickf@pmafire.inel.gov (Rick Furniss) puts it: "More systems have been wiped out by admins than any hacker could do in a lifetime." This is not an FAQ, but more like the questions that *should* have been asked (and answered). There are success stories, and... well... other stories. I'm certain that everyone can learn something from reading these stories. The organization of the Summary has been changed quite a bit (maybe I should bump the version number up to 2.0?). Instead of leaving the stories in more or less chronological order of the postings, they have been separated into sections. There are currently sections for all different types of stories, and a brief table of contents to go along with it. Any new stories that I have received since version 1.0 of the Summary have been integrated with the rest of the stories, but usually appear at the end of their respective sections. The new stories are marked by '*NEW*'. The miscellaneous section is a little large, but I had no idea where to stick those stories. If anyone cares to suggest a place, or comes up with a new section, let me know. Submitting stories \------------------ If there are additional stories that anyone wants to submit, I'll be glad to add them to the Summary . Send them to me at: anatoly@nick.csh.rit.edu. About posting the stories \------------------------- This is probably the last time that the stories will be posted to USENET in their entirety. However, I do plan to make updates more frequent as more stories roll in. Further announcements of updates to the horror stories will be posted to the comp.unix.admin newsgroup, but the horror stories will themselves be available through an ftp site or ftpmail. Initially, the stories will be available for ftp at sunsite.unc.edu. Thanks to jem@sunsite.unc.edu for letting me put them there. They will probably appear within the next few days. They will probably be in /pub/docs/humor or /pub/archives/comp.unix.admin. More ftp sites may follow. How to get the stories through ftpmail: \--------------------------------------- There are a few sites that provide ftp services by mail for those people who don't have ftp access. To find out more, mail one of the following locations with a subject header 'help': ftpmail@decwrl.dec.com ftpmail@sunsite.unc.edu As always, send more stories! -Anatoly Ivasyuk \----------------------------------------------------------------------------- The posting that started it all: \-------------------------------- aras@multix.no (Arne Asplem) wrote: > I'm the program chair for a one day conference on Unix system > administration in Oslo in 3 weeks, including topics like network > management, system admininistration tools, integration, print/file-servers, > securitym, etc. > I'm looking for actual horror stories of what have gone wrong because > of bad system administration, as an early morning wakeup. > I'll summarise to the net if there is any interest. > -- Arne \----------------------------------------------------------------------------- Table of Contents: \------------------ Section 1) Creative uses of rm(1) 2) How not to free up space on your drive 3) Dealing with /dev files 4) Making backups 5) Blaming it on the hardware 6) Partitioning the drives 7) Configuring the system 8) Upgrading the s
|
||
|
|
|