In the previous guide, we built a dedicated binhost to compile your stuff. Time to setup your servers to consume these packages.

In this follow-up guide, we will configure your servers. By pointing their Portage installations to your binhost, these machines will be able to install and update packages in minutes rather than a whole day.

Prerequisites & Assumptions

  • Shared Storage: We assume each server has access to a remote folder (via NFS, SMB, or a mounted cloud drive) at a specific mount point we will refer to as <path>. Another layer of complexity by setting in maintaining a side channel for distribution, like rsync thru ssh, is a hassle.
  • Folder Structure: On that path, the binhost has populated <path>/<host>/binpkgs with compiled packages from the last guide and <path>/gentoo with the Portage repository tree.
  • No Local Syncs: Because the repository is shared, these client machines are no longer supposed to run emerge --sync. They will always read the repository state managed by the binhost.
  • The Public Key: Ensure the binhost-public.asc file (generated in Part 1) has been copied to your client server’s current working directory.

All that needs to be done only once.

Step 1: Centralizing the Repository and Binary Cache

To ensure your client server always uses the exact same packages and repository as your binhost, we will remove the local copies of the Gentoo tree and the binary cache, replacing them with symbolic links to your shared storage.

First, clear out any existing local binary packages to save disk space:

rm -rf /var/cache/binpkgs

Next, remove the local Portage repository tree:

rm -rf /var/db/repos/gentoo

Now, link your binary cache directly to the binhost’s compiled packages. Replace <path> with your mount point and <host> with the hostname of your binhost machine:

ln -s <path>/<host>/binpkgs /var/cache/binpkgs

Link the Portage tree to the shared repository folder:

ln -s <path>/gentoo /var/db/repos/gentoo

Why do this? By using symlinks, your client machine will never be out of sync with the builder. Because the repository is now shared, this client machine no longer needs to run emerge --sync. The binhost handles the synchronization, and the client simply reads the shared data.

Step 2: Trusting the Binhost’s Signature

Portage will refuse to install binary packages unless it trusts the GPG key that signed them. We need to import the public key from our binhost and tell Portage that it is the ultimate authority for these packages.

Import the public key into Portage’s specific GPG home directory:

gpg --homedir=/etc/portage/gnupg --import "binhost-public.asc"

Open the GPG key editor to change the trust level for this key:

gpg --homedir=/etc/portage/gnupg --edit-key <keyid>

When the GPG prompt appears, type trust. You will be presented with a menu. Select 5 (Ultimate trust) and confirm. This tells Portage to automatically trust any packages signed by this key without pausing to ask for user confirmation. Type quit to exit.

Verify that the trust database has been updated correctly:

gpg --homedir=/etc/portage/gnupg --check-trustdb

Step 3: Updating the System via Binaries

Now comes the most satisfying part. We will update the system using the binary files.

Because we are relying on a shared repository rather than performing local syncs, you will not get that traditional message that you should update your portage. Just do it everytime, or create a script to check the version each time.

emerge --oneshot sys-apps/portage

Perform a full system update:

emerge --update --deep --newuse --ask @world

What is happening here? Portage will scan the @world set, calculate the dependency tree, and look for the required packages in /var/cache/binpkgs. Instead of downloading source code and compiling it on the client machine, it will instantly pull the pre-compiled files from your shared folder. For an underpowered machine, this transforms a 12-hour upgrade into a 15-minutes process!

Finally, clean up orphaned dependencies:

emerge --depclean

Conclusion

Your client server is now fully integrated into your binhost ecosystem! Going forward, system maintenance, package upgrades, and USE flag changes can be rolled out to your entire fleet of machines almost instantly.