Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#49101 - [ufw] update renders some servers unreachable

Attached to Project: Community Packages
Opened by John (graysky) - Tuesday, 26 April 2016, 19:28 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 07 May 2016, 14:17 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Kyle Keen (keenerd)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Upon updating from 0.34-1 to 0.35-1, the user created rules mentioned below (excerpt from pacman.log) are removed rather than copied into their new location which breaks the ability of hasty updates to connect via ssh. In order to do so, users will have to reconfigure the ufw on the box (see the wiki) enabling sshd access before rebooting. Failure to do this will lock them out of the box which is a horrible scenario for remote admins.

The package should either clearly warn users this will be happening at a minimum.

warning: /usr/lib/ufw/user6.rules saved as /usr/lib/ufw/user6.rules.pacsave
warning: /usr/lib/ufw/user.rules saved as /usr/lib/ufw/user.rules.pacsave

Additional info:
* package version(s) 0.35-1

Steps to reproduce:
Have a functional setup on a previous version and update to 0.35-1
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 07 May 2016, 14:17 GMT
Reason for closing:  Fixed
Additional comments about closing:  post-upgrade message added
Comment by John (graysky) - Tuesday, 26 April 2016, 19:51 GMT
From what I understand after studying the PKGBUILD and testing on an image, the package provided defaults are unchanged from 0.34-1 --> 0.35-1 so a post install scriptlet directing the user to either diff or simply drop-in-replace the following files would be helpful (the pacman warning does not tell the user where these files should go or if intervention is actually needed):

/usr/lib/ufw/user.rules.pacsave --> /etc/ufw/user.rules
/usr/lib/ufw/user6.rules.pacsave --> /etc/ufw/user6.rules

What is packaging policy about simply doing this automatically on updates? In other words, if no data loss will be experienced, why not simply move the edited files from /u/l/u to /e/u automatically?
Comment by Kyle Keen (keenerd) - Wednesday, 27 April 2016, 10:57 GMT
Ack, knew I should have let this sit in [testing].

Arch's normal policy is to put a message in the post install and you are expected to read it and act on it. You are absolutely correct that a warning is required.
Comment by Kyle Keen (keenerd) - Wednesday, 27 April 2016, 11:11 GMT
Thoughts on ufw-0.35-2? Here is the post-upgrade text:

>>>
>>> IMPORTANT UFW UPGRADE NOTICE
>>> ----------------------------
>>> Version 0.35 has moved several config files.
>>> You may need to copy your versions of the files
>>> to the new location.
>>> /usr/lib/ufw/user.rules.pacsave -> /etc/ufw/user.rules
>>> /usr/lib/ufw/user6.rules.pacsave -> /etc/ufw/user6.rules
>>>

I will ask around if this is a news-worthy item.
Comment by Kyle Keen (keenerd) - Wednesday, 27 April 2016, 13:19 GMT
Some TUs think it could have a news item, some devs think it shouldn't. Going with none for now. Don't perform "hasty updates" on servers (or ever) and read pacman's output.
Comment by John (graysky) - Wednesday, 27 April 2016, 19:21 GMT
The warning is nice and should be sufficient but seems like a pre_upgrade scriptlet could check for these and move them if they exist with no harm, no? Either way is good. Thanks for the quick fix and for maintaining!
Comment by Jamin Collins (jamincollins) - Saturday, 30 April 2016, 18:01 GMT
I'm curious why the files weren't simply moved by the package. From what I've seen simply moving the files is the right thing to do and the existing files seem to work just fine.

Not doing so effectively leaves a ticking time bomb for users that could result in locking them out of the box (remote access no longer allowed).

Loading...