Modify

Opened 7 years ago

Closed 7 years ago

#633 closed bug (fixed)

Not all configuration is preserved on upgrades

Reported by: matthijs Owned by:
Priority: high Milestone: Firmware 2.3.7.0
Component: fon-base-firmware Version: 2.3.6.0 (Gari)
Severity: unknown
Cc: covert@…, JonTheNiceGuy, <jon@…> Hardware: both

Description

When you use a tarball for a web upgrade, the upgrade script preserves a number of config files through a tarball.

However, the files /etc/config/services and /etc/config/system are not preserved. The first contains the "fwall" setting for each service that opens up ports to the WAN side, the second contains the "pass_good" setting that stores the password strength (and is also needed to get SSH access on the WAN side).

Simply preserving those two config files will probably not work, since they also contain all kinds of configuration that should be replaced on an upgrade (e.g., when new firmware adds more services). A proper solution would probably need to move some settings around.

This bug has been noticed before, but probably got lost in the development. This ticket should keep it in the picture.

I've tested and confirmed this bug with upgrades to 2.3.6.

Attachments (0)

Change History (18)

comment:1 Changed 7 years ago by matthijs

  • Milestone Requests deleted

Milestone Requests deleted

comment:2 Changed 7 years ago by matthijs

  • Hardware set to both
  • Priority changed from normal to major
  • Status changed from new to confirmed
  • Version set to 2.3.6.0 (Gari)

comment:3 Changed 7 years ago by matthijs

  • Reporter changed from Matthijs Kooijman <matthijs@…> to matthijs

comment:4 Changed 7 years ago by matthijs

  • Milestone set to Firmware 2.3.7.0

comment:5 Changed 7 years ago by matthijs

A comment on the blog suggests that static DHCP leases are also lost on an upgrade. I haven't confirmed this yet, though.

comment:6 follow-up: Changed 7 years ago by John Covert "covert@…

Can we get a manual edit to these files to enable this?

/john

comment:7 in reply to: ↑ 6 Changed 7 years ago by anonymous

BTW, what I have for the WebGUI is below -- and a connection to https is accepted, but it goes to an authentication popup which doesn't accept the password which has been set.

config 'service' 'httpd'

option 'process' '1' option 'path' '/Apps/lucid' option 'boot' 'StartHttpd?' option 'order' '15' option 'name' 'WebGUI' option 'mdns' 'luci.service' list 'tcp_port' '443' option 'fwall' '1'

comment:8 Changed 7 years ago by matthijs

  • Severity set to unknown

I'm not sure I understand your question, John. Do you mean a temporary workaround?

As for not being able to access HTTPS, that should not be affected by this bug. Please double-check your password on the LAN side. The username should be "fonero". If you're still having problems with this, please open a new ticket to prevent cluttering up this one.

comment:9 follow-up: Changed 7 years ago by matthijs

  • Cc covert@… added

comment:10 in reply to: ↑ 9 Changed 7 years ago by John Covert

Replying to matthijs:

Yes, I was hoping someone would post a temporary workaround.

To enable ssh, I added:

option 'pass_good' '1'

to config 'fon' 'fon'

in /etc/config/system

But strangely, after doing that, a connect to port 443 is now refused, and I made no other changes.

comment:11 follow-up: Changed 7 years ago by matthijs

Adding pass_good does indeed work, but it is of course useless if you only have WAN access. An easier way is to just change the password again (into the same value, I think that just works).

I can't say why your HTTPS stops working. Perhaps you could try a reboot. If that doesn't work, please open a new ticket for that problem.

comment:12 in reply to: ↑ 11 Changed 7 years ago by John Covert

Replying to matthijs:

Adding pass_good does indeed work, but it is of course useless if you only have WAN access. An easier way is to just change the password again (into the same value, I think that just works).

Yes, resetting the password from the WebGUI and then rebooting does simply work. If you'd like to clean up this report, feel free to delete my previous comments, but since people searching with Google for why the WebGUI (which used to work on port 80) and ssh no longer work, Please leave my next comment with the workaround for them.

I thank you for the help in developing the workaround.

/john

comment:13 Changed 7 years ago by John Covert

WORKAROUND

Users affected by this should note the following:

On the WAN, only https is enabled for the WebGUI in order to protect you from password sniffers. The username is now "fonero".

To enable ssh, use the WebGUI to reset your password to a strong enough password (must have both letters and numbers) and then reboot for the ssh server to reread the options and enable WAN access.

/john

comment:14 Changed 7 years ago by matthijs

In 2.3.6.1, the upgrade script has been changed to preserve the pass_good variable. The firewall configuration is still lost, though.

comment:15 Changed 7 years ago by matthijs

Just to keep things together: It seems the /etc/config/firewall file (containing port forwardings and firewall policies) is also lost. The upgrade script does in fact try to preserve the file, but currently the default values in /etc/uci-defaults/firewall overwrite the preserved settings on boot. Changing the uci import to uci import -m (for merge), would help to preserve the port forwardings, but changes to the policies would still be overwritten.

comment:16 Changed 7 years ago by matthijs

  • Summary changed from Web upgrades break WAN access due to lost configuration to Not all configuration is preserved on upgrades

I'm making this report a bit more generic by not limiting it to WAN access anymore.

OldMan? reported more missing configuration: /etc/config/luci-ethers and the OpenVPN configuration (/etc/config/openvpn and /etc/openvpn, though the latter probably shouldn't be preserved entirely, probably only the "keys" subdirectory).

Fixing all of these probably requires a better setting backup than just a list of files to keep around (i.e., specific settings should be backed up instead of complete files only). This will probably require some extra support code.

comment:17 Changed 7 years ago by matthijs

  • Cc JonTheNiceGuy <jon@…> added

#910 is a duplicate of this bug.

comment:18 Changed 7 years ago by matthijs

  • Resolution set to fixed
  • Status changed from confirmed to closed

(In [1840]) luci: Make the settings backup complete.

Previously, the settings backup would include complete files in a tarball that becomes the backup. This missed out on a lot of settings, because they were contained in files that could not be backed up completely (because parts of them could vary between firmware versions).

This commit puts the creation of the tarball into a new script, /sbin/save-config.sh. Before creating the tarball, this script cherry-picks some settings from various files and generates uci commands to restore those settings. These commands are saved within the tarball, so they will be run after a settings restore.

Note that this save-config.sh script is also intended to be used inside released firmware tarballs, so all settings are also preserved on upgrades.

This commit adds the following settings to the backup:

  • The password strength (used for enabling SSH on WAN).
  • The firewall->applications settings.
  • The downloadmanager settings, logins and download list. These were already backed up, but now only the necessary settings are backed up instead of the entire file. These were also not preserved on an upgrade yet.
  • QoS settings.
  • OpenVPN settings, keys and clients.
  • The WebGUI language.
  • Static DHCP assignments.
  • The Flickr/Picasa/Youtube/Facebook? uploader settings.

Closes: #633

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.