[ On Sunday, April 4, 1999 at 15:35:45 (-0400), Curt Sampson wrote: ]
> Subject: Re: Recovering from /usr loss
>
> That's a nice thought, but I'm on the open Internet with this
> particular machine. Who is his right mind is going to enable
> rlogin/rsh?

If the machine's got no /usr then you're not open on any network!  ;-)

Use TCP Wrappers and/or IP Filter to restrict access to your r* ports
and you should be safe enough.

Worst case you can transfer the necessary files to a local server,
unplug it from the internet for a few moments, plug the dead machine
directly into it, temporarily enable rsh, and slurp across the files.
So long as you remember to disable rsh again on the server before you
re-attach it to the internet you'll be just fine:

	rsh server gzcat saved-usr.tar.gz | pax -r -p e

BTW, if you control your own DNS and you are sure your systems use your
own local authoritative DNS, then the only known attack against modern
rsh implementations (other than social engineering and/or naughty users
leaving foreign hosts in their ~/.rhosts files) is a TCP spoofing attack
and you don't see those every day yet....  With the added protection of
appropriate IP Filters and TCP Wrapper configuration you can reduce the
risk of the r* tools to a very acceptable level.

<SARCASM>

BTW, this is yet another reason for keeping / and /usr (but perhaps not
/usr/pkg or /usr/local, and definitely not /tmp or /var or any other
more volatile area) in the same filesystem (iff they would be on the
same spindle anyway, of course).  You'd then have been forced to
re-install the entire base system and you wouldn't have had a chance to
get stuck in any Catch-22 situation like this!  ;-)

</SARCASM>

<BLUE-SKY-MORE-THAN-24-HOURS-IN-A-DAY-DREAM>

It would be nice if pax used zlib instead of forking gzip though.....

</BLUE-SKY-MORE-THAN-24-HOURS-IN-A-DAY-DREAM>

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>