I can confirm that without linux-modules-extra-*, iptables is broken.
Reduced test case:
$ sudo iptables -L -n
iptables: No chain/target/match by that name.
Full test case:
$ sudo /usr/share/ufw/check-requirements -f
...
ERROR: could not create 'ufw-check-requirements'. Aborting
FAIL: check your
Marking the ufw task as Invalid. The kernel doesn't have what is needed
to run iptables.
** Changed in: ufw (Ubuntu)
Status: New => Invalid
** Changed in: ufw (Ubuntu)
Assignee: Jamie Strandboge (jdstrand) => (unassigned)
--
You received this bug notification because you are a
This might have some implications for fan usage on cloud instances as I
see some fan-* rules post switch to generic kernel.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
Dropping ufw from the test case - just running sudo iptables-save
against the virtual kernel produces no output.
--
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/1823862
Title:
Diff between two identical instances, one with -generic and one with
-virtual.
iptables* commands working find with -generic.
** Attachment added: "kernel-diff.txt"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823862/+attachment/5254621/+files/kernel-diff.txt
--
You received this
OK I think I've figured it out; the cloud images use the -virtual
kernel, which does not install linux-modules-extra-*.
If I install the -generic kernel or just the extra modules and reboot,
then iptables commands start working again.
** Changed in: ufw (Ubuntu)
Status: Incomplete => New
main diff there is py2.7 vs py3 (but that's cause swift still uses
python2)
--
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/1823862
Title:
disco: unable to enable ufw
Status
I also tested on a pristine machine:
$ sudo /usr/share/ufw/check-requirements
Has python: pass (binary: python3.7, version: 3.7.3, 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
check-requirements from failing swift unit:
$ sudo /usr/share/ufw/check-requirements
Has python: pass (binary: python2.7, version: 2.7.16, py2)
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
"I can only think this is something cloud-image specific."
Can you provide the requested information in the earlier comments?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
I can only think this is something cloud-image specific.
FTR the policy is initially configured wide open (as the server may be
doing a number of other things the charm deploying does not know about)
and then the ports for swift/rsync are restricted to peers.
--
You received this bug
Another thing that might be useful is attaching a tarball of /lib/ufw,
/etc/ufw, and /etc/default/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/1823862
Title:
disco:
FYI, I also tried the above with setting /etc/default/ufw to have
IPV6=no and everything works fine (and the v6 rules are not added).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
You said that the swift charm is disabling ipv6 in certain situations.
Is it updating /etc/default/ufw? Is it disabling it elsewhere? In the
failing instance, before trying to setup swift or run ufw or anything,
what is the output of 'sudo /usr/share/ufw/check-requirements'?
--
You received this
The usefulness of the policy aside (it is configured wide open), I still
can't reproduce with http://cdimage.ubuntu.com/ubuntu-
server/daily/current/disco-server-amd64.iso that I just downloaded:
$ sudo ufw default allow incoming
Default incoming policy changed to 'allow'
(be sure to update your
this translates into:
ufw default allow incoming
ufw default allow outgoing
ufw default allow routed
ufw allow rsync
ufw allow ssh
ufw enable
which gets us to the:
ufw.enable(soft_fail=config('allow-ufw-ip6-softfail'))
which is where the failure to enable occurs.
--
You received this bug
OK so there is a little modification of the policy prior to enablement:
def initialize_ufw():
"""Initialize the UFW firewall
Ensure critical ports have explicit allows
:return: None
"""
if not config('enable-firewall'):
log("Firewall has been administratively
I'm trying to figure out what is modifying /etc/default/ufw - the swift-
storage charm does but it just disables IPv6 in some situations.
I reported this from a different cloud instance - so probably worth
mentioning that this is a disco image running on openstack from the
daily image stream.
--
I cannot reproduce. I notice that you said 'default install' but at a
minimum you have modified /etc/default/ufw to have:
DEFAULT_INPUT_POLICY="ACCEPT"
$ cat /proc/version_signature
Ubuntu 5.0.0-8.9-generic 5.0.1
$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with
19 matches
Mail list logo
