This `[0:]` syntax doesn't seem to be correct. iptables 1.8.10
errors out on encountering it, saying:
invalid policy counters for chain 'PREROUTING'
this seems to be because the check was tightened between 1.8.9
and 1.8.10 to apply even when iptables is not actively restoring
the counters:
https://git.netfilter.org/iptables/commit/?id=4a2b2008fdf4df980433f99a6d8f2003f2005296
I think these are all meant to be 0:0, so let's make them that
and stop iptables choking.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We want to move (well, really re-install) all these over on the new lpar
in rdu. This will have much higher stats and be in general faster by
both network and cpu. Hopefully all these will replace all the old
boston ones.
We may need to break these up some more into smaller vm's if the number
isn't able to keep up ok. We can adjust after things are all working.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Lets move this vm over to rdu, and set it up as a new varnish cache.
This way we can test 01 doing builds before moving others.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Setup osbuild so it only needs to exist on the specific builders in the
osbuild channel, not all builders.
Also, setup things so we can add a blocklist that will block external
subnets/ip's if we need to do so. Currently it should just be an empty
set, but we can implement it as needed/desired starting with the ips we
already were blocking on just some hosts.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
While we actually use SLAAC in aws, there's a dhcp6d sending out the
router advertisements, so without that the instance doesn't get an ipv6
ip and just doesn't work. With this it does.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This is a quick, hacked up script that just runs once per minute and
updates the ip addresses for the osbuild koji plugin. The script calls
systemd's resolvectl without cache and puts the ips in a ipset. The
koji_builder firewall has a added rule to check that ipset for outgoing
connections that are allowed.
TODO: add some kind of error checking
TODO: probibly won't work on s390x builders as they can't reach the host
even with open firewalls, but should work for others.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Most of our vpn hosts are on a 192.168.1.0/24 network.
However we have a small number on a 'less secure' 'less trusted' subnet:
192.168.100.0/24. This change adds in logic to:
* on log01, allow rsyslog from 192.168.100.x hosts
* on ipa servers, allow ipa ports for 192.168.100.x hosts
* then reject everything else.
This will make sure 192.168.100.x hosts can only hit ssh and the two
above items, otherwise all vpn hosts will reject their traffic. This
should add a bit of security to having those hosts on the vpn.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This should only affect stg hosts.
We had set all of iad2 the same, prod and stg both.
We need to make sure stg resolves to stg hosts first.
This worked somewhat until now because we replace the resolv.conf on stg
hosts, but without this they are borken right after boot and until we
replace the resolv.conf and restart httpd or other services.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Note that this will not yet work, it needs the RHIT firewall between
vlans opened on these ports first, but after that this is needed to
allow them to use those ports.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
In IAD2 the prod and stg hosts are on different VLANs, so we thought we
didn't need this. However, we are still seeing some odd mixing of prod
and stg fedmsgs, so likely some fedmsg port has become enabled accross
all the VLANS. In any case this should do no harm, it just adds 2
subnets on all prod hosts to block staging, except for a small number of
staging_friendly hosts (in the staging_friendly ansible group).
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Moving the local to s390x cache from 07 (a zvm instance) to 24 (a kvm
instance) needs to adjust the firewalls for those builders to know that
they can use port 80 on the new one. After that we will update dns to
point it to the new location.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Actually it's only the varnish caching host that needs to talk to them
at this point, but might as well allow it on any of them in case we
switch how the caching works there or the like.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
