--kORqDWCi7qDJ0mEj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Hart, Charles <charles.hart AT medtronic DOT com> [2005-04-29 15:46]:
>=20
> 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.

--=20
David Rock
david AT graniteweb DOT com

--kORqDWCi7qDJ0mEj
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCdaWNMrO4/Yb/xwYRAiMwAKDOzoh/uzTtw7y+vZJMqi4rWtaaQQCfb/jq
fVgQWtlLd5Rcw9pm0CPi0GY=
=5mcf
-----END PGP SIGNATURE-----

--kORqDWCi7qDJ0mEj--