"Configure the Orion ToolSet to use the Server IP as Source Address"

Dears,

We need your support Also regarding the following feature "Use Orion's IP for Browser Integration". case #438469 already opened.

Our client consoles don't have the right to access "ping, traceroute, ssh, telnet and http "the Customers Nodes.

we need to add a feature where we can use the Server IP instead of the client console IP while using the browser integration

Regards

Find more posts tagged with

prodfr

Status: None

Comments

rfletcher

Yes would be great to have

pserwe

Correct me if I'm wrong, but you're looking for access to these tools be run from the Orion *server* directly.

I can corroborate that it would be a good idea. It would be different in my mind than browser integration, which just launches the tools from your workstation.

It would be of particular use for techs trying to troubleshoot a down node, so from the Node Page under node details, having a "traceroute to host" option that would push the results into a window (possibly a popup?) would be great for quickly isolating the source of network issues.

We don't have such restrictions and do most of our activities from privileged hosts unrelated, but I couldn't see that this would have a big impact even on a fairly well loaded poller and executed outside of the normal job engine in a very lightweight plugin with a low priority so it can't clobber more important functions.

As seen in the distant past when I tested trap-based interface status changing, SW needs to implement it with a pretty conservative limit on how many processes it allows to spawn, and maybe even make it smart enough to choose that limit based on available resources with the core product functionality installed and running to ensure it can't impact any services or job engine (v1|v2|vx)

Peter

pierre.elkhoury

Hi Peter,

The Issue i am facing and for Security reason, only the Server IP address has access access to customers Nodes.

While using the browser integration "PING, TRACEROUTE" i noticed that they are using the Client Console IP as source IP.

with my previous Fault Management tools the ping, traceroute and pooling uses the Server IP address.

with Orion NPM the Pool and discovery uses the Server IP address but all the browser integration features uses the client console.

kindly let me knw if you need further information.

Regards

pserwe

Right, okay, so let me throw in a couple of workaround options.

1) For ping/traceroute, I don't run those tools from Windows, they get run from a Linux host behind a gui. Tools like mtr (that requires root privileges) and are of dubious potential security, get protected behind firewalls/network ACL's and appropriate hardening/authentication.

2) If I really wanted to, I could potentially include these resources as custom resources on the home page, but I prefer to keep them separate at the moment.

3) If I wanted to be extra clever, and keep it all on the SW box, I would replicate the functionality you're looking for with a mixture of ActiveState or other windows-based perl implementation and NCM scripts. Whatever you feel comfortable running as CGI, and if it had to run side-by-side with IIS I'd spin it on a non-standard SSL port and redirect as needed.

At a certain point, the question isn't whether or not you can make this tool do those jobs, but whether or not the functionality should be combined in that fashion, the on thing I think this feature request doesn't consider, is the impact of running all of these stuff from what is already a very busy box. One may argue that simple ping/traceroute functionality is of minimal impact, but I can guarantee at any volume, that it's not.

Peter