Hi,
Just to let you know in advance that we'll add some modifications to the buildlogs.centos.org nodes. We got a proposal from a CDN infrastructure company (CDN77.com) willing to be a sponsor for the CentOS Project, and so we'd like to use that service for the testing/dev artifacts (so rpm packages, iso images, qcow2 images, etc) so that users can get it faster than when served from our actual buildlogs.centos.org nodes.
What does that mean for you ? Next tuesday, we'll implement RewriteRule to redirect requests to those CDN backend nodes (themselves fetching/caching directly from us) The change is scheduled to be implemented on Tuesday March 29th, 8:00 am UTC time You can convert to local time with $(date -d '2016-3-29 8:00 UTC')
What will be the impact ? Starting from that day, httpd will redirect you to another location for the following type of files : .rpm, .iso .qcow2{.gz,.xz}, .img{.xz} We tested that yum follows correctly the redirection, so people consuming packages from those repositories (so testing repo for the SIGs building pkgs through cbs.centos.org) will not see any impacts, except maybe an increase in available bandwidth/speed delivery (so the goal we wanted to reach)
What about people downloading such images ? - browser (Firefox, Chome, others) : works directly - wget : it follows the redirection by default, so no impact - curl : if you use curl without the --location option, it will *not* follow the redirection so you'll not be able to download the needed file as before. Verify so your download scripts using curl to implement the correct options. - other method : not tested
What about the integrity of the downloaded files ? - for rpm packages, you'll still get the repodata files from our nodes, meaning that only the packages will be downloaded from the cdn, and so metadata for the .rpm packages will have to match what's declared at the repodata level, ensuring integrity checks. - for the other images (.iso, .qcow2, etc) you'll be able to fetch/compare the .sha256 file for each file (or the sha256sum.txt file) from us, giving you the ability to verify also the integrity of the downloaded files.
If you encounter an issue, feel free to reach us in #centos-devel.
On Fri, Mar 25, 2016, at 12:39 PM, Fabian Arrotin wrote:
Hi,
Just to let you know in advance that we'll add some modifications to the buildlogs.centos.org nodes. We got a proposal from a CDN infrastructure company (CDN77.com) willing to be a sponsor for the CentOS Project, and so we'd like to use that service for the testing/dev artifacts (so rpm packages, iso images, qcow2 images, etc) so that users can get it faster than when served from our actual buildlogs.centos.org nodes.
This sounds great!
- for rpm packages, you'll still get the repodata files from our nodes,
Yes, but these aren't accessible over TLS, nor GPG signed =( Given Let's Encrypt is now a thing, is there any blocker for using TLS?
One thing that would be also nice (and partly orthogonal) is to offer "tls-pinned" access, where a custom root CA cert is used, and client systems can be configured to pin to this CA. Something like https://buildlogs-pin.centos.org
Still though, the CDN sounds nice.
On 26/03/16 15:23, Colin Walters wrote:
Yes, but these aren't accessible over TLS, nor GPG signed =( Given Let's Encrypt is now a thing, is there any blocker for using TLS?
Fabian is going to investigate this, since buildlogs is just a few machines we control it might be possible to roll out some sort of TLS support here.
One thing that would be also nice (and partly orthogonal) is to offer "tls-pinned" access, where a custom root CA cert is used, and client systems can be configured to pin to this CA. Something like https://buildlogs-pin.centos.org
Still though, the CDN sounds nice.
yeah, we are looking forward to testing this - it would give us a lot more PoP's for the buildlogs content, ie. definitely improve the developer experience around the CentOS Project resources.
regards
-
Colin Walters -
Fabian Arrotin -
Karanbir Singh