home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20704 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  4.4 KB
  1. Path: sparky!uunet!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: HELP!!! Security problem for gurus. [Directories]
  5. Date: 10 Jan 1993 22:39:46 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 75
  8. Distribution: world
  9. Message-ID: <1iq8jiINNb7n@gap.caltech.edu>
  10. References: <1iou2eINN372@gap.caltech.edu>,<86009@zl2tnm.gen.nz>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <86009@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
  15. >carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
  16. >> Agreed.  That's one of the many uses of standalone BACKUP.  Shut the system
  17. >> down *NOW*, before you run the chance of rendering the disk unreadable.
  18. >
  19. >Not necessarily.  It's still running.  Start looking.  SHOW ERROR.  Run
  20. >Did a file get overwritten?  When?  What's running that might have done it?  
  21. >Is the disk structure intact?  ANALYZE/DISK.  We need to know now.  Time
  22. >is money.
  23.  
  24. All of these things can be found after a crash, provided the system disk hasn't
  25. been corrupted beyond the ability of VERIFY to deal with it, and provided
  26. you've got a dumpfile on the disk.  Please note the code that writes the dump
  27. file is in an entirely separate thread from the normal disk XQP, so there's a
  28. good chance the dump file will be valid even if the XQP is somehow hosed.
  29.  
  30. >I've already outlined a case where the very act of shutting down was one
  31. >of the causes of the problem.  You're advocating taking an action before 
  32. >diagnosing the problem.  If it looks serious, I can at least stabilise 
  33. >things by chucking the users off and stopping queues.  If it's really bad
  34. >I'm going to have to restore from backup anyway.
  35.  
  36. And if it's something that is continuing to corrupt the system disk, the longer
  37. you fool around trying to diagnose the problem while running the corrupted
  38. system, the more likely the system disk will become too corrupted for you to
  39. ever successfully diagnose the problem.
  40.  
  41.  
  42. >... yeah, you get to find out, three hours and many thousand $ of lost
  43. >production time later, that you accidentally deleted a non-critical file
  44. >and could have fixed the problem in less than two minutes.  I'd rather
  45. >you explained that to the CEO.
  46.  
  47. Perhaps you can tell me which facility bugchecks because "you accidentally
  48. deleted a non-critical file?"  I'd appreciate it if you'd argue about the way
  49. things actually work rather than against straw men of your own devising.
  50.  
  51. >Sites that care about their production have people available.  I've
  52. >crawled out of bed in the wee smalls more times than I care to count to
  53. >attend to sick systems (usually hardware problems).  Operators were 
  54. >instructed that if they didn't know what to do, they were to call; they'd
  55. >get a far bigger blasting if they didn't than the odd curse they'd get for
  56. >digging me out unnecessarily.
  57.  
  58. I'm also available 24 hours a day.  But I'm not on site all that time.  It can
  59. take up to half an hour for me to get to the computer.  A lot can happen in
  60. half an hour.
  61.  
  62.  
  63. >The nature of bugcheck code is that it must be simpleminded.  
  64. >
  65. >Taking an action that may be destructive (and rebooting onto a sick system
  66. >disk is a Bad Thing), may render a recoverable situation unrecoverable,
  67. >or even just increases the downtime required to fix the problem, is not
  68. >an appropriate response.  
  69.  
  70. Who said anything about "rebooting onto a sick system disk"?  Whether or not
  71. that happens automatically is controlled by the SYSGEN parameter BUGREBOOT
  72.  
  73. >> Fine.  Then perhaps we're simply arguing about just how severe the problem must
  74. >> be before the system takes matters out of our hands.  It might be useful if VMS
  75. >> had more than two classes of BUGCHECKS, and allowed the system manager to set a
  76. >> SYSGEN parameter that specified the lowest class that was considered fatal.
  77. >
  78. >Maybe, maybe not.  I like how it is.
  79.  
  80. Then why are you bitching about it?
  81. --------------------------------------------------------------------------------
  82. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  83.  
  84. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  85. understanding of astronomy is purely at the amateur level (or below).  So
  86. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  87. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  88. hold me responsible for it, but my organization had nothing to do with it.
  89.