On 10/8/08 9:17 AM, John McKown wrote:
I didn't see the original message. Apparently the OP wants to backup
RHEL/Intel files on z/OS. I will mention a very nice product which is
free, but not open source. It is Co:Z from Dovetailed Technologies.
http://www.dovetail.com
What this can do is establish an SSH session from z/OS to any Linux box
which is running sshd. On the Linux box, there are some programs
installed. Then, on the z/OS side of the world, you can run a jobstep
similar to:
//BACKUP EXEC PROC=COZPROC,
// ARGS='[EMAIL PROTECTED]'
//STDIN DD *
cd /sub/directory/to/back/up
tar cjv * |\
todsn -b '//DD:TAROUT'
/*
//TAROUT DD DSN=output.file,
// RECFM=FB,LRECL=1,BLKSIZE=0,DSORG=PS,
// UNIT=(SYSDA,10),
// SPACE=(CYL,(200,10))
//
The above puts the output of the tar command on the file "output.file" on
the z/OS system. Unfortunately, as shown, it requires that the RACF id on
the z/OS system have a UNIX UID and home directory which contains
~/.ssh/id_rsa file and that file have a "null" passphrase which is
appropriate to ssh onto the given Linux box with the given Linux ID.
Going off on a tangent here, you can limit the exposure of a null
passphrase by including the "from=" and "command=" parameters in the
target userid's .ssh/authorized_keys file, on the line matching the
source userid's .ssh/id_rsa file, similar to:
from="host.domain,from_IP,etc",command="sudo rsync --server -vlHogDtprxS
. ~a_user/user_subdirectory/" ssh-dss AAAAB3Nz...
(this example only allows the rsync server to be used with this key
pair, and only allows rsync-ing from/to (can't remember which way) a
particular directory.)
You have to be careful, however, to make sure the target host can vet
the source host via the host keys, that the "from=" parameter include
all hostnames that may be received by the target, that the "command=" is
specified correctly (e.g., if the todsn, or the cozproc command, pass
exactly "cd /sub/directory...'//DD:TAROUT'", that's exactly what should
be in the authorized_keys file; commands like scp and rsync generate
other commands that are sent to the target system), and that the
permissions be correct on all the files involved, or ssh will disallow
access with little/no diagnostics (there's some techniques for getting
better diagnostics if anyone's interested). You can also use the
"SSH_ORIGINAL_COMMAND" variable in the "command=" parameter in
authorized_keys to essentially pass parameters to the target userid's
command, but you have to cleanse it before trusting it.
- Larry
PS wow, I guess it's been a while since I've touched MVS...ah, z/OS --
lrecl 1, blocksize 0?!?
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
