Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-7819

Requesting IPv6 resources on measurements rest endpoint fails



    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 16.0.2
    • Fix Version/s: 17.0.0
    • Component/s: REST
    • Security Level: Default (Default Security Scheme)
    • Labels:
    • Environment:
      Stock install on Debian Wheezy - running on a VM for testing.

      Using RRD files for backend storage, stored by IP address.


      When trying to access the measurement rest endpoint at a similar URL to the following:

      The endpoint responds with:

      'Fetch failed'

      on further digging, this seems to be an issue with colons being in the filename - when storing rrd files by IP address, with IPv6 addresses. The command which gets run underneath for the address above is:

      /usr/bin/rrdtool xport --step 300 --start 1438067466 --end 1438081866 DEF:1=/var/lib/opennms/rrd/response/fe80:0000:0000:0000:0000:0000:0000:0005/ssh.rrd:ssh:AVERAGE XPORT:1:1

      What this command needs to be is the following (atleast for it to work on the command line):

      /usr/bin/rrdtool xport --step 300 --start 1438067466 --end 1438081866 DEF:1=/var/lib/opennms/rrd/response/fe80\\:0000\\:0000\\:0000\\:0000\\:0000\\:0000\\:0005/ssh.rrd:ssh:AVERAGE XPORT:1:1

      The difference is the double escaping of the colons. In the manpage for RRDtool, specifically 'rrdgraph_data' it states:

      Remember to escape colons in the time specification!

      which seems to extend to the rrdfile name as well.

      On code digging, I assume the issue is at line 126 of features/rest-measurements-api/src/main/java/org/opennms/web/rest/measurements/fetch/RrdtoolXportFetchStrategy.java' in branch 'Release-16.0.1' (for some reason I dont have 'Release-16.0.2' available in my repo...) - the specific code is:

                          tempLabel, rrdFile, source.getAttribute(),

      However I dont know the codebase well enough to know if fixing the issue there is going to cause issues elsewhere - or if it should be fixed elsewhere.

      Hopefully this is enough information, however if you need any more, feel free to ask




            • Assignee:
              j-white Jesse White
              TBSliver Tom Bloor
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: