Thanks for the replies.
In brief, I was trying to backup a server that resides outside
the firewall with my backup server that resides inside the
firewall. I was essentially running an 'rsh dump' from the server
to the client outside the firewall... then I would pipe the
dump back (via stdout) to the tapedrive on the internal server.
I was told this was 'insecure' but I just don't see the concern.
It's not like data is leaving the firewall, it's only coming in.
And since it's all initiated internally... seems pretty safe to
me. If you've got a great argument why this is "inherantly stupid"
I'll gladly listen. Meanwhile, it sure makes my life a whole lot
easier only having to run one centralized network backup.
There were some generally good thoughts on the subject but no one
was able to nail down the problem. I don't think there are
many people out there running this firewall. The final solution
actually came from CISCO, the vendor of our firewall, and the
answer was... there's a bug in the firewall software
that stomped on 'rsh' results. A quick ftp download and rev
2.7.12.2 update solved the problem.
Thanks for feedback from...
jholt@pdc.com (Jay Holt)
Rich Snyder <rsnyder@eos.hitc.com>
"Matthew Stier" <Matthew.Stier@MCI.Com>
---Original query...
Hey all:
I'm trying to run a backup through a firewall by issuing an rsh a redirecting the stdout back. I know, I know, you're not supposed to try to backup through a firewall for security reasons. Still, it's maddening because I can't figure out WHY it doesn't work!
I currently use a Perl script which runs from my backup server (with a tape drive local to that server) and essentially issues a bunch of commands very much like this...
# rsh -n $REMOTEHOST /usr/sbin/ufsdump 5ubdsf 126 10800 68000 - / 2>/tmp/dumplog | dd obs=126b of=/dev/rmt/0n
...and so it rsh's into each machine and redirects a dump back to the server's tape drive. This works very well and I prefer it to many of the alternatives.
Now the firewall part. The firewall is designed to only block one-way. We can get out (and echo stuff back) but outsiders can't get in (unless specifically allowed). This means I should be able to rsh into the machine outside our firewall (itchy) and echo stdout back to my tape drive, just like I do with every other machine that resides inside the firewall.
Unfortunately it just goes out and hangs....
# rsh -n itchy /usr/sbin/ufsdump 5ubdsf 126 10800 68000 - / ^C
It won't return until I break out. Also true like this...
# rsh itchy /usr/sbin/ufsdump 5ubdsf 126 10800 68000 - / ^C
Okay, we blame the mysterious firewall. BUT, why does THIS work?!?! # rsh itchy Last login: Fri Dec 20 20:23:38 from kazoo.wcnewmedia Sun Microsystems Inc. SunOS 5.5 Generic November 1995 You have new mail. root@itchy(1): /usr/sbin/ufsdump 5ubdsf 126 10800 68000 - / DUMP: Writing 63 Kilobyte records DUMP: Date of this level 5 dump: Fri Dec 20 20:32:02 1996 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rdsk/c0t3d0s0 (itchy:/) to standard output. DUMP: Mapping (Pass I) [regular files] DUMP: Mapping (Pass II) [directories] DUMP: Estimated 1343638 blocks (656.07MB) on 0.09 tapes. DUMP: Dumping (Pass III) [directories] gjl[C-Cnone//dev/dsk/c0t3d0s0itchy2;>jl[PKpnone//dev/dsk/c0t3d0s0itchy~ {o ^C
You see the maddening mystery!? I can manually rsh to itchy, execute the ufsdump, and see the whole thing echoed back to my local (backup server's) console. I just can't do it all in one neat command while implementing redirection.
It seems like if I can do the latter I should be able to do the former.
I've made references of the backup server in itchy's /.rhost and /etc/hosts.equiv file. No good.
Any suggestions? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | _/ _/_/ _/_/ _/_/ _/_/_/ _/_/_/_/_/ _/_/_/_/| | _/ _/ _/ _/ _/ _/ _/ _/ | | _/ _/ _/ _/ _/ _/ _/_/ _/_/_/ | | _/ _/ _/ _/_/_/_/_/ _/ _/ _/ | |_/_/_/ _/ _/ _/ _/ _/_/_/_/_/ _/_/_/_/_/ | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Dan Penrod - Unix Network Administrator | | Image Technologies - World Color New Media | | 2502 Rocky Point Dr. Suite 200, Tampa, FL 33716 | | vox:813/636-9266 fax:636-0431 penrod@wcnewmedia.com | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:18 CDT