Backup Central

Content-Transfer-Encoding: quoted-printable

Hi everyone,

=20

I dug through the archives to try to answer the following question, but
didn't find an answer.

=20

The question: It appears after looking through documentation that even
using NBU's "no callback" feature, a media server and/or client WILL
still initiate a connection back to the master using that method. Has
Veritas updated that behavior in version 5 to get rid of any connections
initiated towards the master? We have clients in a DMZ, and cannot have
them initiating connections into the internal environment (where the
master is) so the no callback feature as it's built in 4.5 will not work
for us. If they've fixed this behavior in version 5, then we may be in
business. Otherwise, we're kind of stuck since we don't want to
dual-home the master and media servers in our existing setup, either.

=20

Thanks!

=20

Marshall Skare

ATIS - Unix Engineering

(612) 277-4434

=20



This message is for the designated recipient only and may contain =
privileged, proprietary, or otherwise private information. If you have =
received it in error, please notify the sender immediately and delete =
the original. Any other use of the email by you is prohibited.

I don't know the answer to your question, but I don't see how you could
have a user initiated backup, user initiated restore, or a DB Agent
backup without allowing the client to initiate contact with the master.
cheers, wayne

marshall.a.skare < at > accenture.com wrote, in part, on 1/24/2005 4:03 PM:


The question: It appears after looking through documentation that even
using NBU’s “no callback” feature, a media server and/or client WILL
still initiate a connection back to the master using that method. Has
Veritas updated that behavior in version 5 to get rid of any
connections initiated towards the master? We have clients in a DMZ,
and cannot have them initiating connections into the internal
environment (where the master is) so the no callback feature as it’s
built in 4.5 will not work for us. If they’ve fixed this behavior in
version 5, then we may be in business. Otherwise, we’re kind of stuck
since we don’t want to dual-home the master and media servers in our
existing setup, either.

I would imagine he's encountering the same issue as I am.
Policy here doesn't permit connections initiated from the DMZ,
therefore, without a "true" no-callback we can't backup anything in the
DMZ.
Many sites would sacrifice the ability to do user initiated restores,
backups, or DB agent backups in the DMZ in favour of just being able to
do regular plain vanilla backups.

I guess it should just be an "available feature".

In our environment, we don't permit user initiated backups or restores
anyway, so there would be no loss to us....and we don't do DB agent
backups, unless absolutely required.

A work around to this (which I've not yet tested) is to bring up an SSH
tunnel from the master/media server to the client in the DMZ, before the
job kicks off. Once the tunnel is up, the client can reply on the tunnel
session, without the connection being initiated from the DMZ.
Once the backup is complete, the tunnel gets torn down.

Paul

-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu] On Behalf Of
Wayne T Smith
Sent: January 24, 2005 4:26 PM
To: veritas-bu < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] FW: Verifying a feature of vnetd's
no-callback feature


I don't know the answer to your question, but I don't see how
you could
have a user initiated backup, user initiated restore, or a DB Agent
backup without allowing the client to initiate contact with
the master.
cheers, wayne

Hi Paul,

If you get that SSH tunneling to work, I'd love to see how. I'll mess
around with it too in the next few days and see if I can get it to work
as well.

You're right in that we're both looking for the same functionality.
True "no callback" as you would normally think it to be given the name
of the feature.

Marshall Skare
ATIS - Unix Engineering
(612) 277-4434

-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu] On Behalf Of Paul
Keating
Sent: Tuesday, January 25, 2005 8:15 AM
To: veritas-bu < at > mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] FW: Verifying a feature of vnetd's no-callback
feature

I would imagine he's encountering the same issue as I am.
Policy here doesn't permit connections initiated from the DMZ,
therefore, without a "true" no-callback we can't backup anything in the
DMZ.
Many sites would sacrifice the ability to do user initiated restores,
backups, or DB agent backups in the DMZ in favour of just being able to
do regular plain vanilla backups.

I guess it should just be an "available feature".

In our environment, we don't permit user initiated backups or restores
anyway, so there would be no loss to us....and we don't do DB agent
backups, unless absolutely required.

A work around to this (which I've not yet tested) is to bring up an SSH
tunnel from the master/media server to the client in the DMZ, before the
job kicks off. Once the tunnel is up, the client can reply on the tunnel
session, without the connection being initiated from the DMZ.
Once the backup is complete, the tunnel gets torn down.

Paul

-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu] On Behalf Of
Wayne T Smith
Sent: January 24, 2005 4:26 PM
To: veritas-bu < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] FW: Verifying a feature of vnetd's
no-callback feature


I don't know the answer to your question, but I don't see how
you could
have a user initiated backup, user initiated restore, or a DB Agent
backup without allowing the client to initiate contact with
the master.
cheers, wayne



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

Content-Transfer-Encoding: quoted-printable

Yes, but the point that was bing discussed, is that even with vnetd
option, the client still initiates the connection to the media server,
requiring port 13724 being open from DMZ into production network.
=20
this currently violates 2 policies here.....ports open from DMS into
production, and connections initiated from DMZ, so it is of no use.
=20
Paul

-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu] On Behalf Of Carlos
Alberto Lima dos Santos
Sent: January 24, 2005 6:51 PM
To: veritas-bu < at > mailman.eng.auburn.edu
Subject: RES: [Veritas-bu] FW: Verifying a feature of vnetd's
no-callback feature
=09
=09
In NetBackup 5.0 has a option to avoid the callback an use
only the vnetd port. In the NetBackup administrator guide V5.0 has a
procedure how to configure this option. Se the technote below.
=20
http://seer.support.veritas.com/docs/271202.htm
=20
T+

Content-Transfer-Encoding: quoted-printable

Yes, exactly right.......what is *needed* by both myself, and the
original poster, is a way for NB to initate connection from server in
production to client in DMZ, and maintain that connection for the
duration of the backup, rather than signalling the client and having the
client open the connection back to the server in production (single
port, or random port.....single security hole, or multiple)
=20
vnetd still requires an open port...... a security hole.....a slightly
more obscure hole than leaving all ports open, but not much, when you're
talking about secure environments.
=20
Paul

-----Original Message-----
From: David Trostli
[mailto:david.trostli < at > veritas-software.com.br]=20
Sent: January 25, 2005 11:25 AM
To: Paul Keating
Subject: RES: [Veritas-bu] FW: Verifying a feature of vnetd's
no-callback feature
Importance: High
=09
=09
even using vnetd you need to open port 13724 in the firewall. If
you don't do this you won't be able to go througn you DMZ. The purpose
of vnetd is to avoid the use random reserved port.
=20
David