NetXMS Support Forum

Dear NetXMS team,

I am currently facing an issue with Line charts which use data from DCI, populated by the NetXMS Agent push:

The way, data collection works for these DCIs is that (e.g.) every five minutes, a script pushes 24 timestamp-value pairs (one for every one of the last full hours) to the DCI using nxapush.

This is done every five minutes, because the values might change over the course of an hour. The idea here is that it always overwrites the previously assigned values to those timestamps, and here comes the problem:

I noticed (at first in the line charts) that there are multiple different values assigned to equal timestamps, resulting in vertical steps within the graph, as seen in 'double_value_assign.png'.

Then, I checked the history data of the DCI and as seen in 'multiple_value_assign1.png', there are in fact multiple instances of timestamp-value pairs, which have the same timestamp.

(I marked the two entries, which refer to the right-most step in the line chart screenshot)

Is this expected behavior, or a bug?

Anyway, my assumption is that most users would expect nx(a)push to just update the value, if an entry with the given timestamp is already present on the DCI.


Kind regards,
fbu

Soooo, after hundreds of LoC and hundreds of grey hair later, I finally managed to get the Apereo CAS working with NetXMS Web UI.

In order to help other users, who also struggle to get this to work on their setup, I answer my questions from the original post by myself, give brief tips and try to keep it as general as possible.

You will need the following Server Configuration variables set on your NetXMS server:

"CASHost" - The hostname/IP facing to the CAS server; in case it is behind a proxy, configure the proxy let this hostname point to the CAS server (or the root folder of it's .war)
"CASPort" - The port which will be appended to 'CASHost' for the https-request (Again, when behind a proxy, use the port, which is configured in the proxy to point towards the server)
"CASService" - The 'serverId' configured in CAS, NetXMS uses to identify intself at CAS
"CASTrustedCACert" - The path to the CA certificate of the CAS server (actually, I'm not 100% sure about that, but it worked for me to just use the .crt file, which I generated for the CAS-domain)
"CASValidateURL" - The path extension to append to hostname and port to get CASHost:CASPort/CASValidateURL. At this resource, NetXMS requests CAS to validate the received service ticket. (With CAS 6.0.x, this is by default '/cas/serviceValidate')

(From this point, I will use cas.example.com as CAS-hostname and netxms.example.com as NetXMS-WebUI hostname -> this will also be its serviceId at CAS)

1. "How does the Webapp handle the SSO session?":

• After loggin into CAS at cas.example.com/cas/login?service=netxms.example.com, CAS will redirect to netxms.example.com?ticket=ST-[...]-something
• The Webapp then attempts to connect to the NetXMS server defined either in nxmc.properties or by the 'server' query parameter (otherwise, 127.0.0.1 is chosen) and provides the service ticket to be used as SSO login.
• The NetXMS server then tries to connect to the CAS server's service validation endpoint defined by the three variables above, using HTTPS and to verify its SSL certificate (here: cas.examlpe.com/cas/serviceValidate?service=netxms.example.com&ticket=ST-[...]-something
• The provided parameters 'service' and 'ticket' are used for validation. If they are valid, NetXMS tries to extract the XMS tags <cas:authenticationSuccess> for confirmation and <cas:user> to determine the username, from CAS-server's response.
• Successful login is only possible, if the username extracted from <cas:user> is present in the NetXMS user database, otherwise, access will not be granted.

1.1 "Is there a special URL to which CAS needs to redirect upon successful login?":
More or less: netxms.example.com?ticket=ST-[...]-something (The URL to reach the login-page of the NetXMS WebUI, extended by a query string containing at least the ticket-parameter)
This is done by default by CAS, so nothing to do here.

1.2 "Which attributes are needed from and for CAS?":
From CAS, only the service ticket (and optionally, the NetXMS server, but this can by set in nxmc.properties)
To CAS, serviceId (CASService configuration variable) and ticket, additionally, the username in CAS should also be present in NetXMS user database

1.3 "Is SLO (single log out) also implemented?":
So far, I did not see anything like this. After logging out from a NetXMS SSO session, the current service ticket may be expired (depending on the CAS configuration), but the TGT (Ticket granting ticket) is not, so logging in again via the CAS interface will not prompt the login dialog of CAS, until cas.example.com/cas/logout is requested.

2 "How is the user management handled?: "
The username extracted from the validation response (<cas:user>, which is basically the principal id) is used to determine the representing user within the NetXMS database. Basically, it is just as logging in as this user.

2.1 "Does te user still need to be present in the NetXMS database?: "
Yes 

2.2 "If not, how are access rights handled?: "
As 2.1 returns 'Yes', this is pretty self explaining, given that you know how NetXMS internal user-/group management works.

3 "Can the official documentation be extended with this topic?":
I don't know, they could refer to this forum thread, maybe 


Hopefully, this helps some people setting up their CAS/NetXMS infrastructure. (Btw.: Debug level 9 in server logs gives some good information about this. Keep an eye open for SSO error codes (0,-1,-2,-10 ... -20 ...) and messages - their handling can be checked in the file 'cas_validator.cpp' of the sourcecode, which can provide some help in determining, what is going on).

The file 'ApplicationWorkbenchAdvisor.java' in [SourceCodeRoot]/webui/webapp/Core/src/org/netxms/ui/eclipse/console/ shows, how the login method is chosen, depending on the URL parameters provided upon accessing the login page of the WebUI.

Another tip: Service ticket validation needs to be done via HTTPS - a self-signed certificate is sufficient in a testing environment.

Feel free to ask, if questions come up 

Thank you and kind regards,
fbu

Hi all,

maybe someone can help me with the following:

I am currently trying to set up a SSO (Single sign on) solution for NetXMS using Apereo CAS. After several days of research and digging, I stumbled across a few lines in the WebUI source code, indicating that it has native SSO support, which was then confirmed by the change log of version 1.2.8 (https://www.netxms.org/forum/announcements/netxms-1-2-8-released/).

However, I could not find a single line of documentation nor a single forum thread on this topic, which is why I started one, by myself.

Currently, the following are the main questions related to this:

1. How does the Webapp handle the SSO session?
-> Is there a special URL to which CAS needs to redirect upon successful login?
-> Which attributes (if any) are needed from and for CAS?
-> Is SLO (single log out) also implemented?
2. How is the user management handled?
-> Does the user still need to be present in the NetXMS database?
-> If not, how are access rights handled (maybe via a special group?)
3. Can the official documentation be extended with this topic? It would really be cool to have a proper guide on how to set this up

I would be really happy, if someone could find the time to help me with this topic 

Thank you and kind regards,
fbu

Dear NetXMS team,

here is another thing that came to my mind when creating line charts in NetXMS:

Currently, NetXMS provides the ability to create "stacked" line chart diagrams, however, it only allows to stack all or none of the data from the source DCIs.

I think it would be useful to manually choose, which data to stack on top of each other and to have a more user friendly way of defining the stacking order (right now it is defined by the order the DCI sources).

Imagine the following: We have the four metrics TCP upstream, UDP upstream, HTTP upstream and overall upstream (downstream equivalent). To combine all four within one diagram, it should be possible to only stack UDP on top of TCP, as HTTP is a subset of the TCP traffic and the overall upstream is the superset of all three (which would only be added as a reference line).

What do you think about this idea?

Thanks and kind regards,
fbu 

Hi NetXMS team,

here's another idea of a potentially useful feature addition:

A NXSL function which allows to manually enable and disable DCIs or set their states. The function could be defined such as "setDCIStatus(dci, status)", where dci would be the DCI-object and status an integer with 0=Active, 1=Disabled and 2=Not Supported.

Maybe "setDCIStatusByID(dciID, node, status)", with dciID being an integer representing the DCI ID and node being a node-object as optional parameter, would also be possible.


The idea came to my mind, because a fairly large set of the nodes within my current setup is receiving monitoring data via NXAgent extension scripts from a centralized database, and are initially created via a big NXSL script under "Infrastructure Services", based on this data, as it is impossible to have a direct monitoring communication with NetXMS - not even with the use of NXAgent and proxy agents.

Because these devices might change in their states and different metrics temporarily might not return data any more, it would be useful to have a NXSL function, to disable those metrics via a script, as the "unsupported"-detection is also not working with this setup.

I know, template automatic apply rules can be used for this, however, once a template is un-applied from a node, the DCIs on it are gone and there is no way to access their history data via the management console until the template is re-applied, again.


What do you think, could this be useful if so, would it be difficult to implement?

Kind regards,
fbu

Dear NetXMS team,

as this is my first post on this forum, I shortly want to thank you for creating this awesome software product.

Over the course of the last few months, I got to research through NetXMS and learn, how most of its components and features are working.

During this time, there where some situations, in which I felt like there would be something useful missing.

Now, I want to share my ideas with you in this and the upcoming feature request posts, hoping that I can help to improve the tool for all users. 

############################

In my current setup, there are about 100 nodes to monitor, which are all bound to a container hierarchy under "Infrastructure Services".

For some of them, I created dashboards, containing only "Status Indicator" elements, to show the states of certain sets of nodes.

As this hierarchy currently has a depth of six, it can be pretty annoying to manually navigating through the containers, in order to access the object details of special nodes, each time their states are turning to something non-normal.

(To clarify: On each node's performance tab, there is a number of charts for its applied metrics, which is the preferred display option, as creating around 100 individual dashboards would be to time-consuming -> Which refers to one of my other feature requests of "Dashboard templates"  )

My idea would be to have a connection from certain dashboard elements (e.g. Status indicators) to the object details of the related node.

Basically, I came up with two potential solutions:

1. Enable right-click dropdown menus on these dashboard elements and add the menu entry "Show object details" - The way I see it is, that this is the simpler solution, as this menu entry is already available, when right-clicking a node in the "Service Dependency" view of a node.

2. Allow object details to be added as "Drill down objects" - I would assume this to be harder to implement, but it would also be kind of useful, as double clicking a status indicator would directly lead the user to the node's object details.

Thank you for considering my idea. Within the upcoming days, a few more will appear on the forum. 

Kind regards,
fbu