[Touch-packages] [Bug 2075395] Re: status description lists "in" interface in "to" column
Hi, thank you for reporting an issue. This is discussed in the ufw man page: " status - show status of firewall and ufw managed rules. Use status verbose for extra information. In the status output, 'Anywhere' is synonymous with 'any', 0.0.0.0/0 (IPv4) and ::/0 (IPv6). Note that when using status, there is a subtle difference when reporting interfaces. For example, if the following rules are added: ufw allow in on eth0 from 192.168.0.0/16 ufw allow out on eth1 to 10.0.0.0/8 ufw route allow in on eth0 out on eth1 to 10.0.0.0/8 from 192.168.0.0/16 ufw limit /tcp comment 'SSH port' ufw status will output: To Action From -- -- Anywhere on eth0 ALLOW 192.168.0.0/16 10.0.0.0/8 ALLOW OUT Anywhere on eth1 10.0.0.0/8 on eth1 ALLOW FWD 192.168.0.0/16 on eth0 Anywhere LIMIT Anywhere # SSH port For the input and output rules, the interface is reported relative to the firewall system as an endpoint, whereas with route rules, the interface is reported relative to the direction packets flow through the firewall. " You stated: " -A ufw-user-input -i serviceA -p tcp --dport 3306 -j ACCEPT So far everything is good. The iptables rule is generated as expected and traffic is allowed. But I find the "ufw status verbose" output very confusing: ``` To Action From -- -- 3306/tcp on serviceA ALLOW IN Anywhere # ServiceA: MySQL access ``` Here it looks like we are allowing traffic To port 3306 on serviceA (from anywhere). " The "-A ufw-user-input -i serviceA -p tcp --dport 3306 -j ACCEPT" rule literally says "append to the ufw-user-input chain a rule that says input on interface 'serviceA' to port 3306/tcp should be accepted" and so your interpretation of the ufw verbose status is correct. I find the proposal to change this more confusing personally but ultimately I think whether one is more clear or not is subjective. ufw is operating as documented and I fear changing the output after so many years would be far to disruptive for users. I'm going to mark this as Opinion. Thanks again for your report. ** Changed in: ufw Status: New => Opinion ** Changed in: ufw (Ubuntu) Status: New => Opinion -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2075395 Title: status description lists "in" interface in "to" column Status in ufw: Opinion Status in ufw package in Ubuntu: Opinion Bug description: Hello! I've found what I think might be a bug in the `ufw status [verbose]` output. **Background** I have an SQL server running directly on the host listening on port 3306. I have serviceA running in a Docker container, attached to bridge "serviceA". I would like to allow serviceA to talk to the SQL server on port 3306/tcp. **UFW command** `ufw allow in on serviceA to any port 3306 proto tcp comment "ServiceA: MySQL access"` **user.rules** ``` ### tuple ### allow tcp 3306 0.0.0.0/0 any 0.0.0.0/0 in_serviceA comment=53657276696365413a204d7953514c20616363657373 -A ufw-user-input -i serviceA -p tcp --dport 3306 -j ACCEPT ``` So far everything is good. The iptables rule is generated as expected and traffic is allowed. But I find the "ufw status verbose" output very confusing: ``` To Action From -- -- 3306/tcp on serviceA ALLOW INAnywhere # ServiceA: MySQL access ``` Here it looks like we are allowing traffic To port 3306 on serviceA (from anywhere). Instead I would expect the following output: ``` To Action From -- -- 3306/tcp ALLOW INAnywhere on serviceA # ServiceA: MySQL access ``` This is very confusing and could make administrators think that the system is secure, when it's not, or lead to lots of unnecessary troubleshooting. I'm using UFW 0.36.2 on Ubuntu 24.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2075395/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
Note that after this fix, snapd in containers needs to be at >= 2.62 for apparmor policy to load (snapd's snapd-apparmor needs the corresponding fix as this bug). This is currently in the candidate channel. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2060535 Title: apparmor's is_container_with_internal_policy() does not recognize incus Status in apparmor package in Ubuntu: Fix Released Status in apparmor source package in Bionic: Triaged Status in apparmor source package in Focal: Triaged Status in apparmor source package in Jammy: Triaged Status in apparmor source package in Noble: Fix Released Bug description: apparmor is not loading for Ubuntu containers under incus. This is due to `/lib/apparmor/rc.apparmor.functions` (18.04 uses `/lib/apparmor/functions`): is_container_with_internal_policy() { # this function is sometimes called independently of # is_apparmor_loaded(), so also define this here. local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked" local ns_name_path="${SFS_MOUNTPOINT}/.ns_name" local ns_stacked local ns_name if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then return 1 fi read -r ns_stacked < "$ns_stacked_path" if [ "$ns_stacked" != "yes" ]; then return 1 fi # LXD and LXC set up AppArmor namespaces starting with "lxd-" and # "lxc-", respectively. Return non-zero for all other namespace # identifiers. read -r ns_name < "$ns_name_path" if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ [ "${ns_name#lxc-*}" = "$ns_name" ]; then return 1 fi return 0 } This can be fixed by adjusting it to have: # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-", # "lxc-", and "incus-" respectively. Return non-zero for all other namespace # identifiers. read -r ns_name < "$ns_name_path" if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ [ "${ns_name#lxc-*}" = "$ns_name" ] && \ [ "${ns_name#incus-*}" = "$ns_name" ] ; then return 1 fi References: * https://github.com/lxc/incus/issues/740 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
This is already available in noble. An SRU for jammy and focal (and ideally bionic) would be nice. ** Changed in: apparmor (Ubuntu Bionic) Status: New => Triaged ** Changed in: apparmor (Ubuntu Focal) Status: New => Triaged ** Changed in: apparmor (Ubuntu Jammy) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2060535 Title: apparmor's is_container_with_internal_policy() does not recognize incus Status in apparmor package in Ubuntu: Fix Released Status in apparmor source package in Bionic: Triaged Status in apparmor source package in Focal: Triaged Status in apparmor source package in Jammy: Triaged Status in apparmor source package in Noble: Fix Released Bug description: apparmor is not loading for Ubuntu containers under incus. This is due to `/lib/apparmor/rc.apparmor.functions` (18.04 uses `/lib/apparmor/functions`): is_container_with_internal_policy() { # this function is sometimes called independently of # is_apparmor_loaded(), so also define this here. local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked" local ns_name_path="${SFS_MOUNTPOINT}/.ns_name" local ns_stacked local ns_name if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then return 1 fi read -r ns_stacked < "$ns_stacked_path" if [ "$ns_stacked" != "yes" ]; then return 1 fi # LXD and LXC set up AppArmor namespaces starting with "lxd-" and # "lxc-", respectively. Return non-zero for all other namespace # identifiers. read -r ns_name < "$ns_name_path" if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ [ "${ns_name#lxc-*}" = "$ns_name" ]; then return 1 fi return 0 } This can be fixed by adjusting it to have: # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-", # "lxc-", and "incus-" respectively. Return non-zero for all other namespace # identifiers. read -r ns_name < "$ns_name_path" if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ [ "${ns_name#lxc-*}" = "$ns_name" ] && \ [ "${ns_name#incus-*}" = "$ns_name" ] ; then return 1 fi References: * https://github.com/lxc/incus/issues/740 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
https://gitlab.com/apparmor/apparmor/-/commit/659a187687fc8802045c113da0d12bc4b836d591 was committed upstream for this. It would be nice if this was SRU'd. ** Changed in: apparmor (Ubuntu Noble) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2060535 Title: apparmor's is_container_with_internal_policy() does not recognize incus Status in apparmor package in Ubuntu: Fix Released Status in apparmor source package in Bionic: Triaged Status in apparmor source package in Focal: Triaged Status in apparmor source package in Jammy: Triaged Status in apparmor source package in Noble: Fix Released Bug description: apparmor is not loading for Ubuntu containers under incus. This is due to `/lib/apparmor/rc.apparmor.functions` (18.04 uses `/lib/apparmor/functions`): is_container_with_internal_policy() { # this function is sometimes called independently of # is_apparmor_loaded(), so also define this here. local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked" local ns_name_path="${SFS_MOUNTPOINT}/.ns_name" local ns_stacked local ns_name if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then return 1 fi read -r ns_stacked < "$ns_stacked_path" if [ "$ns_stacked" != "yes" ]; then return 1 fi # LXD and LXC set up AppArmor namespaces starting with "lxd-" and # "lxc-", respectively. Return non-zero for all other namespace # identifiers. read -r ns_name < "$ns_name_path" if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ [ "${ns_name#lxc-*}" = "$ns_name" ]; then return 1 fi return 0 } This can be fixed by adjusting it to have: # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-", # "lxc-", and "incus-" respectively. Return non-zero for all other namespace # identifiers. read -r ns_name < "$ns_name_path" if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ [ "${ns_name#lxc-*}" = "$ns_name" ] && \ [ "${ns_name#incus-*}" = "$ns_name" ] ; then return 1 fi References: * https://github.com/lxc/incus/issues/740 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2060535] [NEW] apparmor's is_container_with_internal_policy() does not recognize incus
Public bug reported: apparmor is not loading for Ubuntu containers under incus. This is due to `/lib/apparmor/rc.apparmor.functions` (18.04 uses `/lib/apparmor/functions`): is_container_with_internal_policy() { # this function is sometimes called independently of # is_apparmor_loaded(), so also define this here. local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked" local ns_name_path="${SFS_MOUNTPOINT}/.ns_name" local ns_stacked local ns_name if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then return 1 fi read -r ns_stacked < "$ns_stacked_path" if [ "$ns_stacked" != "yes" ]; then return 1 fi # LXD and LXC set up AppArmor namespaces starting with "lxd-" and # "lxc-", respectively. Return non-zero for all other namespace # identifiers. read -r ns_name < "$ns_name_path" if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ [ "${ns_name#lxc-*}" = "$ns_name" ]; then return 1 fi return 0 } This can be fixed by adjusting it to have: # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-", # "lxc-", and "incus-" respectively. Return non-zero for all other namespace # identifiers. read -r ns_name < "$ns_name_path" if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ [ "${ns_name#lxc-*}" = "$ns_name" ] && \ [ "${ns_name#incus-*}" = "$ns_name" ] ; then return 1 fi References: * https://github.com/lxc/incus/issues/740 ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Affects: apparmor (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: apparmor (Ubuntu Focal) Importance: Undecided Status: New ** Affects: apparmor (Ubuntu Jammy) Importance: Undecided Status: New ** Affects: apparmor (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: apparmor (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: apparmor (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: apparmor (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: apparmor (Ubuntu Jammy) Importance: Undecided Status: New ** Description changed: apparmor is not loading for Ubuntu containers under incus. This is due to `/lib/apparmor/rc.apparmor.functions` (18.04 uses `/lib/apparmor/functions`): + is_container_with_internal_policy() { + # this function is sometimes called independently of + # is_apparmor_loaded(), so also define this here. + local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked" + local ns_name_path="${SFS_MOUNTPOINT}/.ns_name" + local ns_stacked + local ns_name - is_container_with_internal_policy() { - # this function is sometimes called independently of - # is_apparmor_loaded(), so also define this here. - local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked" - local ns_name_path="${SFS_MOUNTPOINT}/.ns_name" - local ns_stacked - local ns_name + if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then + return 1 + fi - if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then - return 1 - fi + read -r ns_stacked < "$ns_stacked_path" + if [ "$ns_stacked" != "yes" ]; then + return 1 + fi - read -r ns_stacked < "$ns_stacked_path" - if [ "$ns_stacked" != "yes" ]; then - return 1 - fi + # LXD and LXC set up AppArmor namespaces starting with "lxd-" and + # "lxc-", respectively. Return non-zero for all other namespace + # identifiers. + read -r ns_name < "$ns_name_path" + if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ +[ "${ns_name#lxc-*}" = "$ns_name" ]; then + return 1 + fi - # LXD and LXC set up AppArmor namespaces starting with "lxd-" and - # "lxc-", respectively. Return non-zero for all other namespace - # identifiers. - read -r ns_name < "$ns_name_path" - if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ - [ "${ns_name#lxc-*}" = "$ns_name" ]; then - return 1 - fi - - return 0 + return 0 } - ``` This can be fixed by adjusting it to have: - ``` - # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-", - # "lxc-", and "incus-" respectively. Return non-zero for all other namespace - # identifiers. - read -r ns_name < "$ns_name_path" - if [ "${ns_name#lxd-*}" = "$ns_name" ] && \ - [ "${ns_name#lxc-*}" = "$ns_name" ] && \ - [ "${ns_name#incus-*}" = "$ns_name" ] ; then - return 1 - fi - return 0 + # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-", + # "lxc-", and "incus-" respectively. Return non-zero for all other namespace + # identifiers. + read -r ns_name < "$ns_name_path" +
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
Ok, https://autopkgtest.ubuntu.com/results/autopkgtest- noble/noble/amd64/u/ufw/20240211_163608_4a05d@/log.gz (the one for python3-defaults/3.12.1-0ubuntu1) passed with 0.36.2-4 so hopefully this bug will stay closed! :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw package in Debian: Fix Released Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
> From my reading (https://github.com/pypa/setuptools/issues/3661), installing python3-setuptools instead of python3-distutils should be sufficient, with a new enough setuptools, which we have in noble. Uploaded 0.36.2-4 to unstable, it migrated to noble-proposed and awaiting autopkgtests. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: Fix Released Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
>From my reading (https://github.com/pypa/setuptools/issues/3661), installing python3-setuptools instead of python3-distutils should be sufficient, with a new enough setuptools, which we have in noble. ** Bug watch added: github.com/pypa/setuptools/issues #3661 https://github.com/pypa/setuptools/issues/3661 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: Fix Released Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
I can also reproduce if I have python3-setuptools installed, but don't have python3-distutils installed and use SETUPTOOLS_USE_DISTUTILS=stdlib. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: Fix Released Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
Mathias, So, this is a little hard to fix with the archive packages now and I'm not sure where people are going with the 3.12 updates. I can get python3.12 reasonably easily enough but debian/tests/control has: # root unittests under python3 Tests: root-unittest Depends: iptables, netbase, procps, sed, python3, python3-distutils Restrictions: needs-root, allow-stderr, isolation-machine, build-needed, rw-build-tree # unittests under python3 Tests: unittest Depends: iptables, netbase, procps, sed, python3, python3-distutils, dh-python, Both of these are installing python3-distutils, but only one is installing dh-python. dh-python depends on both python3-distutils and python3-setuptools. Presumably dh-python is going to stop installing python3-distutils? However, python3-setuptools *also* depends on python3-distutils (which the setuptools package provides). As it stands, ufw 0.36.2-3 builds fine with what is in noble now and should in what is in noble-proposed now (indeed, it passed its autopkgtests and migrated recently). Where was this test result coming from? What is the goal of that build? Since the autopkgtests are declaring that python3-distutils be installed, we shouldn't be getting the the error since it should be there. I can create an artificial situation and do 'sudo dpkg --force-depends --purge python3-distutils' (but is this even valid?) but even in that situation, python3-setuptools in the archive being installed still allows the import to work. Only if I do 'sudo dpkg --force-depends --purge python3-distutils python3-setuptools' can I reproduce the import error, but the fix is to use python3-setuptools -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: Fix Released Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
fyi, I plan to fix this but probably not til next week. My plan is to adjst the import to conditionally (or fall back to) import setuptools.distutil and then adjust the Build-Depends/autopkgtests to specify python3-setuptools. I may do something else longer term, but that should get things going again. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: Fix Released Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
https://launchpad.net/ubuntu/+source/ufw/0.36.2-3/+build/27739360 built fine. Closing. ** Changed in: ufw (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw package in Debian: New Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
I'll upload a fix for that tomorrow. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: In Progress Status in ufw package in Debian: Fix Released Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
Another fix is needed for python 3.12: Performing tests 'good/reports' - installing - result: FAIL: 4a5,8 > /<>/tests/testarea/lib/python/ufw/util.py:483: SyntaxWarning: > invalid escape sequence '\.' > quads = re.split('\.', nm) > /<>/tests/testarea/lib/python/ufw/util.py:745: SyntaxWarning: > invalid escape sequence '\s' > tmp = re.split('\s', out) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: In Progress Status in ufw package in Debian: Fix Released Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
** Changed in: ufw Status: New => Fix Committed ** Changed in: ufw Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Changed in: ufw (Ubuntu) Status: Confirmed => In Progress ** Changed in: ufw (Ubuntu) Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Bug watch added: Debian Bug tracker #1061763 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061763 ** Also affects: ufw (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061763 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2051540 Title: ufw ftbfs with Python 3.12 as default Status in ufw: Fix Committed Status in ufw package in Ubuntu: In Progress Status in ufw package in Debian: Unknown Bug description: == ERROR: test_ufwcommand_parse (tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse) Test UFWCommand.parse() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 88, in test_ufwcommand_parse self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action)) ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? == ERROR: test_ufwcommand_rule_get_command (tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command) Test UFWCommand(Route)Rule.get_command() -- Traceback (most recent call last): File "/<>/tests/unit/test_parser.py", line 375, in test_ufwcommand_rule_get_command self.assertEquals(len(errors), 0, ^ AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? -- Ran 24 tests in 7.584s FAILED (errors=9) test_skeleton test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example) Test example dummy test ... ok -- Ran 1 test in 0.000s OK To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2051540/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
> If you are using NetworkManager, then systemd-networkd.service (and associated units like systemd-networkd-wait-online.service) should NOT be enabled. With the caveat that I am not sure why you have systemd- networkd enabled in the first place, I would recommend that you simply disable it: > $ systemctl disable --now systemd-networkd.service > This will also have the effect of disabling systemd-networkd-wait- online.service. Ok, I've done this. It is easy enough to re-enable if I need to test anything wrt the bug. This resolved the issue for me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
>> On Ubuntu 22.04 desktop system using network-manager > To be clear, does this mean you have no network interfaces that are configured to use networkd? Hey Steve :) So, this system is quite old. I think the first install was 16.04 and it went through a bunch of upgrades (mostly interim until 20.04 and then to 22.04). It would not surprise me if things weren't pristine. I'll give some info and you can tell me what else to provide: $ cat /etc/netplan/01-network-manager-all.yaml # Let NetworkManager manage all devices on this system network: version: 2 renderer: NetworkManager $ sudo netplan get all network: version: 2 renderer: NetworkManager $ ls /etc/systemd/network $ $ cat /etc/systemd/networkd.conf # This file is part of systemd. ... # See networkd.conf(5) for details. [Network] #SpeedMeter=no #SpeedMeterIntervalSec=10sec #ManageForeignRoutingPolicyRules=yes #ManageForeignRoutes=yes #RouteTable= [DHCPv4] #DUIDType=vendor #DUIDRawData= [DHCPv6] #DUIDType=vendor #DUIDRawData= $ sudo systemctl status systemd-networkd ● systemd-networkd.service - Network Configuration Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2023-09-17 12:13:48 CDT; 1 day 2h ago TriggeredBy: ● systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 1442 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 18857) Memory: 2.7M CPU: 1.387s CGroup: /system.slice/systemd-networkd.service └─1442 /lib/systemd/systemd-networkd Sep 17 14:33:42 systemd-networkd[1442]: wlp58s0: Lost carrier Sep 17 14:33:43 systemd-networkd[1442]: wlp58s0: Gained carrier Sep 17 16:44:57 systemd-networkd[1442]: lxd0: Link UP Sep 17 16:45:02 systemd-networkd[1442]: veth8afa41ff: Link UP Sep 17 16:45:02 systemd-networkd[1442]: veth8afa41ff: Gained carrier Sep 17 16:45:02 systemd-networkd[1442]: lxd0: Gained carrier Sep 17 16:45:02 systemd-networkd[1442]: lxd0: Gained IPv6LL Sep 17 17:32:49 systemd-networkd[1442]: wlp58s0: Lost carrier Sep 17 17:32:50 systemd-networkd[1442]: wlp58s0: Connected WiFi access point: () Sep 17 17:32:50 systemd-networkd[1442]: wlp58s0: Gained carrier I don't recall enabling systemd-networkd, but a lot has happened over the last 7 years, 4.5 of those while developing Ubuntu. :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
** Description changed: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents - logins (GDM, ssh, console) until it does. This seems to be introduced by - the change for + logins (GDM, ssh, console) until it does time out. This seems to be + introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: New Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] [NEW] systemd wait-online now times out after jammy and lunar upgrade
Public bug reported: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: regression-update ** Description changed: On Ubuntu 22.04 and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 - also mentioned the problem. + also mentioned the problem on Lunar. ** Description changed: - On Ubuntu 22.04 and upgrading to systemd 249.11-0ubuntu3.10, wait-online - now times out which prevents logins (GDM, ssh, console) until it does. - This seems to be introduced by the change for + On Ubuntu 22.04 desktop system using network-manager and upgrading to + systemd 249.11-0ubuntu3.10, wait-online now times out which prevents + logins (GDM, ssh, console) until it does. This seems to be introduced by + the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. ** Summary changed: - systemd 249.11-0ubuntu3.10 wait-online now times out after upgrade + systemd wait-online now times out after jammy and lunar upgrade ** Tags added: regression-update -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: New Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982218] Re: wait-online does not correctly identify managed links
> Somehow, wait-online now times out, while it didn't before this update. I just created https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358 to track this. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1982218 Title: wait-online does not correctly identify managed links Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Status in systemd source package in Lunar: Fix Released Bug description: [Impact] systemd-networkd-wait-online will exit prematurely when the --any flag is passed, due to an incorrect patch in Ubuntu that is supposed to make systemd-networkd-wait-online exit when *no* links are managed. [Test Plan] This test uses a VM managed by libvirt. In this scenario we have the "default" network which provides DHCP to the VM, and the "no-dhcp" network which does not provide DHCP. To setup the VM (this assumes Jammy, but the same steps apply for Lunar using appropriate names and install media): 1. Define the default and no-dhcp networks: $ cat > /tmp/net-default.xml << EOF default 04260896-2701-422d-84e0-8e0df1122db3 $ virsh net-create --file /tmp/net-default.xml $ cat > /tmp/net-default.xml << EOF no-dhcp 2c047740-caab-4c90-8421-70da6732a759 $ virsh net-create --file /tmp/net-no-dhcp.xml $ virsh net-start --network default $ virst net-start --network no-dhcp 2. Create the VM using virt-install: virt-install \ --connect=qemu:///system \ --name=jammy \ --arch=x86_64 \ --cpu=host-passthrough \ --ram=4096 \ --vcpus=1 \ --disk=path=/var/lib/libvirt/images/jammy.qcow2,size=24,format=qcow2,sparse=true,bus=virtio \ --virt-type=kvm \ --accelerate \ --hvm \ --cdrom=/tmp/ubuntu-22.04.2-live-server-amd64.iso \ --os-type=linux \ --os-variant=generic \ --graphics=spice \ --input=tablet \ --network=network=default,model=virtio \ --video=qxl \ --noreboot 3. Complete the installation steps. Reboot the VM. Run the test: 1. Detach the network interface so that the test starts with no interfaces attached: $ virsh detach-interface $VM network 2. In the VM, write a network config for all en* links to use DHCP: $ cat > /etc/systemd/network/10-dhcp.network << EOF [Match] Name=en* [Network] DHCP=yes EOF 3. Restart systemd-networkd: $ systemctl restart systemd-networkd 4. On the host, attach an interface to the VM on the no-dhcp network, so that an IP is not assigned: $ virsh attach-interface $VM network no-dhcp 5. Back in the VM, confirm that the device is in the degraded/configuring state: $ networkctl networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 8 ens3 etherdegradedconfiguring 2 links listed. 6. Run systemd-networkd-wait-online --any, and confirm that it does timeout instead of returning while the device is is still not configured: $ /lib/systemd/systemd-networkd-wait-online --any --timeout=10 Timeout occurred while waiting for network connectivity. 7. Confirm that the device is STILL in the degraded/configuring state: $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 8 ens3 etherdegradedconfiguring 2 links listed. 8. Now, leave systemd-network-wait-online --any running while we attach another interface: $ /lib/systemd/systemd-networkd-wait-online --any --timeout=0 9. On the host, attach another interface to the VM on the default network, so that DHCP assigns the interface an IP: $ virsh attach-interface $VM network default 10. Back in the VM, the systemd-networkd-wait-online process should have exited with success, and networkctl should show the new link as configured, while the old one is still configuring: $ /lib/systemd/systemd-networkd-wait-online --any --timeout=0 $ echo $? 0 $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 8 ens3 etherdegradedconfiguring 9 ens9 etherroutableconfigured 3 links listed. [Where problems could occur] This patch we want to remove is totally confined to systemd-networkd- wait-online, so that's where we would see problems. From what I can tell, the patch is no longer doing what it was intended to do. E.g. running systemd-networkd-wait-online on a desktop install, where systemd-networkd does not manage links, results in a timeout. It only works with the --any flag, but the --any flag did not exist when the patch was written. If a user was relying on --any to make systemd- networkd-wait-online exit when no links are managed, they will see a change in behavior as a result of this change. However, the
[Touch-packages] [Bug 2033560] Re: package ufw 0.36.1-4ubuntu0.1 failed to install/upgrade: o subprocesso instalado, do pacote ufw, o script post-installation retornou erro do status de saída 10
The DpkgHistoryLog.txt has lots of entries that aren't ufw specific: Start-Date: 2023-08-16 18:22:34 Commandline: aptdaemon role='role-commit-packages' sender=':1.134' Upgrade: libgpgmepp6:amd64 (1.16.0-1.2ubuntu4, 1.16.0-1.2ubuntu4.1), libgl1-amber-dri:amd64 (21.3.7-0ubuntu1, 21.3.9-0ubuntu1~22.04.1), libglx-mesa0:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libglx-mesa0:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), python3-distupgrade:amd64 (1:22.04.16, 1:22.04.17), language-pack-en-base:amd64 (1:22.04+20230209, 1:22.04+20230801), libgtk-4-common:amd64 (4.6.6+ds-0ubuntu1, 4.6.9+ds-0ubuntu0.22.04.1), libunwind8:amd64 (1.3.2-2build2, 1.3.2-2build2.1), libldap-common:amd64 (2.5.15+dfsg-0ubuntu0.22.04.1, 2.5.16+dfsg-0ubuntu0.22.04.1), ufw:amd64 (0.36.1-4build1, 0.36.1-4ubuntu0.1), libgbm1:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgbm1:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), ubuntu-release-upgrader-gtk:amd64 (1:22.04.16, 1:22.04.17), libmutter-10-0:amd64 (42.9-0ubuntu1, 42.9-0ubuntu4), libwbclient0:amd64 (2:4.15.13+dfsg-0ubuntu1.2, 2:4.15.13+dfsg-0ubuntu1.3), language-pack-en:amd64 (1:22.04+20230209, 1:22.04+ 20230801), language-pack-pt:amd64 (1:22.04+20230209, 1:22.04+20230801), language-pack-gnome-en-base:amd64 (1:22.04+20230209, 1:22.04+20230801), libsmbclient:amd64 (2:4.15.13+dfsg-0ubuntu1.2, 2:4.15.13+dfsg-0ubuntu1.3), libxatracker2:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), gir1.2-gtk-4.0:amd64 (4.6.6+ds-0ubuntu1, 4.6.9+ds-0ubuntu0.22.04.1), mutter-common:amd64 (42.9-0ubuntu1, 42.9-0ubuntu4), python-apt-common:amd64 (2.4.0ubuntu1, 2.4.0ubuntu2), libgpgme11:amd64 (1.16.0-1.2ubuntu4, 1.16.0-1.2ubuntu4.1), language-pack-pt-base:amd64 (1:22.04+20230209, 1:22.04+20230801), libldap-2.5-0:amd64 (2.5.15+dfsg-0ubuntu0.22.04.1, 2.5.16+dfsg-0ubuntu0.22.04.1), mesa-va-drivers:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgl1-mesa-dri:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgl1-mesa-dri:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), terraform:amd64 (1.5.4-1, 1.5.5-1), gir1.2-mutter-10:amd64 (42.9-0ubuntu1, 42.9-0ubuntu4), mesa-vulkan-drivers:amd64 (22.2 .5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), mesa-vulkan-drivers:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), base-files:amd64 (12ubuntu4.3, 12ubuntu4.4), python3-apt:amd64 (2.4.0ubuntu1, 2.4.0ubuntu2), python3-distro-info:amd64 (1.1build1, 1.1ubuntu0.1), linux-firmware:amd64 (20220329.git681281e4-0ubuntu3.14, 20220329.git681281e4-0ubuntu3.17), language-pack-gnome-pt-base:amd64 (1:22.04+20230209, 1:22.04+20230801), distro-info:amd64 (1.1build1, 1.1ubuntu0.1), libglapi-mesa:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libglapi-mesa:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgtk-4-1:amd64 (4.6.6+ds-0ubuntu1, 4.6.9+ds-0ubuntu0.22.04.1), samba-libs:amd64 (2:4.15.13+dfsg-0ubuntu1.2, 2:4.15.13+dfsg-0ubuntu1.3), language-pack-gnome-en:amd64 (1:22.04+20230209, 1:22.04+20230801), language-pack-gnome-pt:amd64 (1:22.04+20230209, 1:22.04+20230801), thermald:amd64 (2.4.9-1ubuntu0.2, 2.4.9-1ubuntu0.3), libegl-mesa0:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04. 1), libegl-mesa0:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgtk-4-bin:amd64 (4.6.6+ds-0ubuntu1, 4.6.9+ds-0ubuntu0.22.04.1), ubuntu-release-upgrader-core:amd64 (1:22.04.16, 1:22.04.17) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-16 18:25:33 Start-Date: 2023-08-18 17:51:20 Commandline: /usr/bin/unattended-upgrade Upgrade: ghostscript-x:amd64 (9.55.0~dfsg1-0ubuntu5.3, 9.55.0~dfsg1-0ubuntu5.4), libgs9-common:amd64 (9.55.0~dfsg1-0ubuntu5.3, 9.55.0~dfsg1-0ubuntu5.4), ghostscript:amd64 (9.55.0~dfsg1-0ubuntu5.3, 9.55.0~dfsg1-0ubuntu5.4), libgs9:amd64 (9.55.0~dfsg1-0ubuntu5.3, 9.55.0~dfsg1-0ubuntu5.4) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-18 17:51:22 Start-Date: 2023-08-21 18:14:13 Commandline: apt-get install -y gnupg software-properties-common Requested-By: anderson (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-21 18:14:14 Start-Date: 2023-08-21 18:23:11 Commandline: apt install terraform Requested-By: anderson (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-21 18:23:12 Start-Date: 2023-08-21 18:24:55 Commandline: apt-get -f install Requested-By: anderson (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-21 18:24:55 Start-Date: 2023-08-21 18:30:10 Commandline: apt -f install Requested-By: anderson (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-21 18:30:10 Start-Date: 2023-08-21 18:38:25 Commandline: aptdaemon role='role-commit-packages' sender=':1.233' Upgrade: initramfs-tools-core:amd64 (0.140ubuntu13.2, 0.140ubuntu13.4), apt:a
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
Note that autopkg tests for ufw test various aspects of normal ufw usage, including ufw enable. I also performed the testing for this issue on focal: $ apt-cache policy ufw ufw: Installed: 0.36-6ubuntu1 Candidate: 0.36-6ubuntu1 Version table: *** 0.36-6ubuntu1 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 0.36-6 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages # recreate the WSL2 scenario by having the parent shell contain 'Relay(NNN)'. # This could be done various ways, but the easiest is to create a script named # /tmp/Relay(230) to launch ufw: $ cat < "/tmp/Relay(230)" #!/bin/bash sudo ufw enable EOM $ chmod 755 "/tmp/Relay(230)" # before the update $ "/tmp/Relay(230)" Traceback (most recent call last): File "/usr/lib/python3/dist-packages/ufw/util.py", line 444, in under_ssh ppid = get_ppid(pid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in get_ppid ppid = open(name).readlines()[0].split(')')[1].split()[1] IndexError: list index out of range During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/sbin/ufw", line 138, in not ui.continue_under_ssh(): File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 900, in continue_under_ssh if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover File "/usr/lib/python3/dist-packages/ufw/util.py", line 474, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 474, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 451, in under_ssh raise ValueError(err_msg) ValueError: Couldn't find parent pid for '1782' # after the update $ cat
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
Note that autopkg tests for ufw test various aspects of normal ufw usage, including ufw enable. I also performed the testing for this issue on jammy: $ apt-cache policy ufw ufw: Installed: 0.36.1-4build1 Candidate: 0.36.1-4build1 Version table: *** 0.36.1-4build1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status # recreate the WSL2 scenario by having the parent shell contain 'Relay(NNN)'. # This could be done various ways, but the easiest is to create a script named # /tmp/Relay(230) to launch ufw: $ cat < "/tmp/Relay(230)" #!/bin/bash sudo ufw enable EOM $ chmod 755 "/tmp/Relay(230)" # before the update $ "/tmp/Relay(230)" Traceback (most recent call last): File "/usr/lib/python3/dist-packages/ufw/util.py", line 427, in under_ssh ppid = get_ppid(pid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 419, in get_ppid ppid = open(name).readlines()[0].split(')')[1].split()[1] IndexError: list index out of range During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/sbin/ufw", line 138, in not ui.continue_under_ssh(): File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 901, in continue_under_ssh if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in under_ssh raise ValueError(err_msg) ValueError: Couldn't find parent pid for '1294' # after the update $ cat
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
For lunar, the crmsh autopkgtest issue was unrelated. I reran the autopkgtest and it passed: https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/s390x/c/crmsh/20230725_140910_37cd9@/log.gz Note that autopkg tests for ufw test various aspects of normal ufw usage, including ufw enable. I also performed the testing for this issue on lunar: $ apt-cache policy ufw ufw: Installed: 0.36.1-4.1 Candidate: 0.36.1-4.1 Version table: *** 0.36.1-4.1 500 500 http://archive.ubuntu.com/ubuntu lunar/main amd64 Packages 100 /var/lib/dpkg/status # recreate the WSL2 scenario by having the parent shell contain 'Relay(NNN)'. # This could be done various ways, but the easiest is to create a script named # /tmp/Relay(230) to launch ufw: $ cat < "/tmp/Relay(230)" #!/bin/bash sudo ufw enable EOM $ chmod 755 "/tmp/Relay(230)" # before the update $ "/tmp/Relay(230)" Traceback (most recent call last): File "/usr/lib/python3/dist-packages/ufw/util.py", line 427, in under_ssh ppid = get_ppid(pid) ^ File "/usr/lib/python3/dist-packages/ufw/util.py", line 419, in get_ppid ppid = open(name).readlines()[0].split(')')[1].split()[1] ~~~^^^ IndexError: list index out of range During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/sbin/ufw", line 138, in not ui.continue_under_ssh(): ^^^ File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 901, in continue_under_ssh if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) ^^^ File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) ^^^ File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) ^^^ File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in under_ssh raise ValueError(err_msg) ValueError: Couldn't find parent pid for '4496' # after the update $ cat
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
> I'll prepare an upload for Lunar, add a task and put these back to In Progress after. Uploaded 0.36.1-4.1ubuntu0.1 to Lunar. ** Also affects: ufw (Ubuntu Lunar) Importance: Undecided Status: New ** Changed in: ufw (Ubuntu Lunar) Importance: Undecided => High ** Changed in: ufw (Ubuntu Lunar) Status: New => In Progress ** Changed in: ufw (Ubuntu Lunar) Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2015645 Title: ufw crashes in wsl2 Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Focal: In Progress Status in ufw source package in Jammy: In Progress Status in ufw source package in Lunar: In Progress Status in ufw source package in Mantic: Fix Released Bug description: [ Impact ] Currently, ufw is unusable on WSL due to this bug because the get_ppid() function traces back on /proc when the command name has parentheses (like in WSL). get_ppid() is called with 'ufw enable' and so ufw is not able to be enabled on WSL. The upstream patch adjusts get_ppid() for this and adds unit tests for this function. [ Test Plan ] Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw status' to show that it was enabled. Importantly, this is called as part of autopkgtests already. Furthermore, look in the build logs for: test_util ... test_get_ppid (tests.unit.test_util.UtilTestCase) Test get_ppid() ... ok test_get_ppid_no_space (tests.unit.test_util.UtilTestCase) Test get_ppid() no space ... ok test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase) Test get_ppid() with parens ... ok test_get_ppid_with_space (tests.unit.test_util.UtilTestCase) Test get_ppid() with space ... ok ... -- Ran 49 tests in 0.355s OK [ Where problems could occur ] The risk of regression is considered low since comprehensive unit tests are added for the patched function. Not only is this change in upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu Mantic as part of 0.36.2-1. # Original Description When I enable systemd in WSL2 (it became supported recently), install ufw, and run sudo ufw enable, I get the error detailed in https://superuser.com/questions/1775776/enabling-ufw-failed-with- ubuntu-from-wsl2. You may already be aware of this error, I'm not sure if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2 /proc/[pid]/stat format, although weird, does comply with the spec: https://man7.org/linux/man-pages/man5/proc.5.html I verified that you can fix this issue by replacing the first split in line 427 with rsplit(')', 1) so it splits based on the last parenthesis instead of the all parenthesis. Before: ppid = open(name).readlines()[0].split(')')[1].split()[1] After: ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1] C:\Users\caleb>wsl --version WSL version: 1.1.6.0 Kernel version: 5.15.90.1 WSLg version: 1.0.50 MSRDC version: 1.2.3770 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2728 ➜ ufw git:(master) ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. ➜ ufw git:(master) cat /proc/229/stat | cut -c -23 229 (Relay(230)) S 228 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2015645/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
Oh, I did mean kinetic, yes. Lunar should get an update too (though, as mentioned, that isn't in the Microsoft store it seems). I'll prepare an upload for Lunar, add a task and put these back to In Progress after. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2015645 Title: ufw crashes in wsl2 Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Focal: In Progress Status in ufw source package in Jammy: In Progress Status in ufw source package in Mantic: Fix Released Bug description: [ Impact ] Currently, ufw is unusable on WSL due to this bug because the get_ppid() function traces back on /proc when the command name has parentheses (like in WSL). get_ppid() is called with 'ufw enable' and so ufw is not able to be enabled on WSL. The upstream patch adjusts get_ppid() for this and adds unit tests for this function. [ Test Plan ] Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw status' to show that it was enabled. Importantly, this is called as part of autopkgtests already. Furthermore, look in the build logs for: test_util ... test_get_ppid (tests.unit.test_util.UtilTestCase) Test get_ppid() ... ok test_get_ppid_no_space (tests.unit.test_util.UtilTestCase) Test get_ppid() no space ... ok test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase) Test get_ppid() with parens ... ok test_get_ppid_with_space (tests.unit.test_util.UtilTestCase) Test get_ppid() with space ... ok ... -- Ran 49 tests in 0.355s OK [ Where problems could occur ] The risk of regression is considered low since comprehensive unit tests are added for the patched function. Not only is this change in upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu Mantic as part of 0.36.2-1. # Original Description When I enable systemd in WSL2 (it became supported recently), install ufw, and run sudo ufw enable, I get the error detailed in https://superuser.com/questions/1775776/enabling-ufw-failed-with- ubuntu-from-wsl2. You may already be aware of this error, I'm not sure if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2 /proc/[pid]/stat format, although weird, does comply with the spec: https://man7.org/linux/man-pages/man5/proc.5.html I verified that you can fix this issue by replacing the first split in line 427 with rsplit(')', 1) so it splits based on the last parenthesis instead of the all parenthesis. Before: ppid = open(name).readlines()[0].split(')')[1].split()[1] After: ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1] C:\Users\caleb>wsl --version WSL version: 1.1.6.0 Kernel version: 5.15.90.1 WSLg version: 1.0.50 MSRDC version: 1.2.3770 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2728 ➜ ufw git:(master) ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. ➜ ufw git:(master) cat /proc/229/stat | cut -c -23 229 (Relay(230)) S 228 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2015645/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
Robie, https://apps.microsoft.com/store/detail/ubuntu/9PDXGNCFSCZV?hl=en- us&gl=us&rtc=1 seems to indicate that only 22.04.2 is supported. Users have talked about upgrading via the command line to 22.10, but I figured that Lunar was about to EOL and no point in updating it at this time. ** Changed in: ufw (Ubuntu Focal) Status: Incomplete => In Progress ** Changed in: ufw (Ubuntu Jammy) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2015645 Title: ufw crashes in wsl2 Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Focal: In Progress Status in ufw source package in Jammy: In Progress Status in ufw source package in Mantic: Fix Released Bug description: [ Impact ] Currently, ufw is unusable on WSL due to this bug because the get_ppid() function traces back on /proc when the command name has parentheses (like in WSL). get_ppid() is called with 'ufw enable' and so ufw is not able to be enabled on WSL. The upstream patch adjusts get_ppid() for this and adds unit tests for this function. [ Test Plan ] Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw status' to show that it was enabled. Importantly, this is called as part of autopkgtests already. Furthermore, look in the build logs for: test_util ... test_get_ppid (tests.unit.test_util.UtilTestCase) Test get_ppid() ... ok test_get_ppid_no_space (tests.unit.test_util.UtilTestCase) Test get_ppid() no space ... ok test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase) Test get_ppid() with parens ... ok test_get_ppid_with_space (tests.unit.test_util.UtilTestCase) Test get_ppid() with space ... ok ... -- Ran 49 tests in 0.355s OK [ Where problems could occur ] The risk of regression is considered low since comprehensive unit tests are added for the patched function. Not only is this change in upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu Mantic as part of 0.36.2-1. # Original Description When I enable systemd in WSL2 (it became supported recently), install ufw, and run sudo ufw enable, I get the error detailed in https://superuser.com/questions/1775776/enabling-ufw-failed-with- ubuntu-from-wsl2. You may already be aware of this error, I'm not sure if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2 /proc/[pid]/stat format, although weird, does comply with the spec: https://man7.org/linux/man-pages/man5/proc.5.html I verified that you can fix this issue by replacing the first split in line 427 with rsplit(')', 1) so it splits based on the last parenthesis instead of the all parenthesis. Before: ppid = open(name).readlines()[0].split(')')[1].split()[1] After: ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1] C:\Users\caleb>wsl --version WSL version: 1.1.6.0 Kernel version: 5.15.90.1 WSLg version: 1.0.50 MSRDC version: 1.2.3770 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2728 ➜ ufw git:(master) ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. ➜ ufw git:(master) cat /proc/229/stat | cut -c -23 229 (Relay(230)) S 228 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2015645/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
Fyi, uploaded to 0.36.1-4ubuntu0.1 and 0.36-6ubuntu1.1 to jammy-proposed and focal-proposed, respectively. ** Changed in: ufw (Ubuntu Focal) Status: Triaged => In Progress ** Changed in: ufw (Ubuntu Jammy) Status: Triaged => In Progress ** Changed in: ufw (Ubuntu Focal) Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Changed in: ufw (Ubuntu Jammy) Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Changed in: ufw (Ubuntu Mantic) Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2015645 Title: ufw crashes in wsl2 Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Focal: In Progress Status in ufw source package in Jammy: In Progress Status in ufw source package in Mantic: Fix Released Bug description: [ Impact ] Currently, ufw is unusable on WSL due to this bug because the get_ppid() function traces back on /proc when the command name has parentheses (like in WSL). get_ppid() is called with 'ufw enable' and so ufw is not able to be enabled on WSL. The upstream patch adjusts get_ppid() for this and adds unit tests for this function. [ Test Plan ] Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw status' to show that it was enabled. Importantly, this is called as part of autopkgtests already. Furthermore, look in the build logs for: test_util ... test_get_ppid (tests.unit.test_util.UtilTestCase) Test get_ppid() ... ok test_get_ppid_no_space (tests.unit.test_util.UtilTestCase) Test get_ppid() no space ... ok test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase) Test get_ppid() with parens ... ok test_get_ppid_with_space (tests.unit.test_util.UtilTestCase) Test get_ppid() with space ... ok ... -- Ran 49 tests in 0.355s OK [ Where problems could occur ] The risk of regression is considered low since comprehensive unit tests are added for the patched function. Not only is this change in upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu Mantic as part of 0.36.2-1. # Original Description When I enable systemd in WSL2 (it became supported recently), install ufw, and run sudo ufw enable, I get the error detailed in https://superuser.com/questions/1775776/enabling-ufw-failed-with- ubuntu-from-wsl2. You may already be aware of this error, I'm not sure if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2 /proc/[pid]/stat format, although weird, does comply with the spec: https://man7.org/linux/man-pages/man5/proc.5.html I verified that you can fix this issue by replacing the first split in line 427 with rsplit(')', 1) so it splits based on the last parenthesis instead of the all parenthesis. Before: ppid = open(name).readlines()[0].split(')')[1].split()[1] After: ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1] C:\Users\caleb>wsl --version WSL version: 1.1.6.0 Kernel version: 5.15.90.1 WSLg version: 1.0.50 MSRDC version: 1.2.3770 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2728 ➜ ufw git:(master) ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. ➜ ufw git:(master) cat /proc/229/stat | cut -c -23 229 (Relay(230)) S 228 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2015645/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
** Description changed: + [ Impact ] + + Currently, ufw is unusable on WSL due to this bug because the get_ppid() + function traces back on /proc when the command name has parentheses + (like in WSL). get_ppid() is called with 'ufw enable' and so ufw is not + able to be enabled on WSL. The upstream patch adjusts get_ppid() for + this and adds unit tests for this function. + + [ Test Plan ] + + Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw + status' to show that it was enabled. Importantly, this is called as part + of autopkgtests already. + + Furthermore, look in the build logs for: + + test_util + ... + test_get_ppid (tests.unit.test_util.UtilTestCase) + Test get_ppid() ... ok + test_get_ppid_no_space (tests.unit.test_util.UtilTestCase) + Test get_ppid() no space ... ok + test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase) + Test get_ppid() with parens ... ok + test_get_ppid_with_space (tests.unit.test_util.UtilTestCase) + Test get_ppid() with space ... ok + ... + -- + Ran 49 tests in 0.355s + + OK + + [ Where problems could occur ] + + The risk of regression is considered low since comprehensive unit tests + are added for the patched function. Not only is this change in upstream + ufw 0.36.2, it is already in Debian Bookworm and Ubuntu Mantic as part + of 0.36.2-1. + + + # Original Description + When I enable systemd in WSL2 (it became supported recently), install ufw, and run sudo ufw enable, I get the error detailed in https://superuser.com/questions/1775776/enabling-ufw-failed-with-ubuntu- from-wsl2. You may already be aware of this error, I'm not sure if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2 /proc/[pid]/stat format, although weird, does comply with the spec: https://man7.org/linux/man-pages/man5/proc.5.html I verified that you can fix this issue by replacing the first split in line 427 with rsplit(')', 1) so it splits based on the last parenthesis instead of the all parenthesis. Before: ppid = open(name).readlines()[0].split(')')[1].split()[1] After: ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1] - C:\Users\caleb>wsl --version WSL version: 1.1.6.0 Kernel version: 5.15.90.1 WSLg version: 1.0.50 MSRDC version: 1.2.3770 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2728 ➜ ufw git:(master) ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. ➜ ufw git:(master) cat /proc/229/stat | cut -c -23 229 (Relay(230)) S 228 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2015645 Title: ufw crashes in wsl2 Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Focal: Triaged Status in ufw source package in Jammy: Triaged Status in ufw source package in Mantic: Fix Released Bug description: [ Impact ] Currently, ufw is unusable on WSL due to this bug because the get_ppid() function traces back on /proc when the command name has parentheses (like in WSL). get_ppid() is called with 'ufw enable' and so ufw is not able to be enabled on WSL. The upstream patch adjusts get_ppid() for this and adds unit tests for this function. [ Test Plan ] Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw status' to show that it was enabled. Importantly, this is called as part of autopkgtests already. Furthermore, look in the build logs for: test_util ... test_get_ppid (tests.unit.test_util.UtilTestCase) Test get_ppid() ... ok test_get_ppid_no_space (tests.unit.test_util.UtilTestCase) Test get_ppid() no space ... ok test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase) Test get_ppid() with parens ... ok test_get_ppid_with_space (tests.unit.test_util.UtilTestCase) Test get_ppid() with space ... ok ... -- Ran 49 tests in 0.355s OK [ Where problems could occur ] The risk of regression is considered low since comprehensive unit tests are added for the patched function. Not only is this change in upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu Mantic as part of 0.36.2-1. # Original Description When I enable systemd in WSL2 (it became supported recently), install ufw, and run sudo ufw enable, I get the error detailed in https://superuser.com/questions/1775776/enabling-ufw-failed-with- ubuntu-from-wsl2. You may already be aware of this error, I'm not sure if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2 /proc/[pid]/stat format, although weird, does comply with the spec: https://man7.org/linux/man-pages/man5/proc.5.html I verified
[Touch-packages] [Bug 1844743] Re: ufw missing .conf for syslog-ng
** Changed in: ufw Importance: Medium => Wishlist ** Changed in: ufw (Ubuntu) Importance: Medium => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1844743 Title: ufw missing .conf for syslog-ng Status in ufw: Triaged Status in ufw package in Ubuntu: Triaged Bug description: ufw package contains /etc/rsyslog.d/20-ufw.conf, but no /etc/syslog-ng/conf.d/ufw.conf distro: any ufw: any To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1844743/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
** Also affects: ufw (Ubuntu) Importance: Undecided Status: New ** Also affects: ufw (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: ufw (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: ufw (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: ufw (Ubuntu Mantic) Status: New => Triaged ** Changed in: ufw (Ubuntu Jammy) Status: New => Triaged ** Changed in: ufw (Ubuntu Focal) Status: New => Triaged ** Changed in: ufw (Ubuntu Mantic) Importance: Undecided => High ** Changed in: ufw (Ubuntu Jammy) Importance: Undecided => High ** Changed in: ufw (Ubuntu Focal) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2015645 Title: ufw crashes in wsl2 Status in ufw: Fix Released Status in ufw package in Ubuntu: Triaged Status in ufw source package in Focal: Triaged Status in ufw source package in Jammy: Triaged Status in ufw source package in Mantic: Triaged Bug description: When I enable systemd in WSL2 (it became supported recently), install ufw, and run sudo ufw enable, I get the error detailed in https://superuser.com/questions/1775776/enabling-ufw-failed-with- ubuntu-from-wsl2. You may already be aware of this error, I'm not sure if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2 /proc/[pid]/stat format, although weird, does comply with the spec: https://man7.org/linux/man-pages/man5/proc.5.html I verified that you can fix this issue by replacing the first split in line 427 with rsplit(')', 1) so it splits based on the last parenthesis instead of the all parenthesis. Before: ppid = open(name).readlines()[0].split(')')[1].split()[1] After: ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1] C:\Users\caleb>wsl --version WSL version: 1.1.6.0 Kernel version: 5.15.90.1 WSLg version: 1.0.50 MSRDC version: 1.2.3770 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2728 ➜ ufw git:(master) ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. ➜ ufw git:(master) cat /proc/229/stat | cut -c -23 229 (Relay(230)) S 228 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/2015645/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python
This was fixed in 0.36.2. ** Changed in: ufw Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1951018 Title: No ability to discern IPv4 vs IPv6 rules through Python Status in ufw: Fix Released Status in ufw package in Ubuntu: Triaged Bug description: Version: ufw 0.36 Ubuntu Version: 20.04.3 LTS There doesn't appear to be a Python method for accessing IPv4 and IPv6 rules in a distinguishable manner. In the source code (root/src/backend.py) there is an object that stores IPv4 and IPv6 rules in separate lists. Those lists are then accessed with the following method: def get_rules(self): '''Return list of all rules''' return self.rules + self.rules6 The issue with this is that the returned list doesn't contain an indication of what IP version each item corresponds to and would display something like the following. 1 allow 22/tcp 2 allow 80 3 allow 443 4 allow 22/tcp 5 allow 80 6 allow 443 I don't currently see a way to distinguish between IPv4 and IPv6 rules other than accessing the lists in the backend object directly (but I don't think this is best practice). E.g.: rules_ipv4 = backend.rules rules_ipv6 = backend.rules6 One possible fix would be to add functions that return only the IPv4 or IPv6 rules. E.g.: def get_rules_ipv4(self): '''Return list of all ipv4 rules''' return self.rules def get_rules_ipv6(self): '''Return list of all ipv6 rules''' return self.rules6 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1951018/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
This was fixed in 0.36.2. ** Changed in: ufw Importance: Undecided => Medium ** Changed in: ufw Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Changed in: ufw Status: Fix Committed => Fix Released ** Changed in: ufw (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Released Status in ufw source package in Focal: Fix Released Status in ufw source package in Hirsute: Fix Released Status in ufw source package in Impish: Fix Released Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 3
[Touch-packages] [Bug 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python
Thank you for reporting a bug in ufw. I've committed a fix for this to add get_rules_ipv4() and get_rules_ipv6(). ** Changed in: ufw Importance: Undecided => Wishlist ** Changed in: ufw Status: New => Fix Committed ** Changed in: ufw Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Changed in: ufw (Ubuntu) Status: New => Triaged ** Changed in: ufw (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1951018 Title: No ability to discern IPv4 vs IPv6 rules through Python Status in ufw: Fix Committed Status in ufw package in Ubuntu: Triaged Bug description: Version: ufw 0.36 Ubuntu Version: 20.04.3 LTS There doesn't appear to be a Python method for accessing IPv4 and IPv6 rules in a distinguishable manner. In the source code (root/src/backend.py) there is an object that stores IPv4 and IPv6 rules in separate lists. Those lists are then accessed with the following method: def get_rules(self): '''Return list of all rules''' return self.rules + self.rules6 The issue with this is that the returned list doesn't contain an indication of what IP version each item corresponds to and would display something like the following. 1 allow 22/tcp 2 allow 80 3 allow 443 4 allow 22/tcp 5 allow 80 6 allow 443 I don't currently see a way to distinguish between IPv4 and IPv6 rules other than accessing the lists in the backend object directly (but I don't think this is best practice). E.g.: rules_ipv4 = backend.rules rules_ipv6 = backend.rules6 One possible fix would be to add functions that return only the IPv4 or IPv6 rules. E.g.: def get_rules_ipv4(self): '''Return list of all ipv4 rules''' return self.rules def get_rules_ipv6(self): '''Return list of all ipv6 rules''' return self.rules6 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1951018/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2014031] Re: ufw fails trying to enable
*** This bug is a duplicate of bug 2015645 *** https://bugs.launchpad.net/bugs/2015645 This looks like it may be a dupe of https://bugs.launchpad.net/bugs/2015645 (the fix for it should fix this). ** Changed in: ufw (Ubuntu) Status: New => Confirmed ** This bug has been marked a duplicate of bug 2015645 ufw crashes in wsl2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2014031 Title: ufw fails trying to enable Status in ufw package in Ubuntu: Confirmed Bug description: root@SW556127-UY:~# sudo ufw enable Traceback (most recent call last): File "/usr/lib/python3/dist-packages/ufw/util.py", line 427, in under_ssh ppid = get_ppid(pid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 419, in get_ppid ppid = open(name).readlines()[0].split(')')[1].split()[1] IndexError: list index out of range During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/sbin/ufw", line 138, in not ui.continue_under_ssh(): File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 901, in continue_under_ssh if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) [Previous line repeated 1 more time] File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in under_ssh raise ValueError(err_msg) ValueError: Couldn't find parent pid for '257' root@SW556127-UY:~# lsb_release -rd Description:Ubuntu 22.04.2 LTS Release:22.04 root@SW556127-UY:~# apt-cache policy ufw ufw: Installed: 0.36.1-4build1 Candidate: 0.36.1-4build1 Version table: *** 0.36.1-4build1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/2014031/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2014031] Re: ufw fails trying to enable
Thanks for the report. Does this happen every time of just occasionally? It's clear that the open(name).readlines() isn't returning anything, which is interesting. Do you have any other information on what might be causing this? (the fix should be straightforward without it though) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/2014031 Title: ufw fails trying to enable Status in ufw package in Ubuntu: New Bug description: root@SW556127-UY:~# sudo ufw enable Traceback (most recent call last): File "/usr/lib/python3/dist-packages/ufw/util.py", line 427, in under_ssh ppid = get_ppid(pid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 419, in get_ppid ppid = open(name).readlines()[0].split(')')[1].split()[1] IndexError: list index out of range During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/sbin/ufw", line 138, in not ui.continue_under_ssh(): File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 901, in continue_under_ssh if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh return under_ssh(ppid) [Previous line repeated 1 more time] File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in under_ssh raise ValueError(err_msg) ValueError: Couldn't find parent pid for '257' root@SW556127-UY:~# lsb_release -rd Description:Ubuntu 22.04.2 LTS Release:22.04 root@SW556127-UY:~# apt-cache policy ufw ufw: Installed: 0.36.1-4build1 Candidate: 0.36.1-4build1 Version table: *** 0.36.1-4build1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/2014031/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1970731] Re: iptables empty when using firewalld
Reassigning to firewalld as the description mentions that ufw is disabled. This is not a bug though because iptables relies on certain tables/chains being used and it looks like firewalld doesn't use those (which is fine for firewalld to do). You should be able to see all netfilter firewall rules with 'nft' but you'll only see rules that are added to the (now non-default) tables/chains that iptables expects (INPUT, OUTPUT, etc). More specifically, 'nft' will see the rules that 'iptables' creates but not necessarily the other way around. ** Package changed: ufw (Ubuntu) => firewalld (Ubuntu) ** Changed in: firewalld (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1970731 Title: iptables empty when using firewalld Status in firewalld package in Ubuntu: Invalid Bug description: Summary: I am using firewalld/jammy,now 1.1.1-1ubuntu1 on my vpn server. The vpn server is using wireguard and I could successfully configure zones and policies in firewalld. Yet, iptables does not show the rules from firewalld. 1) System root@vpn:~# uname -a Linux vpn 5.15.0-27-generic #28-Ubuntu SMP Thu Apr 14 04:55:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux root@vpn:~# lsb_release -rd Description: Ubuntu 22.04 LTS Release: 22.04 All updates installed. 2) What happens: I am setting rules with firewall-cmd. These firewall rules are visible with: nft list table inet firewalld but not with 'iptables'. 3) What I expect to happen: The toutput of iptables --list should also reflect firewalld settings. 4) What happened instead However, the iptables output shows only empty tables (filter, mangle, nat). root@vpn:~# iptables -t nat --list # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination root@vpn:~# iptables -t filter --list # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination root@vpn:~# iptables-legacy -t nat --list Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination root@vpn:~# iptables-legacy -t filter --list Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination 5) Further information The ufw firewall is disabled and uninstalled. According to the release notes of 22.04, the backend has changed to nftables. I was assuming, that the backend default is kind of transparent to the user, meaning iptables should still work as normal. I wonder if on my system is iptables correctly linked to the backend. Iptables points to xtables-nft-multi: root@vpn:~# ls -l /usr/sbin/iptables lrwxrwxrwx 1 root root 26 Aug 24 2021 /usr/sbin/iptables -> /etc/alternatives/iptables root@vpn:~# ls -l /etc/alternatives/iptables lrwxrwxrwx 1 root root 22 Apr 25 18:56 /etc/alternatives/iptables -> /usr/sbin/iptables-nft root@vpn:~# ls -l /usr/sbin/iptables-nft lrwxrwxrwx 1 root root 17 Mar 24 12:58 /usr/sbin/iptables-nft -> xtables-nft-multi root@vpn:~# ls -l /usr/sbin/xtables-nft-multi -rwxr-xr-x 1 root root 224296 Mar 24 12:58 /usr/sbin/xtables-nft-multi Perhaps this is an issue with the upgrade process of ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1970731/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
** Changed in: isc-dhcp (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start Status in ifupdown package in Ubuntu: Fix Released Status in isc-dhcp package in Ubuntu: Triaged Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
** Changed in: ifupdown (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start Status in ifupdown package in Ubuntu: In Progress Status in isc-dhcp package in Ubuntu: New Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
** Also affects: ifupdown (Ubuntu) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start Status in ifupdown package in Ubuntu: New Status in isc-dhcp package in Ubuntu: New Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
I grep'd for 'netif' in /etc and noticed: $ sudo grep -r netif /etc /etc/network/if-down.d/resolved:statedir=/run/systemd/resolve/netif /etc/network/if-up.d/resolved:statedir=/run/systemd/resolve/netif /etc/dhcp/dhclient-exit-hooks.d/resolved:statedir=/run/systemd/resolve/netif /etc/network/if-up.d/resolved and /etc/dhcp/dhclient-exit- hooks.d/resolved have code like this: statedir=/run/systemd/resolve/netif mkdir -p $statedir but do not have a corresponding chown of /run/systemd/resolve/netif. There is a chown for `chown systemd-resolve:systemd-resolve "$statedir/$ifindex"` in /etc/network/if-up.d/resolved and /etc/dhcp/dhclient-exit-hooks.d/resolved. This system has been upgraded many, many times (at least since yakkety). dhclient is being used for this interface. ifupdown is installed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Uns
[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
I see this on 22.04 after upgrading from 20.04. $ journalctl |grep 'Failed to save link data' Apr 17 15:25:52 hostname systemd-resolved[19095]: Failed to save link data /run/systemd/resolve/netif/3: Permission denied Apr 17 15:25:52 hostname systemd-resolved[19095]: Failed to save link data /run/systemd/resolve/netif/3: Permission denied $ ls -ld /run/systemd/resolve/netif drwxr-xr-x 2 root root 40 Apr 17 14:46 /run/systemd/resolve/netif (note, I had tried to restart systemd-resolved) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1968608] Re: networking/firewall issues after upgrade when using iptables-nft
I filed https://github.com/docker-snap/docker-snap/issues/68 for the docker snap unconditionally using xtables. ** Bug watch added: github.com/docker-snap/docker-snap/issues #68 https://github.com/docker-snap/docker-snap/issues/68 ** Also affects: iptables (Ubuntu) Importance: Undecided Status: New ** Changed in: iptables (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1968608 Title: networking/firewall issues after upgrade when using iptables-nft Status in ufw: Invalid Status in iptables package in Ubuntu: Invalid Status in ufw package in Ubuntu: Invalid Bug description: Filing this issue in the hopes that it will help people who are upgrading from a system that previously used xtables to one that is using netfilter. ufw uses the 'iptables' suite of commands under the hood. As of iptables 1.8, iptables ships with two different backends for these commands: * nft (netfilter) * legacy (xtables) such that there are iptables-nft, iptables-legacy, ip6tables-nft, ip6tables-legacy, etc commands on the system. Distributions may choose to then install symlinks from these commands to the traditional command. Eg, iptables will point to either iptables-nft or iptables- legacy. These symlinks can be configured by the admin on Debian/Ubuntu-based systems with: $ sudo update-alternatives --config iptables # configures all the iptables* symlinks $ sudo update-alternatives --config ip6tables # configures all the ip6tables* symlinks ufw is fully compatible with either backend. iptables-nft and nftables (ie, the 'nft' command not part of 'iptables'; will refer to this here as 'nftables' for clarity) both work with the kernel netfilter and different software on the system may freely use iptables-nft or nftables (eg, ufw using iptables-nft with other software (eg, libvirt) using nftables is fine). Since iptables-nft works well for ufw's requirements, there hasn't been a compelling reason to migrate ufw to use 'nftables' instead of 'iptables'. While iptables-nft and nftables can be used together, you should NOT mix and match netfilter and xtables rules as the upstream kernel considers this undefined and the firewall may not work correctly. Before iptables 1.8, admins could not mix and match iptables and nftables (or software that used one or the other). With iptables 1.8, admins can choose to use iptables-legacy or nftables and/or iptables- nft. Older releases of distributions (eg, Ubuntu 20.04 LTS) defaulted to iptables-legacy as the iptables backend with the admin able to opt into iptables-nft. Newer releases of distributions (eg, Ubuntu 22.04 LTS) are choosing to default to iptables-nft instead. As mentioned, so long as all of the software on the system agrees on using either netfilter or xtables, everything should be fine. Use of the symlink mechanism (eg, the aforementioned 'update-alternatives' on Debian/Ubuntu) helps ensure everything works properly. Software that manipulates the firewall outside of the configured symlinks (or using iptables-legacy/iptables 1.6 while nftables is also in use) might introduce problems if they are not aware of the xtables/netfilter incompatibility. Eg, this might happen with snaps that ship their own iptables or nftables and unconditionally use it without considering existing rules on the system. The ufw snap will detect and use the correct backend for the system on startup. The lxd and multipass snaps will do the same. As such, eg, an Ubuntu 20.04 system that is configured with the default iptables- legacy backend can use the ufw deb from Ubuntu with the lxd and multipass snaps without issue (ufw follows the iptables symlink to use the legacy (xtables) backend to load firewall rules in early boot. When lxd and multipass are started, they see that legacy rules are in use and use xtables). Similarly, on an Ubuntu 22.04 system that is configured with the default iptables-nft backend, the ufw deb from Ubuntu will follow the iptables symlink to use the nft (netfilter) backend to load firewall rules in early boot. When lxd and multipass are started, the see that nft rules are in use and use netfilter. Users upgrading from earlier distributions that defaulted to the legacy backend to newer releases that use the nft backend may find that non-distro software isn't choosing the correct backend. You can see if this is the case by running: $ sudo iptables-nft -S and compare with: $ sudo iptables-legacy -S If one is populated and the other comes back with only: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT then everything should be operating together ok. You should also check ip6tables-nft vs ip6tables-legacy and if you have 'nft' on your system, see that
[Touch-packages] [Bug 1968608] Re: networking/firewall issues after upgrade when using iptables-nft
** Description changed: Filing this issue in the hopes that it will help people who are upgrading from a system that previously used xtables to one that is using netfilter. ufw uses the 'iptables' suite of commands under the hood. As of iptables 1.8, iptables ships with two different backends for these commands: * nft (netfilter) * legacy (xtables) such that there are iptables-nft, iptables-legacy, ip6tables-nft, ip6tables-legacy, etc commands on the system. Distributions may choose to then install symlinks from these commands to the traditional command. Eg, iptables will point to either iptables-nft or iptables-legacy. These symlinks can be configured by the admin on Debian/Ubuntu-based systems with: $ sudo update-alternatives --config iptables # configures all the iptables* symlinks $ sudo update-alternatives --config ip6tables # configures all the ip6tables* symlinks ufw is fully compatible with either backend. iptables-nft and nftables (ie, the 'nft' command not part of 'iptables'; will refer to this here as 'nftables' for clarity) both work with the kernel netfilter and different software on the system may freely use iptables-nft or nftables (eg, ufw using iptables-nft with other software (eg, libvirt) using nftables is fine). Since iptables-nft works well for ufw's requirements, there hasn't been a compelling reason to migrate ufw to use 'nftables' instead of 'iptables'. While iptables-nft and nftables can be used together, you should NOT mix and match netfilter and xtables rules as the upstream kernel considers this undefined and the firewall may not work correctly. Before iptables 1.8, admins could not mix and match iptables and nftables (or software that used one or the other). With iptables 1.8, admins can choose to use iptables-legacy or nftables and/or iptables-nft. Older releases of distributions (eg, Ubuntu 20.04 LTS) defaulted to iptables-legacy as the iptables backend with the admin able to opt into iptables-nft. Newer releases of distributions (eg, Ubuntu 22.04 LTS) are choosing to default to iptables-nft instead. As mentioned, so long as all of the software on the system agrees on using either netfilter or xtables, everything should be fine. Use of the symlink mechanism (eg, the aforementioned 'update-alternatives' on Debian/Ubuntu) helps ensure everything works properly. Software that manipulates the firewall outside of the configured symlinks (or using iptables-legacy/iptables 1.6 while nftables is also in use) might introduce problems if they are not aware of the xtables/netfilter incompatibility. Eg, this might happen with snaps that ship their own iptables or nftables and unconditionally use it without considering existing rules on the system. The ufw snap will detect and use the correct backend for the system on startup. The lxd and multipass snaps will do the same. As such, eg, an Ubuntu 20.04 system that is configured with the default iptables-legacy backend can use the ufw deb from Ubuntu with the lxd and multipass snaps without issue (ufw follows the iptables symlink to use the legacy (xtables) backend to load firewall rules in early boot. When lxd and multipass are started, they see that legacy rules are in use and use xtables). Similarly, on an Ubuntu 22.04 system that is configured with the default iptables-nft backend, the ufw deb from Ubuntu will follow the iptables symlink to use the nft (netfilter) backend to load firewall rules in early boot. When lxd and multipass are started, the see that nft rules are in use and use netfilter. Users upgrading from earlier distributions that defaulted to the legacy backend to newer releases that use the nft backend may find that non- distro software isn't choosing the correct backend. You can see if this is the case by running: $ sudo iptables-nft -S and compare with: $ sudo iptables-legacy -S If one is populated and the other comes back with only: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT then everything should be operating together ok. You should also check ip6tables-nft vs ip6tables-legacy and if you have 'nft' on your system, see that 'sudo nft list ruleset' has only accept rules if 'iptables- legacy -S' shows rules are in use. If there is a mixture of rules in both backends, you'll need to make everything use either netfilter or xtables. If things were working correctly before the upgrade, you might find that going back to iptables-legacy could make things work until you're ready to migrate to iptables-nft (on Debian/Ubuntu, see update-alternatives, above). The 'docker' snap as of 20.10.12 in the stable channel is known to unconditionally use xtables. At the time of this filing, it did not have a way to adjust to using netfilter, so if using the docker snap, you might have to update your system to use iptabl
[Touch-packages] [Bug 1968608] [NEW] networking/firewall issues after upgrade when using iptables-nft
Public bug reported: Filing this issue in the hopes that it will help people who are upgrading from a system that previously used xtables to one that is using netfilter. ufw uses the 'iptables' suite of commands under the hood. As of iptables 1.8, iptables ships with two different backends for these commands: * nft (netfilter) * legacy (xtables) such that there are iptables-nft, iptables-legacy, ip6tables-nft, ip6tables-legacy, etc commands on the system. Distributions may choose to then install symlinks from these commands to the traditional command. Eg, iptables will point to either iptables-nft or iptables-legacy. These symlinks can be configured by the admin on Debian/Ubuntu-based systems with: $ sudo update-alternatives --config iptables # configures all the iptables* symlinks $ sudo update-alternatives --config ip6tables # configures all the ip6tables* symlinks ufw is fully compatible with either backend. iptables-nft and nftables (ie, the 'nft' command not part of 'iptables'; will refer to this here as 'nftables' for clarity) both work with the kernel netfilter and different software on the system may freely use iptables-nft or nftables (eg, ufw using iptables-nft with other software (eg, libvirt) using nftables is fine). Since iptables-nft works well for ufw's requirements, there hasn't been a compelling reason to migrate ufw to use 'nftables' instead of 'iptables'. While iptables-nft and nftables can be used together, you should NOT mix and match netfilter and xtables rules as the upstream kernel considers this undefined and the firewall may not work correctly. Before iptables 1.8, admins could not mix and match iptables and nftables (or software that used one or the other). With iptables 1.8, admins can choose to use iptables-legacy or nftables and/or iptables-nft. Older releases of distributions (eg, Ubuntu 20.04 LTS) defaulted to iptables-legacy as the iptables backend with the admin able to opt into iptables-nft. Newer releases of distributions (eg, Ubuntu 22.04 LTS) are choosing to default to iptables-nft instead. As mentioned, so long as all of the software on the system agrees on using either netfilter or xtables, everything should be fine. Use of the symlink mechanism (eg, the aforementioned 'update-alternatives' on Debian/Ubuntu) helps ensure everything works properly. Software that manipulates the firewall outside of the configured symlinks (or using iptables-legacy/iptables 1.6 while nftables is also in use) might introduce problems if they are not aware of the xtables/netfilter incompatibility. Eg, this might happen with snaps that ship their own iptables or nftables and unconditionally use it without considering existing rules on the system. The ufw snap will detect and use the correct backend for the system on startup. The lxd and multipass snaps will do the same. As such, eg, an Ubuntu 20.04 system that is configured with the default iptables-legacy backend can use the ufw deb from Ubuntu with the lxd and multipass snaps without issue (ufw follows the iptables symlink to use the legacy (xtables) backend to load firewall rules in early boot. When lxd and multipass are started, they see that legacy rules are in use and use xtables). Similarly, on an Ubuntu 22.04 system that is configured with the default iptables-nft backend, the ufw deb from Ubuntu will follow the iptables symlink to use the nft (netfilter) backend to load firewall rules in early boot. When lxd and multipass are started, the see that nft rules are in use and use netfilter. Users upgrading from earlier distributions that defaulted to the legacy backend to newer releases that use the nft backend may find that non- distro software isn't choosing the correct backend. You can see if this is the case by running: $ sudo iptables-nft -S and compare with: $ sudo iptables-legacy -S If one is populated and the other comes back with only: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT then everything should be operating together ok. You should also check ip6tables-nft vs ip6tables-legacy and if you have 'nft' on your system, see that 'sudo nft list ruleset' has only accept rules if 'iptables- legacy -S' shows rules are in use. If there is a mixture of rules in both backends, you'll need to make everything use either netfilter or xtables. If things were working correctly before the upgrade, you might find that going back to iptables-legacy could make things work until you're ready to migrate to iptables-nft (on Debian/Ubuntu, see update-alternatives, above). The 'docker' snap as of 20.10.12 in the stable channel is known to unconditionally use xtables. At the time of this filing, it did not have a way to adjust to using netfilter, so if using the docker snap, you might have to update your system to use iptables-legacy (on Debian/Ubuntu, see update-alternatives, above). Finally, if using various container/VM software with ufw on the host and everything agrees on using the same backend, you might check
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Tags removed: block-proposed block-proposed-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: Invalid Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
https://launchpad.net/ubuntu/+source/ufw/0.36.1-3ubuntu1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: Invalid Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Changed in: ufw (Ubuntu) Status: New => Triaged ** Changed in: cloud-init (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: Invalid Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Oh! I missed from the initial report that network-pre was deleted which clears up things considerably on my end (since I wasn't able to reproduce, I didn't see it locally either). :) Preparing an upload now. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: Invalid Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time
Thanks for the response and glad you got it worked out. It reminds me that I would like to document using fail2ban with ufw more. ** Changed in: ufw (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: Invalid Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client reload PIDFile=/run/fail2ban/fail2ban.pid Restart=on-failure RestartPreventExitStatus=0 255 [Install] WantedBy=multi-user.target - root@loki:/etc/default# cat ufw # /etc/default/ufw # # Set to yes to apply rules to support IPv6 (no me
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
> This makes me want to understand the cloud-init configuration that is in play. Can you share it? I'm thinking I should upload: DefaultDependencies=no Before=network-pre.target Wants=network-pre.target local-fs.target After=local-fs.target Do you have any objections? This would remove the explicit sysinit from the dependency equation but I think it would otherwise achieve ufw's startup objectives. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: New Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
> I don't believe your reproducer is valid - cloud-init is not installed anymore, as autopkgtest-buildvm-ubuntu-cloud removes it when building the VM, whereas it remains on the cloud images, as it's needed there to actually get the IP address during boot. Note, in https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/comments/9 I installed cloud-init and did some analysis also (but see below). > Though arguably I'd expect this to be fixed by removing DefaultDependencies again, if I looked at this correctly. Seems likely, though this change was done to fix an issue people were seeing on stack exchange for Debian/Ubuntu systems related to a race between encrypted filesystems and ufw. I guess I could add back DefaultDependencies=no and add After=local-fs.target, but I'm not sure what this would do in practice since local-fs.target is so close to the end of sysinit anyway (but see below). In 0.36.1-2, ufw has: DefaultDependencies=no Before=network.target In 0.36.1-3, ufw has (no DefaultDependencies=no): Before=network-pre.target Wants=network-pre.target cloud-init has (among other things): Before=sysinit.target Before=network-pre.target Wants=network-pre.target AIUI, with 0.36.1-2, ufw will tend to start right away due to DefaultDependencies=no and so will cloud-init so long as it finishes before sysinit. ufw need only finish before network.target, which is after network-pre.target. Eg, ufw and cloud-init race to complete but otherwise their dependencies directly don't affect each other. With 0.36.1-3, cloud-init starts early and before ufw since it must finish before sysinit.target and ufw cannot start until after sysinit.target is done. Because both must finish before network- pre.target, this pushes network-pre.target after sysinit (and of course, ufw), but other than that, there shouldn't be a problem since we have: 1. cloud-init starts / finishes 2. sysinit starts / finishes 3. ufw starts / finishes 4. network-pre reached 5. systemd-networkd starts / finishes 6. network reached IME, there is no obvious problem with the dependencies (as they relate to ufw) since cloud-init is allowed to start/finish before sysinit and network-pre just like before. It is just that now network-pre is guaranteed to be after sysinit (which from cloud-init's point of view, shouldn't necessarily be a concern). It is also guaranteed to be after ufw but, unless cloud-init is doing something with ufw such as perhaps enabling ufw and restarting the ufw service, cloud-init shouldn't care cause the ufw service doesn't do anything unless ufw is enabled (and even when it is enabled, it just loads firewall rules). This makes me want to understand the cloud-init configuration that is in play. Can you share it? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: New Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networ
[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time
> How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? This line from your existing fail2ban.service should be sufficient: After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service See https://www.freedesktop.org/software/systemd/man/systemd.unit.html for details ("After= is the inverse of Before=, i.e. while Before= ensures that the configured unit is started before the listed unit begins starting up, After= ensures the opposite, that the listed unit is fully started up before the configured unit is started.") -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: Incomplete Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in f
[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time
> 4. you didn't mention which distro you are using This would be good to know since some distros are using iptables 1.8.x which has two different backends that are in play. Which distro are you using and what is the output of `iptables --version` -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: Incomplete Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client reload PIDFile=/run/fail2ban/fail2ban.pid Restart=on-failure RestartPreventExitStatus=0 255 [Install] WantedBy=multi-user.target - root@loki:/etc/default# cat ufw # /etc/default/ufw
[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time
Thanks for the bug report. A few things: 1. I'm not sure what 'networking stops' means precisely in the context of this bug report. Does 'ufw disable' restore the network? Is the network torn down? Something else (you are using a lot of limit rules instead of allow rules, I wonder if you are hitting limits...)? 2. 'journalctl -u ufw.service' isn't normally going to show you much since the command run from the service isn't very chatty. Better would be to look at /var/log/ufw.log around the time the networking stops. If /var/log/ufw.log doesn't exist on your distro, you should check /var/log/kern.log for firewall denials and then try to resolve them with new/modified firewall rules 3. It isn't clear if you used the check-requirements from https://git.launchpad.net/ufw/tree/tests/check-requirements or the one on the system. Which did you use? (Note, I just made a change to https://git.launchpad.net/ufw/tree/tests/check-requirements that you might want to use) 4. you didn't mention which distro you are using, but the ufw.service file is not what is shipped upstream (or Ubuntu or Debian). This is what has been shipped in Ubuntu and Debian for several years: [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target and this is what is upstream (Debian is the same except omits the 'Conflicts') and what should solve some issues (though I'm not sure it would solve your issues: [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) Before=network-pre.target Wants=network-pre.target Conflicts=iptables.service ip6tables.service nftables.service firewalld.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target You may want to adjust the service file to be like the upstream one, then run 'sudo systemctl daemon-reload' and reboot. ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: Incomplete Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pa
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Attachment added: "plot-2.svg" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+attachment/5550320/+files/plot-2.svg -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Attachment added: "plot-3.svg" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+attachment/5550321/+files/plot-3.svg -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Attached are two 'systemd-analyze plot's for the autopktest jammy system with cloud-init and ufw installed. plot-2.svg is for booting the system with 0.36.1-2 (current jammy) and plot-3.svg is 0.36.1-3 (proposed jammy). Notice how plot-2.svg, ufw and systemd-networkd start quite a bit earlier than in plot-3.svg. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
@juliank - note I wasn't so much talking about 'blame' as much as understanding, so I apologize if it came across that way. Since I wasn't able to reproduce, I was trying to reason through my thoughts to help the discussion go further since I'm not able to diagnose it myself. In a nutshell, I have concerns that the ufw service has a side effect that somewhere else in the system is dependent on. That other part of the system should be setup to work without ufw in the mix. I'm also concerned that users might face issues if ufw is purged or if other similarly configured software is installed (eg, firewalld). With that in mind, it seems odd that a service that does nearly nothing by default would affect the system by having a Before/Wants on network- pre.target. It also seems odd that going from very little dependencies (DefaultDependencies=no) to have only those for 'basic system initialization' would be a problem since those are not related to networking, etc. Eg, in today's autopkgtest jammy instance that I created with `autopkgtest-buildvm-ubuntu-cloud -r jammy` and rebooting with the proposed -3 of ufw installed: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu Jammy Jellyfish (development branch) Release:22.04 Codename: jammy $ cat /proc/version_signature Ubuntu 5.13.0-19.19-generic 5.13.14 $ systemctl list-dependencies ufw.service ufw.service ● ├─system.slice ● ├─network-pre.target ● └─sysinit.target ● ├─apparmor.service ● ├─dev-hugepages.mount ● ├─dev-mqueue.mount ● ├─keyboard-setup.service ● ├─kmod-static-nodes.service ● ├─multipathd.service ● ├─plymouth-read-write.service ○ ├─plymouth-start.service ● ├─proc-sys-fs-binfmt_misc.automount ● ├─setvtrgb.service ● ├─sys-fs-fuse-connections.mount ● ├─sys-kernel-config.mount ● ├─sys-kernel-debug.mount ● ├─sys-kernel-tracing.mount ● ├─systemd-ask-password-console.path ○ ├─systemd-binfmt.service ○ ├─systemd-boot-system-token.service ● ├─systemd-journal-flush.service ● ├─systemd-journald.service ○ ├─systemd-machine-id-commit.service ● ├─systemd-modules-load.service ○ ├─systemd-pstore.service ● ├─systemd-random-seed.service ● ├─systemd-sysctl.service ● ├─systemd-sysusers.service ● ├─systemd-timesyncd.service ● ├─systemd-tmpfiles-setup-dev.service ● ├─systemd-tmpfiles-setup.service ● ├─systemd-udev-trigger.service ● ├─systemd-udevd.service ● ├─systemd-update-utmp.service ● ├─cryptsetup.target ● ├─local-fs.target ● │ ├─-.mount ● │ ├─boot-efi.mount ○ │ ├─systemd-fsck-root.service ● │ └─systemd-remount-fs.service ● ├─swap.target ● └─veritysetup.target Seeing what depends on ufw, there is very little: $ systemctl list-dependencies ufw.service --reverse ufw.service ● └─multi-user.target ● └─graphical.target I can also say that nothing in this VM depends on network-pre other than ufw: $ systemctl list-dependencies --reverse network-pre.target network-pre.target ● └─ufw.service and that there is not much depending on network.target: $ systemctl list-dependencies --reverse network.target network.target ○ ├─netplan-ovs-cleanup.service ● └─systemd-networkd.service Rebooting with ufw -2 installed, all of the above is the same except ufw's dependencies are nearly nothing: $ systemctl list-dependencies ufw.service ufw.service ● └─system.slice This autopkgtest VM doesn't have cloud-init installed (which is consistent with why I'm not seeing it in here like I am not in Debian) and I don't know what cloud-init config to provide to provide any additional diagnosis. I can say that if I install cloud-init, it add a dependency on on network-pre.target (still with -2 of ufw): $ systemctl list-dependencies network-pre.target --reverse network-pre.target ○ └─cloud-init-local.service It has: $ cat /usr/lib/systemd/system/cloud-init-local.service [Unit] Description=Initial cloud-init job (pre-networking) DefaultDependencies=no Wants=network-pre.target After=hv_kvp_daemon.service After=systemd-remount-fs.service Before=NetworkManager.service Before=network-pre.target Before=shutdown.target Before=sysinit.target Conflicts=shutdown.target RequiresMountsFor=/var/lib/cloud [Service] Type=oneshot ExecStart=/usr/bin/cloud-init init --local ExecStart=/bin/touch /run/cloud-init/network-config-ready RemainAfterExit=yes TimeoutSec=0 # Output needs to appear in instance console output StandardOutput=journal+console [Install] WantedBy=cloud-init.target I notice that it has a `Before=sysinit.target` and DefaultDependencies=no. Is cloud-init in our infrastructure configured to run ufw? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: New Bug description:
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Changed in: ufw (Ubuntu) Status: Triaged => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Incomplete Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
@juliank - where did you see these errors? I booted with a freshly created autopkgtest jammy vm, installed the package from proposed and it worked fine. Please see my previous comments-- this does not seem to be a bug in ufw since it is using the documented unit setup that systemd recommends for firewall software (and that other firewall software use, such as firewalld) and this has been in Debian for some time now with no bug reports (indeed, it solved issues). Your initial report shows that lots of other units have the ordering cycle issue that you mentioned so I'm not sure why ufw would be singled out. So we're all on the same page, this was the change: -DefaultDependencies=no -Before=network.target +Before=network-pre.target +Wants=network-pre.target and I'll add this from debian/changelog: +- use Before and Wants on network-pre.target. Per systemd documentation, + "network-pre.target is a target that may be used to order services + before any network interface is configured. Its primary purpose is for + usage with firewall services". Because network-pre.target is a passive + unit, "services that want to be run before the network is configured + should place Before=network-pre.target and also set + Wants=network-pre.target to pull it in" +- remove DefaultDependencies=no so that we pull in default dependencies + for "basic system initialization". While ufw is meant to come up before + networking, there is no reason why it shouldn't come up after sysinit. + This should help make ufw startup more robust on systems that need + something from sysinit. The ufw unit itself does very little unless ufw is enabled since /lib/ufw/ufw-init exits very quickly when it is not enabled. As such, it seems to me that the ufw upload may have uncovered a latent issue in our early boot (but that wouldn't be a bug in ufw itself) where Ubuntu may not be supporting the documented behavior for network-pre.target. Finally, it has been a couple of months since this report; is it possible to rerun wherever this was run to see if it is still an issue (as mentioned, no bug reports in Debian and so perhaps things floated in that resolved this)? I would rerun autopkgtests, but they all have passed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug
[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot
@Stefan, I suggest you try the fix that is in Debian. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834#27 @Myron, yours sounds like a different issue. I suggest you file a new bug, downloading https://git.launchpad.net/ufw/tree/tests/check- requirements and including the output of 'sudo sh /path/to/check- requirements'. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Invalid Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Xenial: Invalid Status in ufw source package in Bionic: Invalid Status in ufw source package in Cosmic: Invalid Status in ufw source package in Disco: Invalid Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python
** Also affects: ufw Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1951018 Title: No ability to discern IPv4 vs IPv6 rules through Python Status in ufw: New Status in ufw package in Ubuntu: New Bug description: Version: ufw 0.36 Ubuntu Version: 20.04.3 LTS There doesn't appear to be a Python method for accessing IPv4 and IPv6 rules in a distinguishable manner. In the source code (root/src/backend.py) there is an object that stores IPv4 and IPv6 rules in separate lists. Those lists are then accessed with the following method: def get_rules(self): '''Return list of all rules''' return self.rules + self.rules6 The issue with this is that the returned list doesn't contain an indication of what IP version each item corresponds to and would display something like the following. 1 allow 22/tcp 2 allow 80 3 allow 443 4 allow 22/tcp 5 allow 80 6 allow 443 I don't currently see a way to distinguish between IPv4 and IPv6 rules other than accessing the lists in the backend object directly (but I don't think this is best practice). E.g.: rules_ipv4 = backend.rules rules_ipv6 = backend.rules6 One possible fix would be to add functions that return only the IPv4 or IPv6 rules. E.g.: def get_rules_ipv4(self): '''Return list of all ipv4 rules''' return self.rules def get_rules_ipv6(self): '''Return list of all ipv6 rules''' return self.rules6 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1951018/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Also, to be clear, when I say I can't look at the ufw portions 'for a while', I mean ~10 days (doing this from my phone). Thinking about this, my thinking is this is less about the Before/Wants on network-pre and the removal of DefaultDependencies and more about Before=network being removed (with perhaps nothing else doing that? ie, I don't think this an ufw bug; I think the change uncovered something). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
I mention firewalld cause while ufw could be reverted, firewalld users would presumably also hit it, as well as any other software that does it. If the ufw change is reverted, IME someone should audit the archive for other occurrences of this pattern and update the units accordingly). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Fyi, the current configuration is the same as firewalld upstream and what is in Debian, Moreover it is following systemd documentation for firewall software so I wonder if the change simply uncovered a latent bug Fyi, I won't be able to look at this for a while so if you need to back it out, please do an ubuntu1 upload (though it would be great if someone more familiar with systemd-networkd thought through my latent bug comment). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
Tested 0.36-0ubuntu0.18.04.2 on bionic. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I didn't test on an iSCSI system so won't add verification-done-focal at this time, but I think the testing is probably sufficient for that (I'll let others decide). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Status in ufw source package in Impish: Fix Committed Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...>
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
Tested 0.36-6ubuntu1 on focal. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I didn't test on an iSCSI system so won't add verification-done-focal at this time, but I think the testing is probably sufficient for that (I'll let others decide). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Status in ufw source package in Impish: Fix Committed Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset re
[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
Tested 0.36-0ubuntu0.18.04.2 on bionic. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I was able to verify the this bug is fixed via the test steps. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Bug description: [Impact] * The deletion of a rule without the 'proto' field that has a similar rule *with* the 'proto' field might delete the wrong rule (the latter). * This might cause services to be inaccessible or incorrectly allowed, depending on rule ordering (read original description below for examples.) [Test Steps] * Add rules: ufw allow from 1.1.1.1 port proto tcp ufw allow from 2.2.2.2 port proto tcp ufw allow from 1.1.1.1 port * Check iptables: iptables -L ufw-user-input -n ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt: * Delete the third rule above ufw status numbered yes | ufw delete 3 * Check iptables again: iptables -L ufw-user-input -n Observed: (deleted tcp line from first rule, and udp line from third rule) ... ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: Expected: (deleted both tcp and udp lines from third rule) ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: [Regression Potential] * Potential regressions would be observed when deleting rules. * This fix has been suggested for SRU by jdstrand [1], and has already been available in 21.04 and the snap. [1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005 [Original Description] UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible.
[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
Tested 0.36-6ubuntu1 on focal. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order. I was able to verify the this bug is fixed via the test steps. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Bug description: [Impact] * The deletion of a rule without the 'proto' field that has a similar rule *with* the 'proto' field might delete the wrong rule (the latter). * This might cause services to be inaccessible or incorrectly allowed, depending on rule ordering (read original description below for examples.) [Test Steps] * Add rules: ufw allow from 1.1.1.1 port proto tcp ufw allow from 2.2.2.2 port proto tcp ufw allow from 1.1.1.1 port * Check iptables: iptables -L ufw-user-input -n ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt: * Delete the third rule above ufw status numbered yes | ufw delete 3 * Check iptables again: iptables -L ufw-user-input -n Observed: (deleted tcp line from first rule, and udp line from third rule) ... ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: Expected: (deleted both tcp and udp lines from third rule) ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: [Regression Potential] * Potential regressions would be observed when deleting rules. * This fix has been suggested for SRU by jdstrand [1], and has already been available in 21.04 and the snap. [1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005 [Original Description] UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible. Instead if one had the initial configuration... ufw
[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot
I've looked at this issue again in reference to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834 and while I still cannot reproduce, I plan to change to the following (I won't ship the commented out lines of course): [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) #DefaultDependencies=no #Before=network.target Before=network-pre.target Wants=network-pre.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target This removes DefaultDependencies=no so that 'sysinit' will be pulled in and changes the single 'Before=network.target' to instead have Before=network-pre.target and Wants=network-pre.target. This won't help people who have different firewall software installed (like some of the comments), but should make startup more robust (eg, for those needing something from sysinit) while still allowing it to come up before the network. ** Bug watch added: Debian Bug tracker #990834 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Invalid Status in ufw package in Ubuntu: Invalid Status in ufw source package in Xenial: Invalid Status in ufw source package in Bionic: Invalid Status in ufw source package in Cosmic: Invalid Status in ufw source package in Disco: Invalid Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
Ah, I hadn't checked that yet. Yes, please feel free to do the Impish SRU and the 0.36.1-2 that I just uploaded to Debian will float into 'J' after it opens. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: New Status in ufw source package in Bionic: New Status in ufw source package in Focal: New Status in ufw source package in Hirsute: New Status in ufw source package in Impish: New Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. Functional tests summary Attempted: 22 (3339 individual tests) Skipped: 0 Errors: 0 [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 seconds. ... [ 435.707549] session1: session recovery timed out after 120 secs [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could not log back into <...> [age 0] [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device [ 436.134354] sd 1
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
For Impish, lets update debian/master, then I'll upload there and sync to Ubuntu. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: New Status in ufw source package in Bionic: New Status in ufw source package in Focal: New Status in ufw source package in Hirsute: New Status in ufw source package in Impish: New Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. Functional tests summary Attempted: 22 (3339 individual tests) Skipped: 0 Errors: 0 [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 seconds. ... [ 435.707549] session1: session recovery timed out after 120 secs [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could not log back into <...> [age 0] [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device [ 436.134354] sd 12:0:0:1: [sda] tag#105 CDB: Read(10) 28 00 00 05 8d d8 00 00 08 00 [ 436.
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
I merged the changes into master. Thanks Mauricio! ** Changed in: ufw Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: New Status in ufw source package in Bionic: New Status in ufw source package in Focal: New Status in ufw source package in Hirsute: New Status in ufw source package in Impish: New Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. Functional tests summary Attempted: 22 (3339 individual tests) Skipped: 0 Errors: 0 [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 seconds. ... [ 435.707549] session1: session recovery timed out after 120 secs [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could not log back into <...> [age 0] [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device [ 436.134354] sd 12:0:0:1: [sda] tag#105 CDB: Read(10) 28 00 00 05 8d
[Touch-packages] [Bug 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap
Olivier, yes, I shouldn't be assigned. Ian, you're right the profile is suboptimal (it's also old so likely needs updating). Do note that this is a separate named profile and evince (and if this is put in an abstraction, anything that uses the abstraction) only has the `/{,snap/core/[0-9]*/}usr/bin/snap mrCx -> snap_browser,` rule which means that it is able to run the 'snap' command (needed since everything in /snap/bin points to /usr/bin/snap) which at the time I wrote the profile meant that access to this socket was needed as part of snap run. IIRC, snapd should be protecting certain actions by uid connecting to it (eg, you are root or not), but it has been a while since I've looked at that. Evince is not a snap though so if snapd does any checks on 'is the client a snap' then those would fail and evince would be able to do whatever a non-root user could do with the 'snap' command via the socket. For snap run, we can see that the snap_browser profile limits what can be used with 'run' since (at the time I wrote the comment) 'snap run' required being able to look at the meta/snap.yaml of the specific snap. This 'works' (worked?) but is brittle since if snap run changed to lift this requirement (eg, 'snap run' just passed the name of the unresolved symlink to snapd over the socket and let snapd start the snap, perhaps via userd, etc) then this falls apart. The profile was put up as an example as what could be done at the time without any help from snapd. I never particularly cared for it cause it was brittle and not designed. I'm not sure how to fix this, but here are some thoughts: * evince is just executing stuff from /snap/bin (probably via the system's xdg-open). Assuming xdg-open, the system's xdg-open (or whatever evince is using to decide and launch the default browser) could itself be fixed in Ubuntu to launch a different command that behaved better. This wouldn't necessarily fix other distros (though this is the evince profile in Debian and Ubuntu, so *technically*, if you got this change (to presumably xdg-open) into them, you could update the evince profile in them accordingly) * In lieu of that, if the profile still worked as intended, snapd could be hardened to look to check more than if the connecting process is root or a snap; it could also see if it is running under a non-snap profile, then limit access to the socket API accordingly. This has drawbacks and could break people who have written custom profiles similar to what I presented. * I suppose an alternative approach would be to have symlinks in /snap/bin for things that are registered as browsers (or just the default browser) point to a designed snap command. Eg: /snap/bin/firefox -> /usr/bin/snap # keep the existing one too /snap/bin/default-browser-is-a-snap -> /usr/bin/snap-browser # name is illustrative, TBD Now firefox, chromium, opera, brave, etc snaps registers themselves as being capable of being a default browser with snapd, then snapd registers with the system that /snap/bin/default-browser-is-a-snap is the default browser (so system utilities like xdg-open don't need to change) and /usr/bin/snap-browser is written to be safe (eg, only able to 'snap run' the configured default browser, nothing else) and apparmor profiles are adjusted to have `/{,snap/core/[0-9]*/}usr/bin/snap-browser Uxr,` (or similar). The /snap/bin/default-browser-is-a-snap path is illustrative and there isn't really a need for it at all. Could simply perhaps have snapd register /usr/bin/snap-browser as the default browser on the system (it now needs to know what snapd configured as the default browser snap though) and forego the symlink. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1794064 Title: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap Status in apparmor package in Ubuntu: Confirmed Status in evince package in Ubuntu: Triaged Bug description: This is related to bug #1792648. After fixing that one (see discussion at https://salsa.debian.org/gnome-team/evince/merge_requests/1), clicking a hyperlink in a PDF opens it correctly if the default browser is a well-known application (such as /usr/bin/firefox), but it fails to do so if the default browser is a snap (e.g. the chromium snap). This is not a recent regression, it's not working on bionic either. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: evince 3.30.0-2 ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5 Uname: Linux 4.18.0-7-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 24 12:28:06 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2016-07-02 (813 days ago) InstallationMedia: Ubuntu 16.04 LTS
[Touch-packages] [Bug 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap
** Changed in: evince (Ubuntu) Assignee: Jamie Strandboge (jdstrand) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1794064 Title: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap Status in apparmor package in Ubuntu: Confirmed Status in evince package in Ubuntu: Triaged Bug description: This is related to bug #1792648. After fixing that one (see discussion at https://salsa.debian.org/gnome-team/evince/merge_requests/1), clicking a hyperlink in a PDF opens it correctly if the default browser is a well-known application (such as /usr/bin/firefox), but it fails to do so if the default browser is a snap (e.g. the chromium snap). This is not a recent regression, it's not working on bionic either. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: evince 3.30.0-2 ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5 Uname: Linux 4.18.0-7-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 24 12:28:06 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2016-07-02 (813 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: evince UpgradeStatus: Upgraded to cosmic on 2018-09-14 (9 days ago) modified.conffile..etc.apparmor.d.abstractions.evince: [modified] mtime.conffile..etc.apparmor.d.abstractions.evince: 2018-09-24T11:35:41.904158 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1794064/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
** Also affects: ufw (Ubuntu) Importance: Undecided Status: New ** Changed in: ufw (Ubuntu) Status: New => In Progress ** Changed in: ufw (Ubuntu) Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: In Progress Bug description: UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible. Instead if one had the initial configuration... ufw insert 1 reject from 1.0.0.0/8 to any port 22 ufw insert 2 allow from any to any port 22 ...which was later updated to be... ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp ufw insert 2 allow from any to any port 22 proto tcp yes | ufw delete 3 ...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible. A reboot is required to fix the issue, as it reloads the configuration to the expected order. To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1933117/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot
@cajicas215 - your comment is not helpful. If you look at the other comments in this bug, there has been nothing to fix in ufw. I suggest looking at the comments in this bug and seeing if any of the issues others have seen apply to you. If not, please report a new bug with steps to reproduce. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Invalid Status in ufw package in Ubuntu: Invalid Status in ufw source package in Xenial: Invalid Status in ufw source package in Bionic: Invalid Status in ufw source package in Cosmic: Invalid Status in ufw source package in Disco: Invalid Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot
@Fabian - your change both makes the firewall start after networking, brings python into the boot process (which can slow down boot) and changes the intent of 'systemctl stop ufw' from unloading the firewall to disabling the firewall in the moment and forever in the future, which is inappropriate ('systemctl stop' is supposed to stop the service until someone runs 'systemctl start' again or reboot. 'systemctl disable' is meant to prevent the service from starting on reboot. This might be fine for your system, but it would not be appropriate as a default in ufw or distributions. Also, this bug is in upstream ufw and you are reporting an issue on Raspbian, who would supply the packaging for ufw. If you still feel the change should be made, I suggest filing a bug with Raspbian so they can change their packaging of ufw. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Invalid Status in ufw package in Ubuntu: Invalid Status in ufw source package in Xenial: Invalid Status in ufw source package in Bionic: Invalid Status in ufw source package in Cosmic: Invalid Status in ufw source package in Disco: Invalid Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1934931] Re: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently
It is unclear from the description that this has anything to do with networking. Are there any firewall denials in the logs (eg, /var/log/ufw.log or /var/log/kern.log)? If you disable ufw (sudo ufw disable) does the problem go away? As an aside, IIRC, MS-Teams is not a lightweight application and I suspect this could be memory consumption unrelated to the firewall. ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1934931 Title: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently Status in Gufw: Invalid Status in ufw package in Ubuntu: Incomplete Bug description: Thanks for Gufw! inxi -S output: Xubuntu standard LTS installation - Kernel: 5.4.0-77-generic x86_64 bits: 64 Desktop: Xfce 4.14.2 Distro: Ubuntu 20.04.2 LTS (Focal Fossa). GUFW 20.04.1, MS Teams 1.4.00.13653 (64-Bit) (all up to date at the time of this report). ** Problem: 250 Mbit LAN connection slowing down *intermittently*, but reproducible, to a crawl of 300 kbit or less if Gufw is activated parallel to MS teams. * Gufw is used with only basic settings provided after installation (in:denied/out:allowed and nothing else set, no further rules). * There has not to be any active call in teams, just running it seems to cause the problem after a while (<5 minutes). * After congestion for some time (minutes), the system may recover to full speed again, only to succumb again after a few minutes. * Other parallel running programs' connections are slowed down as well in accordance, e.g. parallel samba file sharing download is affected as well. * Stopping teams restores the connection speed after a short while (~1 minute). * Parallel connections to the LAN(router) are not inhibited, it is just the one computer. Teams seems to switch ports after restarting (UDP6/~34nnn-4). I set up a range to be allowed within ports used by teams (e.g. 3:5, allow in/outbound) to no avail, connections dropped still to low speed. Thanks and regards, Christoph To manage notifications about this bug go to: https://bugs.launchpad.net/gui-ufw/+bug/1934931/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1921350] Re: UFW hangs indefinitely on any action
There is another bug related to ansible in https://bugs.launchpad.net/ufw/+bug/1911637. I suggest following that one. Leaving this one as Expired. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1921350 Title: UFW hangs indefinitely on any action Status in ufw package in Ubuntu: Expired Bug description: When installing a new cloudserver (on Amazon EC2, if it makes a difference), UFW completely hangs on any command, for example ufw status. Interrupting it with Ctrl+C yields this backtrace: Traceback (most recent call last): File "/usr/sbin/ufw", line 130, in lock = create_lock(lockfile=lockfile, dryrun=pr.dryrun) File "/usr/lib/python3/dist-packages/ufw/util.py", line 1112, in create_lock fcntl.lockf(lock, fcntl.LOCK_EX) KeyboardInterrupt The line numbers are always the same. The platform is Ubuntu Server 20.04 (Ubuntu 20.04.2 LTS), from the Amazon image. I have not seen this bug on other servers. UFW is version 0.36. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1909373] Re: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10
There isn't anything in the logs the indicates that there what happened. Do you have any other information? ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1909373 Title: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10 Status in ufw package in Ubuntu: Incomplete Bug description: dont upgrade ProblemType: Package DistroRelease: Ubuntu 18.04 Package: ufw 0.36-0ubuntu0.18.04.1 Uname: Linux 3.18.14-17162658-QB35446819 aarch64 ApportVersion: 2.20.9-0ubuntu7.21 Architecture: arm64 Date: Sat Dec 26 20:56:19 2020 Df: Filesystem 1K-blocks Used Available Use% Mounted on rootfs 24604780 19261268 5251352 79% / tmpfs1434188 1020 1433168 1% /dev Dmesg: ErrorMessage: installed ufw package post-installation script subprocess returned error exit status 10 PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.5, unpackaged PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, unpackaged RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: ufw Title: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1909373/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1898696] Re: add some deliminiter between ipv4 and ipv6 in ufw status
Thanks you for the report. It is difficult to convey ipv4 vs ipv6 vs both in list form and currently ufw lists any ipv6 rules with '(v6)' as part of the To and From (as seen in your paste). It isn't clear to me how adding an 'IPv6' break would improve this... I'm going to mark this as wishlist while I think about it. Regarding the side note, the person who posted the question was unaware of https://bugs.launchpad.net/ufw/+bug/1880453 which speaks to future support (it isn't needed as ufw will use the nft backend if the system is configured to do so). ** Changed in: ufw (Ubuntu) Importance: Undecided => Wishlist ** Changed in: ufw (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1898696 Title: add some deliminiter between ipv4 and ipv6 in ufw status Status in ufw package in Ubuntu: Confirmed Bug description: "ufw status numbered" shows all the rules in one block, numbered from top to bottom. First are the ipv4 rules, then the ipv6. This has led to some irritation. A user asked how to add a IPv4 rule to the end of the list. https://answers.launchpad.net/ubuntu/+source/ufw/+question/692096 Inserting ipv6 rules to the correct position is not easy to understand https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1368411 My suggestion is to at least add some separator between the ipv4 and ipv6 rules in the output of "ufw status". A blank line, or a comment line (# IPv6 rules:) would be fine. This would indicate that not both rule lists, but only one of them, is applied to a connection. ## output suggestion: Status: active To Action From -- -- [ 1] 22/tcp ALLOW INAnywhere [ 2] 8080:8090/tcp ALLOW INAnywhere # mywww [ 3] WWW Full ALLOW INAnywhere # IPv6 rules: [ 4] 22/tcp (v6)ALLOW INAnywhere (v6) [ 5] 8080:8090/tcp (v6) ALLOW INAnywhere (v6) # mywww [ 6] WWW Full (v6) ALLOW INAnywhere (v6) ## system info ufw --version: ufw 0.35 side note But maybe this is irrelevant as long as the future plans of ufw are unclear. (https://answers.launchpad.net/ubuntu/+source/ufw/+question/692803) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1898696/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911637] Re: Another app is currently holding the xtables lock
** Changed in: ufw Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1911637 Title: Another app is currently holding the xtables lock Status in ufw: Triaged Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: New Bug description: Version: ufw 0.36 (via Debian buster 0.36-1 deb-package) I'm using ufw together with fail2ban, and often I get an error while fail2ban is trying to ban an ip: ``` ERROR: initcaps [Errno 2] Another app is currently holding the xtables lock. Perhaps you want to use the -w option? ``` it seems that in utils.py, get_netfilter_capabilities(...) iptables is called without "-w" flag to wait for the table lock perhaps the checks should include this parameter to avoid leaving temporary tables behind (and breaking fail2ban, but thats a different story ...)? To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911637] Re: Another app is currently holding the xtables lock
Actually, in thinking about this, ufw could use 'iptables -w' under the hood. I recall having troubles with this approach when providing the fix for https://bugs.launchpad.net/ufw/+bug/1204579. I suggest following my advice in my last comment to avoid the issue while using 'iptables -w' is explored. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1911637 Title: Another app is currently holding the xtables lock Status in ufw: Triaged Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: New Bug description: Version: ufw 0.36 (via Debian buster 0.36-1 deb-package) I'm using ufw together with fail2ban, and often I get an error while fail2ban is trying to ban an ip: ``` ERROR: initcaps [Errno 2] Another app is currently holding the xtables lock. Perhaps you want to use the -w option? ``` it seems that in utils.py, get_netfilter_capabilities(...) iptables is called without "-w" flag to wait for the table lock perhaps the checks should include this parameter to avoid leaving temporary tables behind (and breaking fail2ban, but thats a different story ...)? To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911637] Re: Another app is currently holding the xtables lock
Thanks for the report. I read the ansible bug but this issue is actually coming from the underlying iptables tool. Something on the system is manipulating the firewall via iptables at the same time that the ufw command is being run. As described, this would happen with any firewall software. If only ufw is being used with ansible, perhaps ensure that the ufw commands are not being run in parallel. The upstream bug referenced docker, which will also manipulate the firewall with iptables; perhaps ensure that ufw configuration is applied before docker is started. I'm going to mark this bug as Invalid for now. Feel free to provide more information if you feel this is specific to ufw. ** Changed in: ufw (Ubuntu) Status: Confirmed => Invalid ** Changed in: ufw (Ubuntu) Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1911637 Title: Another app is currently holding the xtables lock Status in ufw: Triaged Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: New Bug description: Version: ufw 0.36 (via Debian buster 0.36-1 deb-package) I'm using ufw together with fail2ban, and often I get an error while fail2ban is trying to ban an ip: ``` ERROR: initcaps [Errno 2] Another app is currently holding the xtables lock. Perhaps you want to use the -w option? ``` it seems that in utils.py, get_netfilter_capabilities(...) iptables is called without "-w" flag to wait for the table lock perhaps the checks should include this parameter to avoid leaving temporary tables behind (and breaking fail2ban, but thats a different story ...)? To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1938005] Re: ufw ignores rules
Recall that ufw uses connection tracking so if you add a deny rule, you may need to expire the connection tracking. One way to do this is to run: `conntrack -D -d ` (see man conntrack for details). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1938005 Title: ufw ignores rules Status in ufw package in Ubuntu: Incomplete Bug description: With my setting I shouldn't be able to surf web, but I can do it (without proxy/vpn) This problem happens after `iptables -F` and only way to solve it, is to reboot PC. I tried `ufw reload` , too ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: ufw 0.36-7.1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Mon Jul 26 11:53:17 2021 EcryptfsInUse: Yes InstallationDate: Installed on 2021-06-17 (38 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1938005] Re: ufw ignores rules
/etc/default/ufw has: DEFAULT_OUTPUT_POLICY="ACCEPT" This means that all outgoing traffic is allowed. If you would like to change that, you can use: $ sudo ufw deny outgoing This will make it more difficult for you to manage the firewall since you'll have to add rules like: $ sudo ufw allow out to any port 53 and the like. Note, using 'ufw reload' may not work as expected if you are running iptables commands by hand underneath it. In those case, I suggest: $ sudo /lib/ufw/ufw-init flush-all $ sudo ufw disable $ sudo ufw enable Please report back. Thanks again for the report. ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1938005 Title: ufw ignores rules Status in ufw package in Ubuntu: Incomplete Bug description: With my setting I shouldn't be able to surf web, but I can do it (without proxy/vpn) This problem happens after `iptables -F` and only way to solve it, is to reboot PC. I tried `ufw reload` , too ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: ufw 0.36-7.1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Mon Jul 26 11:53:17 2021 EcryptfsInUse: Yes InstallationDate: Installed on 2021-06-17 (38 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1938005] Re: ufw ignores rules
Thank you for the bug report. You mentioned that the problem happens after running `iptables -F`. This command removes all the rules from the firewall (see man iptables) so it would be expected that the firewall would not work correctly after running this. I'm going to mark this as Invalid, but if you have more information, feel free to add it. ** Changed in: ufw (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1938005 Title: ufw ignores rules Status in ufw package in Ubuntu: Invalid Bug description: With my setting I shouldn't be able to surf web, but I can do it (without proxy/vpn) This problem happens after `iptables -F` and only way to solve it, is to reboot PC. I tried `ufw reload` , too ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: ufw 0.36-7.1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Mon Jul 26 11:53:17 2021 EcryptfsInUse: Yes InstallationDate: Installed on 2021-06-17 (38 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1921350] Re: UFW hangs indefinitely on any action
Thanks you for reporting a bug. Are there other ufw commands running at the same time? Eg, what is the output of: $ ps auxww|grep ufw ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1921350 Title: UFW hangs indefinitely on any action Status in ufw package in Ubuntu: Incomplete Bug description: When installing a new cloudserver (on Amazon EC2, if it makes a difference), UFW completely hangs on any command, for example ufw status. Interrupting it with Ctrl+C yields this backtrace: Traceback (most recent call last): File "/usr/sbin/ufw", line 130, in lock = create_lock(lockfile=lockfile, dryrun=pr.dryrun) File "/usr/lib/python3/dist-packages/ufw/util.py", line 1112, in create_lock fcntl.lockf(lock, fcntl.LOCK_EX) KeyboardInterrupt The line numbers are always the same. The platform is Ubuntu Server 20.04 (Ubuntu 20.04.2 LTS), from the Amazon image. I have not seen this bug on other servers. UFW is version 0.36. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused
Thanks for the additional information! :) ** Changed in: ufw (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1914816 Title: ufw not logging if it decides to stop all traffic ? Confused Status in ufw package in Ubuntu: Invalid Bug description: Sorry, this is going to be a very bad report. Here's what I did: - installed gufw and enabled it, no rules, just default incoming=deny outgoing=accept - rebooted - Ethernet says it connected - no network access; ping 1.1.1.1 fails - launch gufw, and it says it's disabled (the whole firewall) - I think eventually I figured out that iptables had been emptied and INPUT chain set to DROP After many travails, I captured a piece of dmesg output as the system was booting, and I think it shows ufw trying to check IPv6 status and deciding to stop everything. At least logging (which was set to full in gufw) suddenly stops. In network manager, I've tried to say "ignore IPv6". I'm not sure if this trouble is related to fiddling with the "only work if IPv4 is enabled" check-box, which seems to have a ToolTip that is exactly backwards. My ISP does not give IPv6 service. I've tried many settings of the IPv6 drop-down in System Settings / Network GUI, setting and clearing the IPv4 and IPv6 required check-boxes, etc. So, I'm totally confused, but I think the log shows that logging suddenly stops (from full to zero), which must mean ufw detected some condition that made it empty out the iptables and set everything to DROP ? If so, ufw should have logged a message saying it was doing so, and I don't see such a message. So, if I'm right, at least this is a feature request that ufw should log a message when it decides to stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all rules. Sorry about the mess of a report. I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7 ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: ufw (not installed) ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Fri Feb 5 20:35:18 2021 InstallationDate: Installed on 2021-02-03 (2 days ago) InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused
The check is not free, but it is an interesting idea to do this. I've created a wishlist bug for it: https://bugs.launchpad.net/ufw/+bug/1917325 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1914816 Title: ufw not logging if it decides to stop all traffic ? Confused Status in ufw package in Ubuntu: Invalid Bug description: Sorry, this is going to be a very bad report. Here's what I did: - installed gufw and enabled it, no rules, just default incoming=deny outgoing=accept - rebooted - Ethernet says it connected - no network access; ping 1.1.1.1 fails - launch gufw, and it says it's disabled (the whole firewall) - I think eventually I figured out that iptables had been emptied and INPUT chain set to DROP After many travails, I captured a piece of dmesg output as the system was booting, and I think it shows ufw trying to check IPv6 status and deciding to stop everything. At least logging (which was set to full in gufw) suddenly stops. In network manager, I've tried to say "ignore IPv6". I'm not sure if this trouble is related to fiddling with the "only work if IPv4 is enabled" check-box, which seems to have a ToolTip that is exactly backwards. My ISP does not give IPv6 service. I've tried many settings of the IPv6 drop-down in System Settings / Network GUI, setting and clearing the IPv4 and IPv6 required check-boxes, etc. So, I'm totally confused, but I think the log shows that logging suddenly stops (from full to zero), which must mean ufw detected some condition that made it empty out the iptables and set everything to DROP ? If so, ufw should have logged a message saying it was doing so, and I don't see such a message. So, if I'm right, at least this is a feature request that ufw should log a message when it decides to stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all rules. Sorry about the mess of a report. I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7 ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: ufw (not installed) ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Fri Feb 5 20:35:18 2021 InstallationDate: Installed on 2021-02-03 (2 days ago) InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 881137] Re: UFW does not clean iptables setting from /etc/ufw/before.rules
CzBiX, ufw does not yet manage the nat table (though there have been a couple of false starts). However, it does manage the FORWARD chain with 'ufw route' so it is possible for you to create a chain in the nat table in /etc/ufw/before.rules, and then use ufw route for other things. This is described in 'man ufw-framework' in the EXAMPLES section. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/881137 Title: UFW does not clean iptables setting from /etc/ufw/before.rules Status in ufw package in Ubuntu: Won't Fix Bug description: Adding some additional settings to /etc/ufw/before.rules is not deleted when ufw is stopped. I added these lines at top of file /etc/ufw/before.rules *nat :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o eth0 -j MASQUERADE COMMIT Then I reloaded ufw firewall with command: ufw reload. Output from iptables-save $ iptables-save -t nat *nat :PREROUTING ACCEPT [4:478] :INPUT ACCEPT [4:478] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o eth0 -j MASQUERADE COMMIT Then I reloaded ufw firewall again: $ iptables-save -t nat *nat :PREROUTING ACCEPT [4:478] :INPUT ACCEPT [4:478] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o eth0 -j MASQUERADE -A POSTROUTING -o eth0 -j MASQUERADE COMMIT And ufw reload again $ iptables-save -t nat *nat :PREROUTING ACCEPT [4:478] :INPUT ACCEPT [4:478] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o eth0 -j MASQUERADE -A POSTROUTING -o eth0 -j MASQUERADE -A POSTROUTING -o eth0 -j MASQUERADE COMMIT And again and postrouting is never deleted when ufw is stopped and added again when stared. Same happen if I stop ufw firewall with: $ stop ufw. nat lines are not cleaned. UFW should remove all iptables settings specified in config files after ufw is stopped! This can be dangerous if apt-get is updating some ufw files and scripts needs to reload ufw (some lines will be more times). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/881137/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused
Hi. A few things: ufw is capable of logging (see 'man ufw' the part about 'ufw logging' as well as per rule logging with 'ufw ... log' or 'ufw ... log-all'. It is also capable of ipv6 (see /etc/default/ufw. Also, gufw is a different project than ufw, but it sounds like the issue you saw may be seeing is another firewall is in place. What is the output of 'sudo /usr/share/ufw/check-requirements'? ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1914816 Title: ufw not logging if it decides to stop all traffic ? Confused Status in ufw package in Ubuntu: Incomplete Bug description: Sorry, this is going to be a very bad report. Here's what I did: - installed gufw and enabled it, no rules, just default incoming=deny outgoing=accept - rebooted - Ethernet says it connected - no network access; ping 1.1.1.1 fails - launch gufw, and it says it's disabled (the whole firewall) - I think eventually I figured out that iptables had been emptied and INPUT chain set to DROP After many travails, I captured a piece of dmesg output as the system was booting, and I think it shows ufw trying to check IPv6 status and deciding to stop everything. At least logging (which was set to full in gufw) suddenly stops. In network manager, I've tried to say "ignore IPv6". I'm not sure if this trouble is related to fiddling with the "only work if IPv4 is enabled" check-box, which seems to have a ToolTip that is exactly backwards. My ISP does not give IPv6 service. I've tried many settings of the IPv6 drop-down in System Settings / Network GUI, setting and clearing the IPv4 and IPv6 required check-boxes, etc. So, I'm totally confused, but I think the log shows that logging suddenly stops (from full to zero), which must mean ufw detected some condition that made it empty out the iptables and set everything to DROP ? If so, ufw should have logged a message saying it was doing so, and I don't see such a message. So, if I'm right, at least this is a feature request that ufw should log a message when it decides to stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all rules. Sorry about the mess of a report. I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7 ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: ufw (not installed) ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Fri Feb 5 20:35:18 2021 InstallationDate: Installed on 2021-02-03 (2 days ago) InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1897369] Re: apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE)
Till, it allows quite a few things (from man capabilities): CAP_SYS_NICE * Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes; * set real-time scheduling policies for calling process, and set scheduling policies and priorities for arbitrary processes (sched_setscheduler(2), sched_setparam(2), sched_setattr(2)); * set CPU affinity for arbitrary processes (sched_setaffinity(2)); * set I/O scheduling class and priority for arbitrary processes (io‐ prio_set(2)); * apply migrate_pages(2) to arbitrary processes and allow processes to be migrated to arbitrary nodes; * apply move_pages(2) to arbitrary processes; * use the MPOL_MF_MOVE_ALL flag with mbind(2) and move_pages(2). cups-browsed is probably just trying to renice itself, which isn't terrible for it to try, but it probably fails gracefully with this just being noise. If it does fail gracefully, you could consider an explicit deny rule to silence the log. Eg: deny capability sys_nice, That said, we've normally allowed system policy (ie, those shipped in debs) to use sys_nice if they have a legitimate use case for it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1897369 Title: apparmor: Allow cups-browsed to change nice value (CAP_SYS_NICE) Status in cups package in Ubuntu: Confirmed Bug description: In Ubuntu 20.04.1 with *cups-browsed* 1.27.4-1, apparmor prevents `/usr/sbin/cups-browsed` to change its nice value. $ sudo dmesg | grep apparmor [541870.509461] audit: type=1400 audit(1600898428.089:60): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=62030 comm="cups-browsed" capability=23 capname="sys_nice" [628298.779668] audit: type=1400 audit(1600984854.115:61): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=66850 comm="cups-browsed" capability=23 capname="sys_nice" [714667.424963] audit: type=1400 audit(1601071220.527:62): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=76828 comm="cups-browsed" capability=23 capname="sys_nice" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1897369/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain
FYI, sponsored Alex's upload to hirsute-proposed where it is building. Did the same for groovy-proposed and it is sitting in unapproved waiting for the next steps of the SRU process. ** Changed in: iptables (Ubuntu) Status: Confirmed => Fix Committed ** Changed in: iptables (Ubuntu) Assignee: (unassigned) => Alex Murray (alexmurray) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain Status in iptables: Unknown Status in iptables package in Ubuntu: Fix Committed Status in iptables source package in Groovy: In Progress Status in iptables package in Debian: Unknown Status in iptables package in Fedora: Fix Committed Bug description: [SRU] * Changes that went into 1.8.5 ave broken the errno handling. In particular loading extensions. Due to that it has become impossible to rename rules. * Upstream has created a fix and this backports that change to Ubuntu => http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247 [Test Case] * # ebtables -t nat -N foo # ebtables -t nat -E foo bar ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists * with the fix the above command sequence works [Where problems could occur] * The change moved code from nft_chain_user_rename to do_commandeb and therefore in theory any ebtables/xtables subcommand could be affected. Yet what it does is just resetting the error code in a better place, so while it "could" affect every subcommand it should (tm) not do so. [Other Info] * n/a --- Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed Groovy/Hirsute (Fail): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. What might be the root cause for this? -- Old test instructions -- As I said I was tracking a fail in libvirt so the test instructions initially were around that: # the following us done as 2nd level guest (to not mess with the host, # but works on bare metal jst as much) uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily # On guest then sudo apt update sudo apt install uvtool uvtool-libvirt uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm release=hirsute arch=amd64 label=daily uvt-kvm wait hirsute-2nd-lvm virsh shutdown hirsute-2nd-lvm virsh edit hirsute-2nd-lvm # add this to the network virsh start hirsute-2nd-lvm error: Failed to start domain hirsute-2nd-nwfilter error: internal error: applyDHCPOnlyRules failed - spoofing not protected! FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf log_filters="1:util.firewall" log_outputs="1:syslog:libvirtd" -- -- [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037 To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1904192/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5
FYI, 1.8.5-3ubuntu3 was uploaded to hirsute-proposed yesterday. 1.8.5-3ubuntu2.20.10.1 is in the unapproved queue for groovy-proposed. Alex said he'd do the SRU paperwork. ** Changed in: iptables (Ubuntu Hirsute) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1898547 Title: neutron-linuxbridge-agent fails to start with iptables 1.8.5 Status in iptables package in Ubuntu: Fix Committed Status in neutron package in Ubuntu: Invalid Status in iptables source package in Groovy: Triaged Status in neutron source package in Groovy: Invalid Status in iptables source package in Hirsute: Fix Committed Status in neutron source package in Hirsute: Invalid Bug description: Ubuntu Groovy (20.10) kernel 5.8.0-20-generic neutron-linuxbridge-agent: 2:17.0.0~git2020091014.215a541bd4-0ubuntu1 iptables: 1.8.5-3ubuntu1 (nf_tables) iptables-restore points to xtables-nft-multi After upgrading iptables from 1.8.4 to 1.8.5 and rebooting the neutron network node, neutron-linuxbridge-agent didn't properly start anymore. The log file shows many errors like: 2020-10-05 10:20:37.998 551 ERROR neutron.plugins.ml2.drivers.agent._common_agent ; Stdout: ; Stderr: iptables-restore: line 29 failed Downgrading iptables to 1.8.4 solves the problem. Trying to do what the linuxbridge agent does: 2020-10-05 10:20:37.998 551 ERROR neutron.plugins.ml2.drivers.agent._common_agent *filter 2020-10-05 10:20:37.998 551 ERROR neutron.plugins.ml2.drivers.agent._common_agent :FORWARD - [0:0] shows that iptables-restore
[Touch-packages] [Bug 1899218] Re: Incorrect warning from apparmor_parser on force complained profiles
FYI, this is part of the groovy upload in unapproved. ** Changed in: apparmor (Ubuntu) Status: New => Fix Committed ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => John Johansen (jjohansen) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1899218 Title: Incorrect warning from apparmor_parser on force complained profiles Status in apparmor package in Ubuntu: Fix Committed Bug description: apparmor_parser on a force complained profile produces an incorrect warning message: $ sudo apparmor_parser -rW /etc/apparmor.d/usr.sbin.sssd Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing complain mode Warning from /etc/apparmor.d/usr.sbin.sssd (/etc/apparmor.d/usr.sbin.sssd line 54): Warning failed to create cache: usr.sbin.sssd Even though not generating the cache at all is expected, the warning should describe caching is disabled for force complained profiles instead of failure to create it. $ lsb_release -rd Description: Ubuntu Groovy Gorilla (development branch) Release: 20.10 $ apt-cache policy apparmor apparmor: Installed: 3.0.0~beta1-0ubuntu6 Candidate: 3.0.0~beta1-0ubuntu6 Version table: *** 3.0.0~beta1-0ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1899218/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1899046] Re: /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39
This has been uploaded to groovy and is currently in unapproved. ** Changed in: apparmor (Ubuntu) Status: In Progress => Fix Committed ** Changed in: apparmor (Ubuntu) Assignee: (unassigned) => Emilia Torino (emitorino) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1899046 Title: /usr/bin/aa-notify:ModuleNotFoundError:/usr/bin/aa-notify@39 Status in apparmor package in Ubuntu: Fix Committed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding apparmor. This problem was most recently seen with package version 3.0.0~beta1-0ubuntu6, the problem page at https://errors.ubuntu.com/problem/69bb6832fe7b294bd7e2d75970fdc903f412c409 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1899046/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot
@Muhammad - can you run: $ sudo /usr/share/ufw/check-requirements and paste the results? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Invalid Status in ufw package in Ubuntu: Invalid Status in ufw source package in Xenial: Invalid Status in ufw source package in Bionic: Invalid Status in ufw source package in Cosmic: Invalid Status in ufw source package in Disco: Invalid Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp