home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20698 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  5.1 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!wupost!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don
  2. From: don@zl2tnm.gen.nz (Don Stokes)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: HELP!!! Security problem for gurus. [Directories]
  5. Message-ID: <86009@zl2tnm.gen.nz>
  6. Date: 10 Jan 93 13:45:01 GMT
  7. References: <1iou2eINN372@gap.caltech.edu>
  8. Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.)
  9. Organization: The Wolery
  10. Lines: 91
  11.  
  12. carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
  13. > Agreed.  That's one of the many uses of standalone BACKUP.  Shut the system
  14. > down *NOW*, before you run the chance of rendering the disk unreadable.
  15.  
  16. Not necessarily.  It's still running.  Start looking.  SHOW ERROR.  Run
  17. Did a file get overwritten?  When?  What's running that might have done it?  
  18. Is the disk structure intact?  ANALYZE/DISK.  We need to know now.  Time
  19. is money.
  20.  
  21. I've already outlined a case where the very act of shutting down was one
  22. of the causes of the problem.  You're advocating taking an action before 
  23. diagnosing the problem.  If it looks serious, I can at least stabilise 
  24. things by chucking the users off and stopping queues.  If it's really bad
  25. I'm going to have to restore from backup anyway.
  26.  
  27. > And how certain can you be that you've *REALLY* fixed the problem?  Sure, you
  28. > can track down and repair the symptoms, but do you really want to trust a
  29. > system that's been running for some time with either the system disk or memory
  30. > corrupted?
  31.  
  32. If you can find a cause, you can often find the effect.  If in doubt,
  33. restore.  But no bugcheck handler can ever make that decision for you
  34. reliably.
  35.  
  36. > True.  I'm assuming that you've got at least two disks on the system.  Shut
  37. > down, do a standalone BACKUP of the non-system disk, restore it from your last
  38. > known good image BACKUP of the system disk, and THEN try to diagnose the
  39. > problems with the system disk.
  40.  
  41. ... yeah, you get to find out, three hours and many thousand $ of lost
  42. production time later, that you accidentally deleted a non-critical file
  43. and could have fixed the problem in less than two minutes.  I'd rather
  44. you explained that to the CEO.
  45.  
  46. > And if the system manager isn't there 24 hours a day, 7 days a week, 52 weeks a
  47. > year?  I once managed a 780 that had it's floating point processor fail.  At
  48. > the time that happened, I was involved with some stuff that didn't use floating
  49. > point.  It took a user who *WAS* doing lots of floating point work several
  50. > hours and about a dozen crashes of his program with machine checks for him to
  51. > decide to notify me of the problem.
  52.  
  53. Sites that care about their production have people available.  I've
  54. crawled out of bed in the wee smalls more times than I care to count to
  55. attend to sick systems (usually hardware problems).  Operators were 
  56. instructed that if they didn't know what to do, they were to call; they'd
  57. get a far bigger blasting if they didn't than the odd curse they'd get for
  58. digging me out unnecessarily.  Incidentally, these are the same folks you
  59. accused of being "so goddamned stupid" in your previous message....
  60.  
  61. > >It needs to be possible for the system manager to make that decision. 
  62. > 
  63. > For sufficiently minor problems, yes;  once the problem gets severe enough, you
  64. > don't want to risk having the corrupted system running any longer than it takes
  65. > it to notice that it IS corrupted.
  66.  
  67. The nature of bugcheck code is that it must be simpleminded.  
  68.  
  69. Taking an action that may be destructive (and rebooting onto a sick system
  70. disk is a Bad Thing), may render a recoverable situation unrecoverable,
  71. or even just increases the downtime required to fix the problem, is not
  72. an appropriate response.  
  73.  
  74. The correct response is to make it very clear to all who might be in a
  75. position to fix it that there is a problem.  Software systems that cannot
  76. continue because of the problem should stop, but as far as possible it
  77. should be up to something with a brain to sort out what happens next.
  78.  
  79. > That's why not all BUGCHECKs are fatal.  Some are continuable.
  80.  
  81. Bugchecks come in two varieties: those that blow the system out of the
  82. water and those that don't.  The latter type get logged to the error
  83. log, and that's about it; otherwise they look like normal exceptions to
  84. the average user.  If you're not watching the error log, you'll never
  85. know one happened.
  86.  
  87. Personally, I'm rather a fan of things like VAXsim which will take action
  88. to notify you when something (usually hardware) goes amis.  Back at that
  89. printing co I had it automatically email me at home....  (I even got a
  90. notification of a dead disk after I left the company.... 8-)
  91.  
  92. > Fine.  Then perhaps we're simply arguing about just how severe the problem must
  93. > be before the system takes matters out of our hands.  It might be useful if VMS
  94. > had more than two classes of BUGCHECKS, and allowed the system manager to set a
  95. > SYSGEN parameter that specified the lowest class that was considered fatal.
  96.  
  97. Maybe, maybe not.  I like how it is.
  98.  
  99. --
  100. Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
  101. Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
  102. Victoria University of Wellington, New Zealand              +64-4-495-5052
  103.