Thank you for the explanation David.  I can see why you wouldn't want to
do that.  In today's world of ever increasing regulatory environment
NBU's security methodology needs to change.  While apparently you can
lock NBU's security down buy applying individual rights to each
executable file I cant imagine many people in large Backup environments
do that, so many of us out there run the admin console as root etc...
In addition while it's kind of nice to be able to read the backup data
using tar this creates a huge security hole such as the recent loss of
Bank of America backup tapes exposing 1.2Million people's financial
data! ( http://msnbc.msn.com/id/7032779/ )  Yikes!

At one point there was talk that NBU was going to build a "Role Based"
security in to NBU.  With TSM we can create many levels of users, for
example using the Bocada Backup Report the TSM Data Collection is done
via its ODBC driver using a read only account.

On a positive note, with all the recent regulation activity backups are
finally getting the necessary visibility.

Have a good day!




-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of David Rock
Sent: Sunday, May 01, 2005 10:59 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Advanced Reporter

* Hart, Charles <charles.hart AT medtronic DOT com> [2005-04-29 15:46]:
> 
> As far as mapping the NBU error codes it can be cumbersome, but once 
> set you're done.  Not sure what the issue is for the reporting tool to

> "Pretend to be a media server.  How does Aptare collect NBU data?

It's a security hole you don't need, for one. Any system that is listed
as a media server in your environment has FULL access to whatever it
wants in NBU. That's not a good idea. BTW, that's also how Veritas
allows the Admin Client to connect. Very, very stupid. There are a
hundred other ways that are much more secure than that.

It's also more likely to be stepped on by Veritas. All they have to do
is change their security model and you're screwed. You are MUCH safer to
use the published CLI to access data rather than try to hack and snoop
your way to the data. If it does get changed, the development time to
fix your app is a lot shorter.

Aptare collects their data by running published CLI commands and then
pushes to the database server via port 80. That's it, nothing fancy. I
also can't say enough about Aptare's responsiveness when we have run
into an issue. They are very knowledgable about their product and how it
interacts with NBU data. I have never gone more than 24 hours without a
solid fix to an issue, and it's usually only a couple hours.

--
David Rock
david AT graniteweb DOT com