Re: Does this help explain better?? ATA/IDE Thread

From: Stephen Frost (sfrost@ns.snowman.net)
Date: Tue Jul 25 2000 - 14:37:07 EST


On Tue, 25 Jul 2000, James Sutherland wrote:

> On Tue, 25 Jul 2000, Khimenko Victor wrote:
>
> > In <Pine.LNX.4.10.10007251640210.15492-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
> > JS> On Tue, 25 Jul 2000, Khimenko Victor wrote:
> >
> > >> For example our server do not have floppy drive at all. It does not have
> > >> kerboard or attached monitor as well.
> >
> > JS> How do you handle situations where you need to take it down to single-user
> > JS> mode, no network?
> >
> > Why you think it's ever needed ?
>
> You do all your system maintenance with the system online, serving users?!

        Personally I do as much as possible that way. Very rarely do I
have problems too, esp when I'm using SCSI devices. The *point* is to
be able to do everything needed to keep the machine running while it's
up and serving users. With Unix in general this is possible.

> > >> > That way, they can't blame it on your anti-virus daemon, your NIC,
> > >> > the kernel version you're running, etc.
> > >>
> > >> Without my NIC I'll be unable to do ANYTHING with my system, sorry.
> >
> > JS> You're pretty much stuffed when your NIC firmware upgrade fails, then.
> >
> > Correct. But I have THREE NIC's there. So I can access system if ANY of them
> > fails (even more: if one NIC is fryed backup will be activated automagically).
>
> OK - supposing it's the system BIOS you just fried remotely?

        So there are some things that you can't flash. I'm certainly not
saying you can flash everything in the system, I'm saying we shouldn't limit
ourselves or Linux without good cause. The concern that someone *as root*
might be able to damage something certainly isn't a very good reason to
limit ourselves in such a manner. Esp. not when it adds code to the kernel
which has no other redeeming value.

> > JS> You have bigger problems than not getting a nice point&drool interface for
> > JS> low-level hardware modifications.
> >
> > Perhaps. Usually if one NIC is fryed I can shedure replacement procedure for
> > month or so later - I have more then enough time for that.
>
> IF it's a redundant component like that. Some aren't - the system BIOS,
> perhaps.
>
> > P.S. NIC can be fried by static electricity, not only from cracker. That's
> > why this backup system was invented in first place.
>
> You don't seem to have any procedure in place for recovering if/when the
> upgrade fails. If you can't get the NICs online, or boot into Linux, what
> are you going to do?

        If the upgrade fails you have to replace the NIC, but that can be
done later, you don't have to immediately reboot the machine, and it can be
planned for downtime.

                Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:20 EST