[PLUG] My mail server is down for the moment...

Elliott Mitchell ehem at m5p.com
Thu Jul 20 02:09:39 UTC 2006


>From: Ronald Chmara <ron at Opus1.COM>
> I know it's not much help now, but I have a *very* small list of things 
> I *never* do remotely:

Oh, you just lack courage!  :-)   ...insanity helps too.

> 1. kernel upgrades (if it bonks on the BIOS level, no remote daemon can 
> save you... the only fix would be a magic box that tunneled raw VGA 
> output, raw PS2/USB input, etc. over TCP/IP... is there such a beast?)

The thing is, being stuck at the LI prompt is actually more secure than a
problematic kernel. Your stuff is inaccessible to you, but it keeps the
intruders out as well.

With a distribution kernel though, this isn't all that hazardous. They
tend to ship working kernels, and the associated scripts tend to ensure
no steps are skipped (`pkgadd` a kernel patch on SunOS remotely, no
problem!). Also with GRUB understanding the filesystem and not needing to
be rerun, the danger has been greatly lessened. Still something to avoid
if you can, but a danger that can be minimized.

Installing a new custom kernel on a system 600 miles away which uses
LILO and Sun-style disk slices, definitely not for the faint of heart.
Finally got it to work for me though (the previous times I was a lot
closer, this time would of been a downtime of more than a week).

> 2. RAID juggling (if /boot is on a SCSI RAID 5, for example)
> 3. For that matter, anything SCSI. Requires waaaay too many goat 
> sacrifices when *at* the console to even consider doing remotely. (Or, 
> alternately, really good high end cables and terminators, which I 
> *never* seem to see IRL.)

You've got a method to install SCSI disks remotely? Impressive.

> 4. Any crypto library changes, or pam changes, if my sole admin access 
> is ssh. (Want to know how to make an sshd session work when the daemon 
> dies because libraries have changed? So do I.)

Problematic on SunOS where open() never returns EBUSY, elsewhere, pretty
easy. You just have to make sure to only kill the server sshd process,
and then test that you can get back in successfully (meaning you keep a
termninal with a root shell open while testing). Not danger free, but
something I do without many worries.

> 5. ifconfig changes (without a crond/atd backup script to restore 
> settings) on single NIC machines.
> 6. For that matter, ipchains/iptables/ipfw changes (without a crond/atd 
> backup script to restore settings) on even multi-NIC machines.

Yeah, know that one two. /Somewhat/ less dangerous than kernel upgrades
(less actually if you're using a package manager).

> Anybody else have warnings to add to the historical pool of "Ooops", so 
> future admin folks can spend less time pounding their heads mercilessly 
> into keyboards?

Not really, you've gotten the ones you have to worry most about. Though
of your list I think only 1, 5 and 6 are really major. 2 and 3 you need
to be at the console to juggle the hardware anyway.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/





More information about the PLUG mailing list