home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20692 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  5.1 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 10:33:50 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 90
  8. Distribution: world
  9. Message-ID: <1iou2eINN372@gap.caltech.edu>
  10. References: <1imh53INNg7a@gap.caltech.edu>,<208009@zl2tnm.gen.nz>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <208009@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
  15. >Calm down, Carl, you're hurting my ears.
  16.  
  17. Sorry about that.
  18.  
  19. >What's very important here is that there is a big difference between 
  20. >corrupt memory and a corrupt system disk.  In the former case, you shut 
  21. >down NOW and reboot.  When you come up, the problem has almost certainly
  22. >gone away, at least until next time.  
  23.  
  24. Well, *THAT* problem has gone away, but a memory corruption can cause
  25. corruption of the data on disk.
  26.  
  27. >If you have a live (if sick) system, you have a chance of finding out what
  28. >went wrong.  That is *very* important -- the glitch might have taken out
  29. >more than a part of the system disk, and you need the error log and stuff
  30. >to diagnose it.  You need to know what got stepped on so you can fix it.
  31.  
  32. Agreed.  That's one of the many uses of standalone BACKUP.  Shut the system
  33. down *NOW*, before you run the chance of rendering the disk unreadable.
  34.  
  35. >Most importantly, you ned the *choice* to be able to fix the problem as
  36. >soon as possible, or possibly effect a temporary repair to maintain 
  37. >production.
  38.  
  39. And how certain can you be that you've *REALLY* fixed the problem?  Sure, you
  40. can track down and repair the symptoms, but do you really want to trust a
  41. system that's been running for some time with either the system disk or memory
  42. corrupted?
  43.  
  44. >Sure, there are cases where you should shut down Right Now
  45. >and boot standalone backup, but in my experience (ignoring total failure,
  46. >in which case you don't have a choice) these are extremely rare.  A knee-
  47. >jerk "something's wrong, let's die" is the *wrong* way to deal with
  48. >discovery of disk problems.  There's not much you can do to diagnose a
  49. >disk problem from the >>> prompt, unless you feel like keying in disk
  50. >controller instructions by hand.
  51.  
  52. True.  I'm assuming that you've got at least two disks on the system.  Shut
  53. down, do a standalone BACKUP of the non-system disk, restore it from your last
  54. known good image BACKUP of the system disk, and THEN try to diagnose the
  55. problems with the system disk.
  56.  
  57. >It needs to be up to the system manager to decide how serious the problem
  58. >is.
  59.  
  60. And if the system manager isn't there 24 hours a day, 7 days a week, 52 weeks a
  61. year?  I once managed a 780 that had it's floating point processor fail.  At
  62. the time that happened, I was involved with some stuff that didn't use floating
  63. point.  It took a user who *WAS* doing lots of floating point work several
  64. hours and about a dozen crashes of his program with machine checks for him to
  65. decide to notify me of the problem.
  66.  
  67. >It needs to be possible for the system manager to make that decision. 
  68.  
  69. For sufficiently minor problems, yes;  once the problem gets severe enough, you
  70. don't want to risk having the corrupted system running any longer than it takes
  71. it to notice that it IS corrupted.
  72.  
  73. >In some cases it can be fixed quickly and simply.  Others are going to 
  74. >require that you kick the users off the system and get on with fixing it.
  75.  
  76. That's why not all BUGCHECKs are fatal.  Some are continuable.
  77.  
  78.  
  79. >> It might also result in two people writing to the same blocks allocated to two
  80. >> separate files.  Result:  Neither file is valid.  You mean to tell me that
  81. >> you've got customers who are so goddamned stupid they's stand for that sort of
  82. >> bullshit?
  83. >
  84. >No.  I have customers who consider me competant enough to make informed
  85. >decisions to provide them with the best possible service, including data
  86. >integrity, security and system availablility.  I would object quite strongly
  87. >to having that decision taken away from me by an overly paranoid exception
  88. >handler.  To me, it's far better to have a good exception reporting 
  89. >facility (and VMS has to have one of the better ones out there) that helps
  90. >me make that decision than it is to have the decision made for me.  
  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. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  98.  
  99. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  100. understanding of astronomy is purely at the amateur level (or below).  So
  101. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  102. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  103. hold me responsible for it, but my organization had nothing to do with it.
  104.