Self-Hosting

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. ...

Maintaining a fleet of Gentoo systems, or struggling to compile packages on an underpowered server, can be an incredibly tedious process. Waiting hours for a single package to compile can quickly add up, and eventually you may try to burn down your home lab. Unless you rich, your home servers are likely stuff of 10 years ago made of mismatch stuff lying around. A partial solution is simple do not touching the portage flags at all and use the Gentoo provided binhost. But this presents two issues: not everything available on portage exist as binary package at their binhost mirrors, and the second is that you give away customization of the packages that you do use. ...