Image server infrastructure

News
22

I was implicitly referring to the hash validation that seems to be absent of lxc-download.

23

That’s because it always downloads over https, the hash validation is useful only if you’re going to fetch the data over http.

For firewalling, you can add every one of the servers listed above to your firewall rules.
You can alternatively force the us of https://ca.images.linuxcontainers.org which is a server that will not redirect.

24

The https brings transport protection, not hosting one. The hash permit to say :

We don’t have to strictly trust our mirrors operators

Anyway, the force scenario proposed is a way to get around it for lxc-download.

1 Like
25

Could offer a mirror (on OVH infra) in EU (France), but won’t be 1 Gpbs symmetrical, 250Mbs up. Would that help?

26

That’s unlikely as we already have a sponsored one not far away in Frankfurt which has 2Gbps symmetric. It’s one of our busiest mirrors but it’s nowhere close to reaching its bandwidth limit.

Given Europe’s routing, I’d expect French customers to have excellent routes to Digital Ocean in Frankfurt, so adding another mirror in France itself wouldn’t really make a visible difference.

That’s unless someone in France has seen performance issues downloading from the current European mirror in Germany, if that’s the case for customers of one or more ISPs in France, then introducing a country-specific mirror may be useful.

1 Like
27

Thanks for providing https://ca.images.linuxcontainers.org. Bandwith is even OK here from Germany. One idea:
Since many companies can whitelist url patterns, I suggest to register mirrors in domain linuxcontainers.org instead of do.letsbuildthe.cloud. The later one could not be seen as linuxcontainers.org specific and therefore whitelisting *.do.letsbuildthe.cloud may not be an option.

28

I think we were looking at doing something like that with @mpontillo a little while back.

Basically delegating something like digitalocean.images.linuxcontainers.org over to the DO team and then they could run things on fra.digitalocean.images.linuxcontainers.org or similar.

Not something we’d necessarily want to do with anyone offering to run a public mirror for us, but something that may make sense in the case of DO as they’re running a bunch of them.

We could also just deal with static records on our end, but then that removes flexibility on the mirror operator to rotate instances, put in load-balancing or the like.

29

That’s exactly what I meant.

With ca.images.linuxcontainers.org we have a work around. However, if the mirrors were accessible under the linuxcontainers.org domain, they could also reduce the load on your server.