Reachability problems for packages6.icinga.com

Since a while we had multiple problems with the repository that is running under packages6.icinga.com. We need to use this repo because our infrastructure is IPv6 only. We now observe massive and random reachability issues. For example if we try to download the gpg key we see a pattern of random reachability:

root@node5:~# curl https://packages6.icinga.com/icinga.key
<html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/1.14.0 (Ubuntu)</center>
</body>
</html>
root@node5:~# curl -I https://packages6.icinga.com/icinga.key
HTTP/1.1 200 OK
Server: nginx/1.14.0 (Ubuntu)
Date: Fri, 11 Sep 2020 09:54:36 GMT
Content-Type: application/pgp-keys
Content-Length: 1723
Connection: keep-alive
Last-Modified: Tue, 12 Jul 2016 09:07:03 GMT
ETag: "6bb-5376c97a7e975"
Accept-Ranges: bytes

root@node5:~# curl -I https://packages6.icinga.com/icinga.key
HTTP/1.1 504 Gateway Time-out
Server: nginx/1.14.0 (Ubuntu)
Date: Fri, 11 Sep 2020 09:56:22 GMT
Content-Type: text/html
Content-Length: 192
Connection: keep-alive

root@node5:~# curl -I https://packages6.icinga.com/icinga.key
HTTP/1.1 200 OK
Server: nginx/1.14.0 (Ubuntu)
Date: Fri, 11 Sep 2020 09:56:42 GMT
Content-Type: application/pgp-keys
Content-Length: 1723
Connection: keep-alive
Last-Modified: Tue, 12 Jul 2016 09:07:03 GMT
ETag: "6bb-5376c97a7e975"
Accept-Ranges: bytes

root@node5:~# curl -I https://packages6.icinga.com/icinga.key
HTTP/1.1 504 Gateway Time-out
Server: nginx/1.14.0 (Ubuntu)
Date: Fri, 11 Sep 2020 09:57:45 GMT
Content-Type: text/html
Content-Length: 192
Connection: keep-alive

So currently this repo isn’t usable at all. From the results I would guess that there is a problem with a load balancer or the system is just overloaded. Anyway it would be great if someone could take a look.

Well… a broken repo is even worse than no repo. So please, fix this!

Hi @leah,

sorry for the late reply! I’ve just tested it a few times and didn’t get a gateway timeout. Will keep an eye on this issue.

Did this happen many times or just a few times out of many tries?

Greetings
Noah

Hey,

thanks for the reply. It happens most of the time but if it works it works for a while. At the moment it works for the host from the output above. But I have 20 hosts here that are on the exact same network with the exact same config and I can reach the repo only from 3 or 4 of them. Most of the time I get a timeout. Sometimes a the gateway error from above. And I have absolutely no good idea what is causing this issues but it persists for over 6 months now.

Hi @leah,

the domain packages6.icinga.com was our first approach to test IPv6 support for our repositories. Since our hoster officially does not provide IPv6 support we were happy to be allowed to test it with them.

Unfortunately, as you figured out already, this setup never left the testing environment for stability reasons.

Whenever we get fully working IPv6 we will provide it directly through packages.icinga.com. Right now it does not look promising however, since we’re the only ones requesting this at our hoster.

1 Like

I’m very sad to hear that your hoster isn’t capable of providing IPv6 in 2020. A technology that we all know for over 20 years now :wink:

As I’m working for a hoster too and we are doing the IPv6 thing for years now (actually we migrate to IPV6 only within our infrastructure, thats the reason for my request) can I provide any help that will fix this problem?

I’m not sure if you want to dig into that. As far as I know they’re using software defined networks with Midonet in combination with OpenStack. The v6 IP assigned to that machine is a floating IP. It seems like the software doesn’t carefully route the traffic on restarts/reloads. Since we’re not doing these things on our own, please don’t consider any of these details as correct :slight_smile:

From what I know there aren’t any other customers requesting this at our hoster, which makes it hard for them to justify the effort which would be required (without any guarantee that it will ever work with the stack they’re using right now).

I know that this is not satisfying. But I rather want to give you an honest answer than act the goat.

Ok…I understand your side :wink: Then I think I have to build a proxy repo for us with a dual stack connection. The same fun as for github :wink: