We’ve moved our software distribution to packages.chef.io

Chef Infra (archive)
1

Ohai Chefs!

We’re excited to announce that we’ve moved all of Chef Software Inc’s public distribution services to packages.chef.io. Under the hood packages.chef.io leverages Bintray, the software distribution platform created by JFrog. We’ve made this transition to provide a more seamless, better performing experience to our users. Bintray takes advantage of Akamai’s extensive Content Delivery Network (CDN), this means faster downloads for our Chefs from all over the world! Additionally, Bintray will also allow us to support additional platform-native repository formats in the near future.

What this means

What’s next

  • We will continue to host a subset of our software packages in the existing PackageCloud APT/YUM repos until April 30, 2016.
  • In the coming weeks, we will update various Chef products to reference the new packages.chef.io based URLs.
  • We will also release a new version of Chef Server which will reference packages.chef.io for addon installation (e.g. chef-server-ctl install). After April, support for the chef-server-ctl install command using an existing version of Chef Server will be deprecated, and users will need to upgrade Chef Server to use this command.
2

All I see there is Invalid storage path: chef. I’m assuming there will be content eventually?

3

So packages.chef.io is CNAME pointing over to our Bintray account (chef.bintray.com). This CNAME is really only meant to be used with fully qualified repository paths. I’ll work on getting a redirect over to https://downloads.chef.io in place if a person visits https://packages.chef.io directly.

Head over to https://downloads.chef.io and you will see all download links are using the packages.chef.io based URLs. omnitruck.chef.io will also begin returning packages.chef.io based URLs in the near future.

4

A https://packages.chef.io => https://downloads.chef.io redirect has been deployed:

$ curl -I https://packages.chef.io
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Thu, 17 Mar 2016 13:51:22 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Location: https://downloads.chef.io

Hopefully that clears up any confusion.

5

I’m trying to download chef server, but getting an authentication prompt. I’m not sure what credentials I’d use.

6

The authorization prompt went away, I’m able to download now. Thanks.

7

I’m trying to proxy the new endpoint via apt-cacher-ng. I’m getting 403 responses from apt-cacher-ng . I modified the PfilePattern regex to include the generated akamai names but didn’t get any progress in that way of the rabbit hole.

Anyone else had this setup and got it working?

Allan

8

@aespinosa The following appears to be working as expected on Ubuntu 14.04:

# enable https support in apt
sudo apt-get install apt-transport-https -y

# Ensure Chef's public key is installed (we sign the repo metadata with it)
wget -qO - https://downloads.chef.io/packages-chef-io-public.key | sudo apt-key add -

# add a source for Chef's stable repo
echo "deb https://packages.chef.io/stable-apt trusty main" | sudo tee /etc/apt/sources.list.d/chef-stable.list    

# install apt-cacher-ng
sudo apt-get install apt-cacher-ng -y

# configure the proper pass-through pattern
echo "PassThroughPattern: (packages\.chef\.io):443$" | sudo tee --append /etc/apt-cacher-ng/acng.conf    

# configure the local machine to use apt-cacher-ng for all requests
echo 'Acquire::http { Proxy "http://localhost:3142"; };' | sudo tee /etc/apt/apt.conf.d/00proxy

# start apt-cacher-ng (be sure to restart it anytime a config change is made)
sudo /etc/init.d/apt-cacher-ng restart

# update the cache
sudo apt-get update

Note the sudo /etc/init.d/apt-cacher-ng restart.

9

Hi Seth,

Thanks for getting back to me.

I had to add ‘akamai.bintray.com’ to get the passthrough to work.

I think in your test, you’re still going directly to packages.chef.io

Acquire::http { Proxy "http://localhost:3142"; }; # should be Acquire::https { Proxy "http://localhost:3142"; }

Doing regular https proxying doesn’t actually cache the repository at least according to the official apt-cacher-ng docs [1] . I always had to use the following in my repository:

# sources.list entry
deb http://proxy.dev:3142/HTTPS///packages.chef.io/stable-apt jessie main

# output:
Err http://proxy.dev:3142/HTTPS///packages.chef.io/stable-apt/ jessie/main chef amd64 12.8.1-1
403  Forbidden
E: Failed to fetch http://proxy.dev:3142/HTTPS///packages.chef.io/stable-apt/debian/8/chef_12.8.1-1_amd64.deb  403  Forbidden

I do the same for the packagecloud repositories and it works as expected.

Regards,
Allan

[1] https://www.unix-ag.uni-kl.de/~bloch/acng/html/howtos.html#ssluse

10

Hello,

I got back from bintray support and was told about this issue of apt [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806959#5. They made an exception for the apt user agent but not yet for apt-cacher-ng. So what I had to do was make apt-cacher-ng’s user-agent to Apt’s like the following:

UserAgent: Debian APT-

I hope others find this useful.

Allan