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>
Found the reason that the definitions I had put were not
working. There were two different ones and i was looking at the wrong
one. Put the two tasks with the same logic so things should work no
matter which one is run.
We need to always run these even in check mode, because they register
things used in the last one of them. So, this could change this in check
mode if we modify it. Be careful!
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Just writing a config file isn't enough, apparently. We need to
really call update-crypto-policies. This attempts to do so, but
only if it's really necessary, by using some handy check args.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is VASTLY better than the hack we have in base now to try and setup
ifcfg files. It uses a standard role that has lots of options and does
the right thing with NetworkManager. Ideally we would switch everything
to this, but lets try it here first to see. It should work with bridges,
etc as well.
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>
This task seems to fail with a nameserver failed to answer message when
you provision a bunch of hosts at once. Try running just one at a time
and see if it helps any.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
