BOLTHOUSE%MCOPN1@eg.ti.COM.UUCP (06/09/87)
Re: the magical patch. I have several systems which can't afford to reboot often. We were hoping to apply the patch at a reasonable time; i.e., when the machines were down anyway, say, for standalone backups. Now that it has been published, I know of several info-vax readers at our site who are intelligent enough to deduce how to get around things. This means I have to reboot these systems *before* they do. Most of them won't bother, but one can't be sure... Our manufacturing customers will undoubtedly give you hearty thanks. I will don my suit of armor for the time when, shortly after the required reboot, they wish to skewer me... david l. bolthouse texas instruments defense electronics information systems VAX system support mckinney, texas no phone number this time... internet: bolthouse%mcopn1@ti-eg.com
VORBRUEG@DBNPIB5.BITNET (06/13/87)
* FLAME ON * Now, do you read this list or not? I can remember it being stated at least once that this patch does *NOT* require a reboot. And if you really knew what you're doing, you would see immediately that telling INSTALL to replace SECURESHR is all that is necessary to activate it. On another tack, I just can't imagine a computer which is not available for a reboot (i.e. at worst 15 minutes) at some scheduled time, let's say 3 o'clock on a nice Saturday morning. So please save us this destructive moan about your users! * FLAME OFF * It's just that I prefer to know about the security holes (hole? Lake Baikal!) and, even more important, of a way to fix them as soon as possible. And the speed of DEC's software distribution being what it is ...:-) --- Jan Vorbrueggen
carl@CITHEX.CALTECH.EDU.UUCP (06/14/87)
> On another tack, I just can't imagine a computer which is not available for > a reboot (i.e. at worst 15 minutes) at some scheduled time, let's say 3 > o'clock on a nice Saturday morning. So please save us this destructive > moan about your users! Let me give your imagination some help. Picture the following: A group of physicists spends years designing an experiment to be run on an accelerator someplace (CERN, SLAC, FERMILAB, wherever). They then wait for another extended period of time to get the experiment scheduled on the accelerator. They start the experiment, and have a VAX doing on-line data collection, with some on-line analysis to select only the events of interest. You, as a system manager, then tell them that they're going to lose 15 minutes of data so that you can perform an elective reboot of the system. I guarantee, they won't be pleased. Yes, a system can always be rebooted, but not always at a reasonable cost.
tli@sargas.usc.edu.UUCP (06/14/87)
In article <8706131331.AA09106@ucbvax.Berkeley.EDU> VORBRUEG@DBNPIB5.BITNET writes: * FLAME ON * On another tack, I just can't imagine a computer which is not available for a reboot (i.e. at worst 15 minutes) at some scheduled time, let's say 3 o'clock on a nice Saturday morning. So please save us this destructive moan about your users! * FLAME OFF * I suggest that you use more imagination. There are *MANY* sites which use their systems for large scale numerical processing and real time control applications. Any amount of downtime for these types of systems can be very hard to come by. Even academic systems near the end of the semester have numerous users at all hours. -- Tony Li - USC University Computing Services "Fene mele kiki bobo" Uucp: oberon!tli -- Joe Isuzu Bitnet: tli@uscvaxq, tli@ramoth Internet: tli@sargas.usc.edu