Project

General

Profile

Actions
Copy link

Bug #13132

closed

Multiple ``<sshdata>`` or ``<rrddata>`` sections in ``config.xml`` lead to an XML parsing error during restore

Added by Viktor Gurov over 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Jim Pingle
Category:
Backup / Restore
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Default
Affected Version:
2.7.0
Affected Architecture:

Description

https://forum.netgate.com/topic/171966/not-posible-to-restore-backups:

I just tried to restore a backup from two days ago .......... which did work !

There must be errors in the way the backup is created and/or the backup restore software.

Below the errors I get

Louis
PS I had to restore for an older backup file (loosing changes of cause)

Fatal error: Uncaught Exception: XML error: SSHDATA at line 17301 cannot occur more than once in /etc/inc/xmlparse.inc:89 Stack trace: #0 [internal function]: startElement(Resource id #20, 'SSHDATA', Array) #1 /etc/inc/xmlparse.inc(188): xml_parse(Resource id #20, 'AjiJwzfL2fT7Oz1...', false) #2 /etc/inc/xmlparse.inc(149): parse_xml_config_raw('/conf/config.xm...', Array, 'false') #3 /etc/inc/config.lib.inc(134): parse_xml_config('/conf/config.xm...', Array) #4 /usr/local/pfSense/include/www/backup.inc(309): parse_config(true) #5 /usr/local/www/diag_backup.php(63): execPost(Array, Array) #6 {main} thrown in /etc/inc/xmlparse.inc on line 89 PHP ERROR: Type: 1, File: /etc/inc/xmlparse.inc, Line: 89, Message: Uncaught Exception: XML error: SSHDATA at line 17301 cannot occur more than once in /etc/inc/xmlparse.inc:89 Stack trace: #0 [internal function]: startElement(Resource id #20, 'SSHDATA', Array) #1 /etc/inc/xmlparse.inc(188): xml_parse(Resource id #20, 'AjiJwzfL2fT7Oz1...', false) #2 /etc/inc/xmlparse.inc(149): parse_xml_config_raw('/conf/config.xm...', Array, 'false') #3 /etc/inc/config.lib.inc(134): parse_xml_config('/conf/config.xm...', Array) #4 /usr/local/pfSense/include/www/backup.inc(309): parse_config(true) #5 /usr/local/www/diag_backup.php(63): execPost(Array, Array) #6 {main} thrown

similar to #8994

Files

PHP_errors-sshdata.log (9.6 KB) PHP_errors-sshdata.log Chris W, 12/02/2022 08:25 PM

Related issues

Related to Bug #8994: Two RRDDATA Sections in Restored Config Breaks UnitResolvedJim Pingle10/02/2018

Actions
Related to Bug #10508: Backup does not skip all RRD dataResolvedJim Pingle04/29/2020

Actions
Actions
Copy link
 #2

Updated by Jim Pingle over 2 years ago

  • Status changed from New to Pull Request Review
Actions
Copy link
 #3

Updated by Viktor Gurov over 2 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Danilo Zrenjanin over 2 years ago

Tested the patch against:

2.7.0-DEVELOPMENT (amd64)
built on Tue May 10 14:23:11 UTC 2022
FreeBSD 12.3-STABLE

I added an empty <sshdata></sshdata> in the running-config. When I took a backup, both the empty and the newly generated one existed in the backup config file, which broke the restoration process.

Please check.

Actions
Copy link
 #5

Updated by Danilo Zrenjanin over 2 years ago

  • Status changed from Feedback to Resolved

I was getting the error only when manually added sshdata tags in the following order:

<sshdata>
</sshdata>

The fix works fine since it should never be formatted that way in pfSense.

I am marking this ticket resolved.

Actions
Copy link
 #6

Updated by Jim Pingle over 2 years ago

  • Assignee changed from Viktor Gurov to Jim Pingle
  • % Done changed from 100 to 0
  • Status changed from Resolved to New
  • Plus Target Version changed from 22.05 to 22.11
  • Release Notes changed from Force Exclusion to Default

There is still some issue here as users are hitting this on 22.05 when restoring backups with two sections.

Actions
Copy link
 #7

Updated by Marcos M about 2 years ago

If the backup file has two <sshdata> sections, it will result in this error. The section should be automatically removed when being restored. If that doesn't happen, doing another backup will add the second <sshdata> section and lead to the error when restoring the file.

Actions
Copy link
 #8

Updated by Jim Pingle about 2 years ago

  • Plus Target Version changed from 22.11 to 23.01
Actions
Copy link
 #9

Updated by Nazar Mokrynskyi about 2 years ago

My 2.6.0-RELEASE (amd64) installation right now creates backups with extra sshdata section at the end for some reason and I hit this error.
If there is anything I can do to help understanding why this happens, please let me know.

Actions
Copy link
 #10

Updated by Jim Pingle about 2 years ago

  • Subject changed from Two SSHDATA Sections in Restored Config Breaks Unit to Multiple SSHDATA or RRDDATA sections in ``config.xml`` lead to an XML parsing error during restore
  • Status changed from New to In Progress

I see a couple problems here. One, code that removed duplicate sections on backup (#10508) got unintentionally removed at some point. Two, when restoring it doesn't also check for duplicate data sections, only for empty tags. If there are two populated data sections that will still fail.

I have fixes for both that seem to work with whatever I've thrown at them so far. I need to run some more tests yet but I should have a fix committed soon.

Actions
Copy link
 #11

Updated by Jim Pingle about 2 years ago

  • Related to Bug #8994: Two RRDDATA Sections in Restored Config Breaks Unit added
Actions
Copy link
 #12

Updated by Jim Pingle about 2 years ago

  • Related to Bug #10508: Backup does not skip all RRD data added
Actions
Copy link
 #13

Updated by Jim Pingle about 2 years ago

When testing this fix, be sure to test the following scenarios:

  • Add sections to the live config.xml before taking a backup, including:
    <sshdata></sshdata>
    <sshdata/>
    <sshdata>
        <sshkeyfile>
            <filename>blah.pub</filename>
            <xmldata>blahblahblah</xmldata>
        </sshkeyfile>
    </sshdata>

Be sure to rm /tmp/config.cache before making the backup.

  • Make a backup including SSH key data and see if any of the previous/junk sshdata sections are in the resulting backup -- it should only contain the new valid section.
  • Restore a backup containing only one valid sshdata section and make sure it results in the correct keys being used
  • Edit a backup and add the same junk data as before -- ABOVE a valid sshdata section in the config -- ensure the valid sshdata section is last -- and restore, then check the result
  • Edit a backup and copy a complete valid sshdata section with all its data in the configuration multiple times (2, 3, 4) and then restore each and check the result.

Retry the above with at least one RRD data file, though if it works for SSH it will work for RRD since the code path is identical.

I tried all of those cases here and each time it only resulted in the correct data being backed up or restored and no XML errors on backup or restore.

Actions
Copy link
 #14

Updated by Jim Pingle about 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #15

Updated by Chris W almost 2 years ago

I updated a virtual machine from 2.6 to 2.7.0.a.20221202.0600 and took a snapshot.
- SSH is enabled and the default admin user has a key in System > User Manager ... Authorized SSH Keys.
- Backups were of course taken with Skip RDD Data unchecked.

I wasn't able make the live file method work. After adding the junk sshdata section to the bottom of the live /conf/config.xml and running rm /tmp/config.cache , I then couldn't access any page on the GUI, including the dashboard because of PHP errors. Had to remove the duplicate sshdata or rdddata tags in the console shell to do anything further, and back at the Dashboard was a crash report to download. The sshdata report is the attached file, which is better formatted than pasting here what was shown in the browser window (same contents).

I restored to the 2.7 machine snapshot, blanked the admin's SSH key in the GUI, and took a config backup.

- Added the junk sshdata tags to the very bottom of the configuration file and was able to restore with no problems. The correct SSH key was back in the window on the admin user's settings. For both sshdata and rdddata, the junk sshdata and empty rdddata tags I created were removed in subsequent backups I took.

- Adding the junk sshdata above the valid one made no difference. The configuration restored successfully and the junk section was removed from the file.

- Duplicating the valid sshdata section in the configuration file four times also had no effect. Successful restore and reboot, and duplicates were removed.

Actions
Copy link
 #16

Updated by Jim Pingle almost 2 years ago

  • Status changed from Feedback to Resolved

That should be sufficient testing.

The "live" method can be done if you are logged in and sitting at the backup page already and just click the backup button after making the modifications, but it's not as important. As you can tell it's unlikely anyone would be in that situation since nothing would be functional. Adding just one of the junk/extra sections at a time would work, though.

Actions
Copy link
 #17

Updated by Jim Pingle almost 2 years ago

  • Subject changed from Multiple SSHDATA or RRDDATA sections in ``config.xml`` lead to an XML parsing error during restore to Multiple ``<sshdata>`` or ``<rrddata>`` sections in ``config.xml`` lead to an XML parsing error during restore

Updating subject for release notes.

Actions
Copy link

Also available in: Atom PDF