nv-l
[Top] [All Lists]

Re: Managing with NetView through Firewalls - Answer

To: nv-l@lists.tivoli.com
Subject: Re: Managing with NetView through Firewalls - Answer
From: "Leslie Clark/Southfield/IBM" <lclark@us.ibm.com>
Date: Wed, 1 Nov 2000 08:56:36 -0500
A repost (I think) .....

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit

Urs Schwarzenbach@TIVOLI SYSTEMS
08/25/2000 05:09 PM

To:   NetView-Field-Spec
cc:
From: Urs Schwarzenbach/Tivoli Systems@Tivoli Systems
Subject:  Managing with NetView through Firewalls - Answer


Managing with NetView through Firewalls

This document attempts to describe what the issues involved in
using the NetView web console through a firewall.

The NetView web console uses the following sockets to get at
server side information:
- A web server socket (services HTTP GET/POST requests from various
  beans in the web console)
    [By default this is set to 8080, but is configurable via
     the line:
        main.LISTENER.all.ADDRS                     : 0.0.0.0:8080
     found in /usr/OV/conf/JettyServer.prp]

- A MIB server socket (web console MIB Browsers bind to this port
  via RMI [Java Remote Method Invokation])
    [By default this is set to 8892, but is configurable via
     the line:
        main.root.Servlet.PROPERTY.SERVLET.Util.PROPERTY.mibserverport  :
8892
     found in /usr/OV/conf/JettyServer.prp]

- A separate socket for every open map (Submap Explorer beans use
  TCP socket communication to get map information for the map they
  are attached to).
    [These sockets are randomly assigned, as the code simply asks
     the operating system for the next available free TCP port]

This means that the netview web console, by default, requires that
TCP ports 8080 and 8892 be accessible through the firewall.
It also means that, by default, the Submap Explorer bean within the
web console will probably not be able to operate as it probably
won't be able to get at the randomly assigned port number being
used by the associated "maptreeserver" on the server side (this
"maptreeserver" is a jre process that every NetView console
launches to service requests from client Submap Explorers).

The NetView V6.0 product does NOT allow configuring this
"maptreeserver" port but the NetView V6.0.1 product DOES allow
configuring it with one important restriction: once configured
you must restrict yourself to only one concurrently open
map.  This isn't a problem on NT, as the NetView for NT product
currently restricts you to only one concurrently running
netview.exe process.  This could, however, be a problem on
NetView for Unix as there is no attempt to restrict you to
running only one concurrent ovw_binary process.

If you can live with the "one concurrent NetView console"
restriction, the work-around for this Submap Explorer port
issue is to specify a "portToUse" -D argument, such as
"-DportToUse=8893", to the jre "maptreeserver" process that
the NetView console launches.  For example, on NT you can
change the maptreeserver.reg line that starts with:
    Command -Shared -Restart -Initial '/usr/ov/jre/bin/jre ...
to instead start with:
    Command -Shared -Restart -Initial '/usr/ov/jre/bin/jre -DportToUse=8893
...

(Unix users would need to make a similar change to the
/usr/OV/jre/bin/jre command that appears in maptreeserver.reg).
[ The configuration file that specifies this can be found in:
  for NT   ... \usr\ov\registration\c\maptreeserver.reg
  for Unix ... /usr/OV/registration/C/maptreeserver.reg ]
In this example, the "-DportToUse=8893" argument will ask that
the jre process bind to port 8893 and you should see something
like this:
    15:24:51   Server is ready to accept connections on port 8893
in your log file (~/nv6000.log on Unix or \usr\OV\log\maptree.log
on NT).  However, on Unix adding this "-DportToUse=8893" argument
also means that, once launched, future launch attempts of this
same jre command will result in "port already bound" problems.
This is the reason for the "only one concurrent NetView console"
restriction.  Obviously, this work-around would require that you
open the firewall for access to the TCP port you've specified in
the -DportToUse argument.

***********************

For any changes to the NetView-Field-Spec distribution list please send me an 
e-mail.

Thanks
Urs Schwarzenbach
----------------------------------------------------------------------
Product Evangelist
Service Provider Business Unit, Tivoli Systems

phone: 512-436-4510
mobile: 512-423-1479
urs.schwarzenbach@tivoli.com


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Managing with NetView through Firewalls - Answer, Leslie Clark/Southfield/IBM <=

Archive operated by Skills 1st Ltd

See also: The NetView Web