Here's some interesting information that crossed my desk recently.
Some of you may be interested in it.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
This document attempts to describe what the issues involved in
using the NetView web console through a firewall using NetView Version 6.0
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.
-NetView Development
|