The provider of proxy05 is moving resources to a new cloud, so proxy05 will be down during this move.
We need to disable it in dns before the move and then check it and reenable after the move.
There should not be any user facing impact, so we don't need to announce this or update status for it.
Location: Frankfurt Data Center Date: January 6, 2026 Time: 12:00 AM – 6:00 AM CET Estimated Duration: Approximately 1–2 hours per VM
Is it worth keeping it in DNS until near the time? Otherwise seems much easier to remove it Monday, and add it back Wednesday.
Sure, it's just more stress on other proxies with that one out of dns, but a day or two should be fine.
Metadata Update from @phsmoura: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: low-gain, low-trouble, ops, outage
Metadata Update from @james: - Issue assigned to james
Okay, proxy05 removed from DNS.
I think this can come back now? I tried ssh'ing to the IP address listed in the inventory and it works.
Hi,
Could it be that it was not removed from all DNS?
$ dig +short +noshort @ns02.fedoraproject.org mirrors.fedoraproject.org mirrors.fedoraproject.org. 300 IN CNAME wildcard.fedoraproject.org. wildcard.fedoraproject.org. 60 IN A 38.145.32.20 wildcard.fedoraproject.org. 60 IN A 185.141.165.254 wildcard.fedoraproject.org. 60 IN A 18.157.159.91 wildcard.fedoraproject.org. 60 IN A 85.236.55.6 wildcard.fedoraproject.org. 60 IN A 152.2.23.104 wildcard.fedoraproject.org. 60 IN A 35.178.204.134 wildcard.fedoraproject.org. 60 IN A 152.2.23.103 wildcard.fedoraproject.org. 60 IN A 38.145.32.21 wildcard.fedoraproject.org. 60 IN A 3.70.22.218
It's still showing here (185.141.165.254).
Next to that, the mirror service on it is broken: curl --resolve mirrors.centos.org:443:185.141.165.254 -v "https://mirrors.centos.org/metalink?repo=centos-baseos-9-stream&arch=x86_64&protocol=https,http" responds with a 503.
curl --resolve mirrors.centos.org:443:185.141.165.254 -v "https://mirrors.centos.org/metalink?repo=centos-baseos-9-stream&arch=x86_64&protocol=https,http"
Can this be resolved asap? Cause this breaks dnf update commands etc...
I think this is fixed now ... vpn didn't come up and dns search was "cs1cloud.internal" ... seems to be working again now.
Metadata Update from @james: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)