-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi
Privately hosting a new mirror in Zurich city, Switzerland. FTTH, 1 Gbit/s. 4x SSDs RAID5.
PS.: The frontend is loadbalanced, so the backend ip is different.
- ----------------------------------------------------- HTTP: http://mirror.spreitzer.ch/centos/
Sync schedule: Every 6 hrs Bandwidth: 1 Gbit/s Location: Zurich, Zurich, Switzerland Sponsor: Sascha Spreitzer Sponsor URL: http://spreitzer.ch IP to authorize: 2a02:168:7a0e:6:5054:ff:fe77:b410 Email contact: sspreitz@redhat.com Mirroring AltArch: no - -----------------------------------------------------
Kind regards Sascha
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
PS.: The frontend is loadbalanced, so the backend ip is different.
To clarify:
Frontend IPs: 212.51.128.169, 2a02:168:7a0e::1
Backend IP (ip to authorize): 2a02:168:7a0e:6:5054:ff:fe77:b410
On 01/04/16 00:03, Sascha Spreitzer wrote:
PS.: The frontend is loadbalanced, so the backend ip is different.
To clarify:
Frontend IPs: 212.51.128.169, 2a02:168:7a0e::1
Backend IP (ip to authorize): 2a02:168:7a0e:6:5054:ff:fe77:b410 _______________________________________________ CentOS-mirror mailing list CentOS-mirror@centos.org https://lists.centos.org/mailman/listinfo/centos-mirror
Well, so does that mean that your backend mirror has no ipv4 connectivity at all ? (for outgoing connections that is), or is that the one from the frontend that is used for outgoing connections (and so that needs to be allowed) ? Problem is that actually nodes in our msync network only have ipv4 (something I'd like to change, but you'd be surprised how many DC don't provide ipv6)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Well, so does that mean that your backend mirror has no ipv4 connectivity at all ? (for outgoing connections that is), or is that the one from the frontend that is used for outgoing connections (and so that needs to be allowed) ?
Correct the backend has no IPv4 connectivity.
[root@mirror ~]# ip a sh eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:77:b4:10 brd ff:ff:ff:ff:ff:ff inet6 2a02:168:7a0e:6:5054:ff:fe77:b410/64 scope global noprefixroute dynamic valid_lft 86347sec preferred_lft 14347sec inet6 fe80::5054:ff:fe77:b410/64 scope link valid_lft forever preferred_lft forever
The fronted IPs are served via a DNS CNAME and might be changed due to infrastructure flexibility.
PS.: If you can provide a username/password rsync access, I can move the backend into a mixed IPv4/IPv6 network. (NAT private IPv4 RC1918 / IPv6) The IPv6 address would change then.
Do you have any other idea? Maybe it is not mandatory (until IPv6 is available) to have a direct connection to our msync network? May I host the first msync IPv6 for Europe?
Problem is that actually nodes in our msync network only have ipv4 (something I'd like to change, but you'd be surprised how many DC don't provide ipv6)
It should really be changed _asap_. IPv6 was codified 1st of December 1995 in RFC1883. This is over _20_ years ago.
On 03/04/16 09:01, Sascha Spreitzer wrote:
Well, so does that mean that your backend mirror has no ipv4 connectivity at all ? (for outgoing connections that is), or is that the one from the frontend that is used for outgoing connections (and so that needs to be allowed) ?
Correct the backend has no IPv4 connectivity.
[root@mirror ~]# ip a sh eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:77:b4:10 brd ff:ff:ff:ff:ff:ff inet6 2a02:168:7a0e:6:5054:ff:fe77:b410/64 scope global noprefixroute dynamic valid_lft 86347sec preferred_lft 14347sec inet6 fe80::5054:ff:fe77:b410/64 scope link valid_lft forever preferred_lft forever
The fronted IPs are served via a DNS CNAME and might be changed due to infrastructure flexibility.
PS.: If you can provide a username/password rsync access, I can move the backend into a mixed IPv4/IPv6 network. (NAT private IPv4 RC1918 / IPv6) The IPv6 address would change then.
Do you have any other idea? Maybe it is not mandatory (until IPv6 is available) to have a direct connection to our msync network? May I host the first msync IPv6 for Europe?
Well, what you can do is still pulling from another external mirror (which has proper ipv6 connectivity) for the time being, while waiting for more msync nodes to have ipv6 on our side ? If that works for you, I can add your mirror today. Let me know
Well, what you can do is still pulling from another external mirror (which has proper ipv6 connectivity) for the time being, while waiting for more msync nodes to have ipv6 on our side ? If that works for you, I can add your mirror today. Let me know
Works for me, please add it.
----------------------------------------------------- HTTP: http://mirror.spreitzer.ch/centos/
Sync schedule: Every 6 hrs Bandwidth: 1 Gbit/s Location: Zurich, Zurich, Switzerland Sponsor: Sascha Spreitzer Sponsor URL: http://spreitzer.ch IP to authorize: 2a02:168:7a0e:6:5054:ff:fe77:b410 Email contact: sspreitz@redhat.com Mirroring AltArch: no -----------------------------------------------------
On 07/04/16 10:07, Sascha Spreitzer wrote:
Well, what you can do is still pulling from another external mirror (which has proper ipv6 connectivity) for the time being, while waiting for more msync nodes to have ipv6 on our side ? If that works for you, I can add your mirror today. Let me know
Works for me, please add it.
Ok, cool, so I just added it. It will be added on the website and will be probed by mirmon/crawler process and so will appear in yum mirrorlists for both ipv4/ipv6 later in the day. Hopefully I'll be back with something that will work on ipv6 "end-to-end" but only when I'll have support from DC involved in the msync network hosting.
Cheers,
-
Fabian Arrotin -
Sascha Spreitzer