summary of ufsdump problem

From: Hansen, Craig D. CECOM SEC LSSC CENSOR (hansenc@ST-LOUIS-EXCH01.army.mil)
Date: Mon Jan 31 2000 - 09:00:13 CST


Thanks to: Richard Felkin
            Ron E. Nelson
              Gary Litwin
            Moti Levy
                David Stern and many many others.

Summary:
Well I'm sorry it took me so long to give this summary, but I never did figure
out why I can't do a: rsh machine_name date from our Ultra 10's. You can however
do a rsh "to" the Ultra 10's, so I just went around the problem....for now.
David Stern gave me a couple of good idea's. I was able to rsh to sunkist-fast
(the machine that needed to be backup up) from calvin (machine with tape drive).
So I just went to calvin and typed: rsh sunkist-fast "ufsdump -0f - /usr" | dd
of=/dev/rmt/0n obs=32786 --->
and this did the trick. Thanks for everyone's responses. I really appreciated
your idea's. Below is some of the responses and my original question (where I
put dsk I meant to put rmt).
            

Original Question:
Sun Experts,
  I'm having a problem doing a ufsdump to a tape device on a remote machine. I
have added a .rhosts file under / to prevent any access problems but I'm still
receiving errors. The machine I'm doing the dump from a 2.7 machine to a 2.6
machine...if that makes any difference??? This is what I'm typing from
sunkist-fast to dump to calvin:
# ufsdump 0ucf calvin:/dev/dsk/1c /dev/rdsk/c0t0d0s3

Here are the error messages I see:
# ufsdump 0ucf calvin:/dev/dsk/1c /dev/rdsk/c0t0d0s3
   DUMP: stl-06lssc: Connection timed out
   DUMP: Cannot connect to tape host `calvin'
   DUMP: The ENTIRE dump is aborted.

Some responses were as follows:
--------------------------------------------------------------------------------
-----------------------
Issue this command from the tape host system

rsh target-sys ufsdump 0fsu source-sys:/dev/rmt/0n 132000 /dev/rdsk/c0t3d0s0
--------------------------------------------------------------

can you do: #rsh calvin date

--------------------------------------------------------------

use the format:

ufsdump 0f - /usr | rsh calvin dd of=/dev/rmt/0 obs=32768

--------------------------------------------------------------

1.from the host you want to copy to run rsh - remotehost date ( this to
check that you have premissions right)
2.cd to the file system youre intrested to copy file to ( /usr )
3.excute the following command rsh remotehost 'ufsdump 0fu - /usr' |
ufsrestore xf -
this will copy the remote file system to local disk.

--------------------------------------------------------------

rsh machine_name 'ufsdump 9bf 126 - /dev/dsk/c020d0s6' |dd of=/dev/rmt/0mn
obs=63
       ***substituting the appropriate diskslice

Check that th eline containing in.rshd in /etc/inetd.conf is not commented
out. If it is, ps e-f | grep inet, get the pid and kill -1 PID.

do a tail -f on /var/adm/messages and try telneting in. See what messages says
he he's the connection as ie perhaps the machine is confused about your IP
address. Likewise, do an nslookup on the problem machine to insure he can
resolve the name you're coming from. BTW, If messages is not logging
connections, you may be need to add to /etc/syslog.conf
daemon.debug /var/adm/messages (note: whitespace is TABS, not spaces) If you
make this change, you'll need to kill -1 syslog just like I descrobed above for
inetd.

-------------------------------------------------------------

rsh padma ufsdump 0ucf meru:/dev/rmt/0n /dev/dsk/c0t0d0s0
where padma is the machine that will be backuped, meru is the machine at which
the backup device is installed and /dev/dsk/c0t0d0s0 is the device to backup.

--------------------------------------------------------------

So ufsdump uses the Berkely r* protocols? (If my Ultra wasn't broken, I'd check
this myself...). If so, then you could try telneting to port 514 on the
destination and seeing if you get through; cheking /etc/inetd.conf on the target
to make sure that shell is running; perhaps run snoop on both sides. Note that
rsh uses a perverse protocol that's a little like FTP -
insofar as it opens a second "reverse" connection from target to source.
Firewalls (PIX, Firewall-1, ...) typically have a special flag that you need to
set to allow this behaviour.

-------------------------------------------------------------

Craig Hansen
UNIX System Administrator
CEN Corporation (CENCOR)



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:02 CDT