#13007 proxy05 outage 2026-01-06
Closed: Fixed by james. Opened by kevin.

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.

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)

Metadata