Project

General

Profile

Bug #8994

Two RRDDATA Sections in Restored Config Breaks Unit

Added by Chris Linstruth over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Backup / Restore
Target version:
Start date:
10/02/2018
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.4
Affected Architecture:

Description

Had a user present a configuration backup with two rrddata sections.

Looked like this:

<rrddata></rrddata>
<rrddata>
<rrddatafile>

The configuration uploaded but the config parser did not like it:

Fatal error: Uncaught Exception: XML error: RRDDATA at line 2179 cannot occur more than once in /etc/inc/xmlparse.inc:87 ...

Removing the empty rrddata section allowed the configuration to be uploaded and applied successfully.

It was an 18.0 (2.4.3_1) backup.

Associated revisions

Revision 93867844 (diff)
Added by Jim Pingle over 1 year ago

Avoid creating or parsing a second empty rrddata tag. Fixes #8994

Revision af145b11 (diff)
Added by Jim Pingle over 1 year ago

Avoid creating or parsing a second empty rrddata tag. Fixes #8994

(cherry picked from commit 9386784480f27d6b04ebf013f691522130a7f013)

History

#1 Updated by Paighton Bisconer over 1 year ago

I don't think this is limited to <rrddata>, any duplicate tag in the config will break imports, I've confirmed with <vlans> and <laggs> but I would think it applies to all duplicate sections.

#2 Updated by Jim Pingle over 1 year ago

  • Target version set to 2.4.4-p1

The rrddata case is special because of the way the backup process injects the data into the config before serving the backup to the user. The others could only happen by manual duplication.

I pushed a fix to avoid the problem case on both backup and restore.

#3 Updated by Jim Pingle over 1 year ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#4 Updated by Chris Linstruth over 1 year ago

Tested restoring the original problematic config.xml. It did restore successfully but there was no rrddata in the result after reboot.

#5 Updated by Jim Pingle over 1 year ago

  • Status changed from Feedback to Resolved

Did you look far enough back in time on the graphs to see data from the date before the backup was taken?

I took a backup with RRD, edited in the bad blank tag, reset RRD so everything was blank, then restored. The RRD data from the backup was restored as expected. Looks good here. I had to set the time span on the graph to a week to see anything meaningful in the graphs after restore since that was the last obvious spike.

#6 Updated by Chris Linstruth over 1 year ago

There was no rrd section in the resulting configuration at all.

#7 Updated by Jim Pingle over 1 year ago

It should be removed by the restore as its last act, since the data is taken out of config.xml and converted back into the RRD data file format expected by rrdtool. Checking the graphs is the best way to reliably know if the restore succeeded.

Only the backup should contain <rrddata> tags, they should never been seen in a live config.

Also available in: Atom PDF