stan wrote:
> On 02 3, 2010, at 3:13 AM, Preston de Guise wrote:
>
>
> > Hi Tim,
> >
> > On 03/02/2010, at 17:19 , tkimball wrote:
> >
> > > All involved systems are solaris 10 Sparc. Server is 7.4.4 EBS, client
> > > is 7.4.1 EBS IIRC (at least 7.4).
> > >
> > > I need to enable Client Encryption on one of our manual backups (run from
> > > save cmd on client). After some trial and error (and an incorrect
> > > manpage on asm names *sigh*) I see a test backup of /etc, from save
> > > command, using the aes asm on the client.
> > >
> > > However, a recovery test on another system does not ask you for the
> > > passphrase (which I set in the Server Config under NMC). I'm using the
> > > recover command instead of nwrecover for testing.
> > >
> > > So, is this actually using Encryption or not? Do Encrypted backups use
> > > the server passphrase when running manually? I don't care either way as
> > > long as I can assure the client its encrypted - default passphrase will
> > > suffice for now.
> > >
> > > The directive (placed in /etc for the test) is straightforward:
> > >
> > > +aes: *
> > >
> >
> > It's been a little while since I configured an encryption setup. However,
> > from memory once the password is set in the datazone, it holds true for all
> > backup/recovery operations in the datazone. Try removing the passphrase and
> > see whether that helps (or failing that, remove the passphrase and
> > stop/restart NetWorker).
> >
> > The other option when running the manual backup is to run save -v; this
> > should tell you what asm's it invokes.
> >
> > I could be wrong though ... it's been a couple of months.
> >
>
> Tim needs to include the appropriate passphrase on the recover command. You
> can tell if a backup is using aes encryption because recovering it without
> the correct passphrase will result in an empty file being recovered. See the
> man page for the recover command for details.
>
Yes, recover *should* have given me back a garbage file (when not running under
-p), but it did not.
I had a Sun engineer on the phone yesterday, and through a webex stepped him
through my test case (below) on a 'fresh' client. The test file (in the webex,
/etc/inet/hosts) did not recover as garbage when the passphrase was left out.
Their guess (from the wording in manual) is that aes asm only works for a
server-started (savegrp) backup. Since we're using a client-started backup
(save) its not really happening, even though 'save -v' shows the aes asm being
used.
I've asked them to confirm this behavior with EMC. My personal feeling about
this is that its a bug, one that normally does not affect many people. In our
case though, this is a serious problem - over 2/3 of our data backups are
client-run.
The test client used in the webex is group-run, so I left the below /etc/.nsr
in place for testing during his next Full backup (over the weekend).
For now, I'm exploring other options, including pre-crypting the files through
our backup script (before save is run).
--TSK
-----=====-----
to replicate the issue:
- set a passphrase in the Server Config
- create /etc/.nsr file as:
+asm: *
- Run on client:
save -s [server] -v -w "one week" -y "one week" -b [any pool] /etc/inet/hosts
[This shows 'aes -s' used as the asm command]
- Run recover (without -p), select the file above, choose 'recover'
--> A passphrase is *not* required, it just recovers the file.
+----------------------------------------------------------------------
|This was sent by t.s.kimball AT gmail DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
