There are various guides about how to get Chef on a Raspberry Pi, but none I could find about how to build a proper Chef client package. People used to Omnibus packages (Chef, ChefDK) expect a certain consistency when deploying stuff.
I’m using the pi user for the following script under Raspbian Buster:
sudo apt-get install build-essential git ruby bundler git clone https://github.com/chef/chef cd chef # checkout the desired Chef release tag, for example git checkout v15.7.32 cd omnibus bundle install --without development --path vendor/bundle sudo mkdir -p /var/cache/omnibus /opt/chef sudo chown pi:pi /var/cache/omnibus /opt/chef # if building under the pi user # git is being bit of a git - use proper values on an actual box, unless it's just # a build box git config --global user.email "you@example.com" git config --global user.name "Your Name" bundle exec omnibus build chef # wait for an extreme amount of time... # check the build results ls -l pkg total 32320 -rw-r--r-- 1 root root 33033164 Feb 7 22:07 chef_15.7.32+20200207193316-1_armhf.deb -rw-r--r-- 1 root root 52348 Feb 7 22:07 chef_15.7.32+20200207193316-1_armhf.deb.metadata.json -rw-r--r-- 1 root root 6894 Feb 7 22:07 version-manifest.json dpkg -I pkg/chef_15.7.32+20200207193316-1_armhf.deb new Debian package, version 2.0. size 33033164 bytes: control archive=327544 bytes. 298 bytes, 11 lines control 1552093 bytes, 12722 lines md5sums 3190 bytes, 111 lines * postinst #!/bin/sh 1226 bytes, 50 lines * postrm #!/bin/sh 837 bytes, 23 lines * preinst #!/bin/sh Package: chef Version: 15.7.32+20200207193316-1 License: Chef EULA Vendor: Omnibus <omnibus@getchef.com> Architecture: armhf Maintainer: Chef Software, Inc. <maintainers@chef.io> Installed-Size: 121364 Section: misc Priority: extra Homepage: https://www.chef.io Description: The full stack of chef
In fact, other than the pi user, none of the above steps are Raspbian specific. They work on pretty much all Debian-based distributions. With the exception of the apt-get line, all the steps are in fact distribution agnostic, but I had to learn them the hard way.
After a huge amount of wait, behold a chef deb ready to be installed. That amount may be significantly shorter on a Raspberry Pi 3 or 4B as Omnibus makes use of all CPU cores.
Emulating a Raspberry Pi
While this may not be necessary, I don’t always have a Raspberry Pi I can kill (read stress, I never had one fail) with package builds. It was quite the challenge to find the winning combination. While the build benefits from better storage and more RAM, the CPU speed isn’t impressive. However, speed isn’t the purpose. While it’s possible to use this under native qemu, regardless of host OS, I went the VM route to have more predictable results. The macOS qemu is painful to work with anyway.
Vagrant to the rescue:
Vagrant.configure('2') do |config|
config.vm.box = 'bento/ubuntu-16.04'
config.vm.box_check_update = true
config.vm.provider 'virtualbox' do |vb|
vb.name = 'ubuntu-pi'
vb.cpus = 4
vb.memory = 2048
vb.customize ['modifyvm', :id, '--nictype1', 'virtio']
end
end
This is a fairly standard Vagrantfile. The vb.customize bit makes sure the network interface uses virtio. I’ve had issues in the past with wobbly performance using the default NIC type.
The actual setup for chroot-ing into a qemu-user-static container is excellently described on the Debian Wiki. The only change was Raspbian Buster which is the current release. I have increased the Raspbian root volume by 4096 MiB.
I have used systemd-nspawn, then after chroot-ing, killed the entry in /etc/ld.so.preload as it spams the shell with messages about failing to load a rather useless library in this setup.
Then, simply use the Raspbian script that I have used on actual Raspberry Pi’s.