I’m just wondering how Chef Software (or whatever the company name is in this current moment) can manage to make chef more and more unfriendly to automation when it comes to packaging?
Way back when chef-client was at version 10, there was a public apt repository at http://apt.opscode.com/ that you could install chef from or mirror from. Easy, a official apt repository correctly setup, publicly available gpg key for the repo.
Then chef was moved to packagecloud.io, and they broke the automatic mirroring, cause packagecloud.io doesn’t support http headers correctly.
So basically you had to update the mirror by deleting the mirror cache for apt-mirror, which in a sense could be automated.
I see that the package repository for chef-client for ubuntu have changed place to https://packages.chef.io/stable/
No repository stuff, just a flat file structure, no gpg keys for the packages, nothing.
I don’t get it, does Chef software not want us to install chef? Or does they want us to package it ourselves? Perhaps the want the community to start using some other tool that is easier to install?
Sadly I’m to invested in chef to switch to another configuration management tool with ease…
Look at the install instructions for ansible for ubuntu: sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible sudo apt-get update
sudo apt-get install ansible
They have a repository with gpg keys and everything becomes simple, using deb packages in a apt repository as it was intended.
To Chef Software, sharpen up, a software company of your size should have any problem building repositories for different OS’es.
It’s not secure to pipe bash scripts from internet, especially as root.
Are you one of those that clicks on the banner ads “You got a Virus! Click here to remove!”?
Joke aside, how is using a script more proper than the assigned package manager for the current distro?
At least with packages you have chance to verify the signatures of the packages.
And why would you need a script, when a package can do all that it needs to install?
Hell why not just skip packages completely. Let’s just have a tarball with binary files that we can use curl and pipe to tar. (Hope you understand sarcasm).
With a proper repository you can install chef as all the other packages you install for your distro, you can easily mirror it with pre-made tools, no need to reinvent the wheel. You can verify signatures.
You can use the one resource “apt_repository” from the apt cookbook to install chef-client if you want to do it from a coobook, or similar for RHEL using the yum cookbook.
And you upgrade chef in the same way you upgrade everything else in your distro… apt-get update && apt-get dist-upgrade… No need to have a cookbook in order to do it.
And maybe you don’t want all your machines to have Internet access…
Nothing prevents you from getting the script and use it internally, as for the packages and serve them internally. (which solves your last point too)
Interesting approach, installing chef repo with chef in order to install chef
I do hope you're managing your packages version better than just getting latest versions, specially for the chef-client, hence the point of using a cookbook to pinpoint the version.
It is just easier to have the same command on any machine provisonning IMO, the script just guess the machine type to get the proper package, if you want to get rid of it just see the page I linked from the documentation to get the proper package with a single curl call.
Maybe there should be a mention of the repositories in the download page https://downloads.chef.io/chef-client/ to alleviate the increase in gray hair around the globe.
Yes, sorry I didn’t resist to get on the same path as your first post with a rant like tone more than a question
This time I absolutely agree with you, adding a link on the getchef page would be far better and would avoid frustration. I’m unsure of the path to open an issue about it, I’ll have a look after lunch
As even knowing those way exists, I had a hard time finding the proper links, and both of them being on two different pages is of not help, and they're not linked too in the bootstrap documentation (which is mainly knife bootstrap centric)
Maybe a documentation page acting as a summary on 'Differents way to install the client on your nodes' giving links to all ways to get the client (Omnitruck API in direct, linux repos, windows method, knife bootstrap, manual install) would be a great page to have in the doc and the perfect target for the get chef page.
Other idea (maybe easiest) link the repo and its key just under the license information link when you have selected the platform and version (when this makes sense, repo exist, etc.)
I'm perhaps a little messy in giving my thoughts, but I hope this is constructive enough .
When I discovered that the packagecloud.io repo was gone. My first instinct was to go to chef.io and click on the Download links to get information on where and how I can download chef.
Unfortunately, my instinct wasn’t to scour docs.chef.io for a repository link.
.