ADSM-L

Re: [ADSM-L] Disparate Client Options

2010-01-06 07:09:20
Subject: Re: [ADSM-L] Disparate Client Options
From: "Schaub, Steve" <steve_schaub AT BCBST DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 6 Jan 2010 07:08:01 -0500
While we're "quibbling"...
What I would like is a single install binary that I could throw at W2K3, W2K8, 
x86, x64 and have it automatically detect and install what it needs, rather 
than me having to create multiple install scripts.  While we're at it, having a 
central console to "push" new clients out in mass would be nice too.

Steve Schaub
Systems Engineer, Windows
BlueCross BlueShield of Tennessee

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Wanda Prather
Sent: Tuesday, January 05, 2010 9:37 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Disparate Client Options

> I could quibble - they have to do all that anyway, right, across the
> various
> clients?
>
> I don't think so. Consider, how would you map an ACL for a UNIX file in
say, an AIX DFS filesystem, to an ACL for a Windows file system?  The client
is supposed to honor those ACL's, and restore them along with the data.  I
don't see how that would work.

And you can have things in non-text files that simply don't compute when
moved from UNIX to Windows and vice-versa.  Moving a binary from UNIX to
Windows won't make it executeable.  And there are file formats that have
big-endian vs. little-endian issues  (for example, output from Fortran, for
which there were UNIX compilers at one time, although I realize there are
fewer and fewer such cases these days.).

And Richard is correct, when restoring to Windows, TSM doesn't write the
files; it calls NTFS to write the files.  I don't know that all the
filesystem calls translate.  For instance, you can create an empty 2GB file
in an NTFS filesystem; there is no such thing in a JFS.

And there are at least 5 different filesystem types for AIX, at least 4 that
I know of for Red Hat, et cetera, et cetera.... many, many permutations.

SO if you say well those aren't the files I'm interested in, I just want
flat files...then I think what you are looking for is a different protocol
altogether - maybe ask for a "bit stream restore", where TSM will restore
the bits into a flat file across operating systems, ignoring all the
conversion issues, and make you responsible for decoding the result.

But I'm still not sure that's desirable from a security point of view, and
most people will find it less work to restore the file back to its original
O/S and FTP it, thereby taking the responsibility of stripping out the ACL's
themselves...

W

>
> Lindsay Morris
> Principal
> TSMworks
> Tel. 1-859-539-9900
> lindsay AT tsmworks DOT com
>
>
> On Tue, Jan 5, 2010 at 2:22 PM, Richard Sims <rbs AT bu DOT edu> wrote:
>
> > On Jan 5, 2010, at 12:19 PM, Lindsay Morris wrote:
> >
> > > True, unix to unix works, and windows to windows too. Osx and netware
> are
> > oddballs, but not so common.
> > >
> > > But we build an appliance that wants to "dsmc restore" from ALL the
> nodes
> > on a TSM site, windows and unix both, to spot-check recoverability. Dsmc
> > blocks cross-platfrm restores (windows vs unix at leadt), and for no good
> > reason, AFAIK.
> >
> > Well...consider what's involved.  The good reason is that a fully
> > cross-platform client architecture would have to include full programming
> > for the universe of file system types accommodated on all the supported
> > platforms - and additionally would have to adeptly provide a meta layer
> of
> > emulation of the wealth of system calls associated with the file system
> > which is not native to the receiving platform.  That's an enormous amount
> of
> > development and testing and maintenance.  I'd rather that their energies
> > went toward things like 64-bit clients, and administrative API, and
> > long-overdue evolution of the terribly neglected CLI.
> >
> >   Richard Sims
> >
>

-----------------------------------------------------
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm