On Tue, 28 Oct 2014 11:07:31 -0400 "Paul W. Frields" stickster@gmail.com wrote:

The firewalld rich language is probably also worth looking into -- if for no other reason than to determine whether it is capable of handling these use cases. If not, we should file RFEs upstream because we I'm betting we're not *that* special. :-)

Sure. When we moved to Fedora builders we just had that down as a "todo later when we get time" and we just haven't had that time yet. ;)

For this particular thing we can set it up so ansible restarts libvirtd (if and only if it's installed) when iptables restarts. It's just moving a task so we have our conditional restart and adding it to the iptables play. I'll do that after freeze.

kevin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Tue, 28 Oct 2014 11:07:31 -0400 "Paul W. Frields" stickster@gmail.com wrote:

On Tue, Oct 28, 2014 at 08:50:29AM -0600, Stephen John Smoogen wrote:

...

On 28 October 2014 08:04, Matthew Miller mattdm@fedoraproject.org wrote:

...

It's my understanding (Dennis please correct if I'm wrong) that the problem with cloud image creation was due to libvirt iptables rules being lost when iptables was restarted. This is a fundamental known issue (see last paragraph of http://libvirt.org/firewall.html), and one of the things firewalld was meant to solve.

Dennis says that there are lot of complicated rules on the builders making switching to firewalld difficult. One possibility might be to move those complicated rules from the builders to a network firewall, and keep the host rules simple and functional. But that's probably a big undertaking.

It would be.. It would be creating a new network for these boxes, putting the hardware behind such a firewall, setting up routing for such devices etc etc. [Plus a budget needed for that hardware.]

...

In the meantime, any time iptables is restarted or reloaded, libvirt needs a SIGHUP. (I suppose this means: ansible playbooks and also added to any manual procedures.)

That actually would be 'easier' to set up even if it is a cron job which

checks to see if a marker is in iptables and if not sends a sighup to libvirt

The firewalld rich language is probably also worth looking into -- if for no other reason than to determine whether it is capable of handling these use cases. If not, we should file RFEs upstream because we I'm betting we're not *that* special. :-)

if you checkout ansible git you cand find the rules we have

cat ./roles/base/templates/iptables/iptables.kojibuilder # {{ ansible_managed }} *filter :INPUT DROP [] :FORWARD DROP [] :OUTPUT DROP []

# loopback allowed - -A INPUT -i lo -j ACCEPT - -A OUTPUT -o lo -j ACCEPT - -A INPUT -i virbr0 -j ACCEPT - -A OUTPUT -o virbr0 -j ACCEPT - -A INPUT -d 127.0.0.0/8 -j ACCEPT - -A OUTPUT -d 127.0.0.0/8 -j ACCEPT

# Accept ping and traceroute (needs icmp) - -A INPUT -p icmp -j ACCEPT - -A OUTPUT -p icmp -j ACCEPT

# Established connections allowed - -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT - -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# kojipkgs - -A OUTPUT -p tcp -m tcp -d 10.5.125.36 --dport 80 -j ACCEPT

#koji.fp.o - -A OUTPUT -p tcp -m tcp -d 10.5.125.63 --dport 80 -j ACCEPT - -A OUTPUT -p tcp -m tcp -d 10.5.125.63 --dport 443 -j ACCEPT

#arm.koji.fp.o - -A OUTPUT -p tcp -m tcp -d 10.5.124.138 --dport 80 -j ACCEPT - -A OUTPUT -p tcp -m tcp -d 10.5.124.138 --dport 443 -j ACCEPT

# compose-x86-02.fp.o - -A OUTPUT -p tcp -m tcp -d 10.5.125.42 --dport 80 -j ACCEPT - -A OUTPUT -p tcp -m tcp -d 10.5.125.42 --dport 443 -j ACCEPT

# DNS - -A OUTPUT -p udp -m udp -d 10.5.126.21 --dport 53 -j ACCEPT - -A OUTPUT -p udp -m udp -d 10.5.126.22 --dport 53 -j ACCEPT

# bastion smtp - -A OUTPUT -p tcp -m tcp -d 10.5.126.12 --dport 25 -j ACCEPT

# infra.fp.o - -A OUTPUT -p tcp -m tcp -d 10.5.126.23 --dport 80 -j ACCEPT - -A OUTPUT -p tcp -m tcp -d 10.5.126.23 --dport 443 -j ACCEPT

# rsyslog out to log01 - -A OUTPUT -p tcp -m tcp -d 10.5.126.29 --dport 514 -j ACCEPT

# SSH - -A INPUT -p tcp -m tcp -s 10.5.0.0/16 --dport 22 -j ACCEPT - -A OUTPUT -p tcp -m tcp -d 10.5.0.0/16 --sport 22 -j ACCEPT

# for ansible accelerate mode - allow port 5099 from lockbox and it's ips - -A INPUT -p tcp -m tcp --dport 5099 -s 192.168.1.58 -j ACCEPT - -A INPUT -p tcp -m tcp --dport 5099 -s 10.5.126.23 -j ACCEPT - -A INPUT -p tcp -m tcp --dport 5099 -s 10.5.127.51 -j ACCEPT - -A INPUT -p tcp -m tcp --dport 5099 -s 209.132.181.6 -j ACCEPT

# git to pkgs - -A OUTPUT -m tcp -p tcp --dport 9418 -d 10.5.125.44 -j ACCEPT - -A OUTPUT -m udp -p udp --dport 9418 -d 10.5.125.44 -j ACCEPT

# http to pull sources from pkgs lookaside - -A OUTPUT -m tcp -p tcp --dport 80 -d 10.5.125.44 -j ACCEPT

# git to fedorahosted - -A OUTPUT -m tcp -p tcp --dport 9418 -d 66.135.62.191 -j ACCEPT - -A OUTPUT -m udp -p udp --dport 9418 -d 66.135.62.191 -j ACCEPT

#nfs to vtap-fedora-nfs01.storage.phx2.redhat.com - a little to wide-open - but # kinda necessary - -A INPUT -m tcp -p tcp -s 10.5.88.36 -j ACCEPT - -A OUTPUT -m tcp -p tcp -d 10.5.88.36 -j ACCEPT - -A INPUT -m udp -p udp -s 10.5.88.36 -j ACCEPT - -A OUTPUT -m udp -p udp -d 10.5.88.36 -j ACCEPT

# ntp - -A OUTPUT -m udp -p udp --dport 123 -d 66.187.233.4 -j ACCEPT - -A OUTPUT -m udp -p udp --dport 123 -d 192.43.244.18 -j ACCEPT - -A OUTPUT -m udp -p udp --dport 123 -d 128.118.25.5 -j ACCEPT - -A OUTPUT -m udp -p udp --dport 123 -d 204.152.184.72 -j ACCEPT

# dhcp - -A OUTPUT -m udp -p udp --dport 67 -d 10.5.126.41 -j ACCEPT

# if the host/group defines incoming tcp_ports - allow them {% for port in tcp_ports %} - -A INPUT -p tcp -m tcp --dport {{ port }} -j ACCEPT {% endfor %}

# if the host/group defines incoming udp_ports - allow them {% for port in udp_ports %} - -A INPUT -p udp -m udp --dport {{ port }} -j ACCEPT {% endfor %}

# if there are custom rules - put them in as-is {% for rule in custom_rules %} {{ rule }} {% endfor %}

COMMIT

they are not overly special just overly restrictive. I really do not know what it would take to enable the rules to work using firewalld. but anyone wanting to take a look the work would be welcome

Dennis