curl https://www.opscode.com/chef/install.sh | sudo bash
That's it. This can be put in any instructions, such as a README or someone's blog, since the logic is in the shell script. Provided you download the script using https, the file has standard levels of authentication and encryption protecting it from manipulation.
This is obviously a shell script, if you're really concerned about the argument that it may contain nefarious activities within, you can easily review it before you run it.
wget https://www.opscode.com/chef/install.sh
less install.sh
sudo bash install.sh
Without a shell script, you must have a website that selects the correct installation procedure based on platform, platform version, and architecture, because you cannot provide a single binary package that is correct for all of them. Source installs require extensive configuration of a development environment and multiple dependencies.
See the old Chef 10 installation directions for specific examples of the complexity of supporting multiple platforms and versions this way.
Source install:
# multiple steps to install development dependencies, which all vary by platform
sudo apt-get install build-essential ruby ruby-dev rake
# download the source
wget https://www.somewhere.com/chef/source.tgz
tar -xvzf source.tgz
cd source
rake gem
sudo gem install pkg/chef-*.gem
Binary install for a single platform:
wget https://www.somewhere.com/chef/install-ubuntu-12.04-x86.deb -O /tmp/install.deb
sudo dpkg -i /tmp/install.deb
# or
sudo yum install wget
wget https://www.somewhere.com/chef/install-centos-6-x86.rpm -O /tmp/install.rpm
sudo rpm -Uvh /tmp/install.rpm
But does being in a regular package make you trust it more than a shell script? Most distribution packages contain shell scripts that are run on installation, and they're harder to review than a simple shell script. The required commands differ depending on platform. For example:
dpkg -e /tmp/install.deb /tmp/install.conffiles
less /tmp/install.conffiles/postinst
What about dependencies? Does your platform have all the required dependencies? Are they new enough (no, unless you're on the most recent version). So now you also need to add a repository for all of these platforms to get updated dependencies. All of these are going to need to be backported and maintained for multiple versions by someone.
Because that developer wrote some good software that I want to use?
It is completely understandable if a single developer in a small project doesn't want to create and maintain packages for
deb
,rpm
, and dozen other package managers various linux systems use. Do you seriously expect everyone to build packages for your MacOS or Arch?Curl+bash are there in every system. Easy to support, easy to run. If it doesn't work, revert to the last backup (btrfs snapshot and the like) that you should've made beforehand (teachable moment about the value of full-system backups right here).
And if you have any security concerns whatsoever, don't give root access. No matter what it is, dpkg or bash script. Don't run it as system root, run it in a container instead (lxc, docker). Bonus point: if it breaks something, you just lose a container with nothing else in it.
curl | bash
should be treated as a warning that a project is very small and doesn't have enough community support (since noone else created 3rd party package yet). Nothing more, nothing less.