I went through the last couple of logs afer the first round of 'turn
off the spiders' went out. I looked at the areas which the /robots.txt
disregard and then looked for the bots which ignored it and still
looked up stuff in 'accounts'. This may cut down CPU spikes as these
are looking at dynamic data which can 'blow' things up.
It might be good to add similar tooling to pagure and src since they
seem to be hit a lot in the logs also.
Signed-off-by: Stephen Smoogen <ssmoogen@redhat.com>
The mirrormanager application moved over to
mirrormanager.fedoraproject.org from
admin.fedoraproject.org/mirrormanager. So we need to change this
redirect to point things to the new place.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This crawler is doing about 2M requests a day to
lists.fedoraproject.org. This is causing db load on db01, causing
services to have issues.
So, block them here for now, but we may want to block them elsewhere
too.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This removes osbs and allmost all it's associated playbooks and files.
It served long and well, but we no longer need it.
flatpaks are building with a koji-flatpak plugin.
base/minimal/toolbox containers are building with kiwi.
We aren't building any other containers right now, and we did they could
be added to kiwi.
This is the end of an era... I look with nostolga on
ansible-ansible-openshift-ansible (a role to setup ansible on a control
host and run it from our ansible).
Good bye osbs!
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
alt.fpo/en/cloud is still the first link to pop up on search engine and
the current redirect only works with /cloud.
This commit fix the redirect, and prevent this old page to be indexed.
New ipa checks the referrer to avoid CSRF issues.
We need to have the proxy edit requests for the right internal hostname
for it to be able to work.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Turns out back in 2015 (in 623be6ff73) I added a robots.txt on the koji
hubs to disallow crawling, but since it's behind the proxies, no one
ever saw that robots.txt. Instead they got the default one that just had
a 'crawl-delay 1' in it.
So, lets tell robots to go away for real now, as they are causing load
problems on the koji database and I don't think it's particularly useful
for koji to be indexed. It's a lot of dynamic content anyhow.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
f39 adds flatpaks for ppc64le, so we need to allow ppc64le builders to
access the registry directly so they can install flatpaks in the ostree
install images. Without this they try and get them from the cdn and the
builder firewall blocks them and it times out and the image fails to
compose.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Right now we only exclude the builders on 10.3.169 from using the
registry cdn (ie, the x86_86 builders), but we also make aarch64
containers/images and we should exclude it too ( 10.3.170.x ).
This might fix a weird compose failure we have been getting on
aarch64 ostree installer images.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
The proxies seem to be hitting file limits, so try increasing them.
Also, set httpd to restart on failure, this should help mask the problem
if it persists with the higher limit.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Our openshift 3.11 cluster(s) served us long and well.
Now we have everything finally moved to the openshift 4 clusters (fas2
was the last holdout). We can finally retire this. :)
🎉🥂
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
I think I handled all the special cases here already.
We want to switch non iad2 proxies to reach the oco4 cluster over it's
vpn now that it has one. This should allow us to still keep ipv6
available for applications and not have to change dns for moving from
ocp3 cluster anymore. Will roll this out slowly to one proxy then
another, then the rest if it all looks ok.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
The ocp3 cluster is reachable/available via the vpn, so any proxy can
reach it.
The ocp4 cluster is (at least for now) only reachable/available from the
iad2 proxies (proxy01/proxy10).
There's a firefox bug that causes it to reuse h2 connections, and in
some cases try and request something of a non iad2 proxy that it can't
reach. To work around this in those cases we need to send a 421 back to
the client so it doesn't do that.
This moves that logic into the template so all ocp4: true hosts do this
by default. Also, we default the balancer nodes so we only have to
change them in one place if we remove/add a compute node.
Finally, we mark all the ocp3 apps with 'ocp4: false' so we know what
they are and can move them more easily.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This is the fun firefox h2 connection reuse bug. blockerbugs is only in
iad2, so if firefox tries to reuse a connection to another proxy for it,
just send it a 421 so it knows thats bad on it.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Due to http/2 connection reuse bugs, sometimes firefox will decide to
'reuse' a connection to fedoraproject.org for openqa.fedoraproject.org
(since they both have the same tls cert), but openqa is only available
from the 2 iad2 proxies, not all of them. This results in a 503 timeout
and it just not loading. This should make those reused connections get a
421 from proxies and reconnect to the proper ips. (we hope)
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
