User:Goverp/ClientServerGentoo

Gentoo is a meta-distribution - you configure your own distribution through a combination of, USE flag settings, settings such as CHOST and packages. Many Gentoo users run the result on just one computer, but it can be easy to use it on several computers using binary packages. This can be done in several ways; this document describes one of them. It may or may not be the most appropriate for any particular situation.

Concepts and Facilities
This document describes one way to use a binary package host. The Binary package guide contains reference details of the Gentoo facilities being used.

One computer, the to do the majority the "heavy lifting" of compiling the packages, and in most cases the others  just install the compiled code. {c|portage}} will compile and install different versions of the code if the master version is unsuitable for a particular slave.

Slaves use to access the binary packages on the master. Other access methods such as are possible: refer to the binary package guide for details.

Matching processor architectures
The approach works when the master and slaves are reasonably similar; for example, the master could be an old but powerful desktop computer with a 4-way AMD Phenom processor, lots of memory and a large RAID disk array, while a slave might be a laptop with a later but smaller AMD a9-9420 processor. It turns out that in most cases code for the Phenom runs well on the a9-9420, and magically, Gentoo can identify the cases where it doesn't and this approach will lead to the slave compiling its own custom code.

It does not work when the architectures are dissimilar, for example an Intel master and an ARM slave such as a Raspberry Pi. Intel code simply does not run on ARM chips.

It might not work if the master has a later version of the similar architecture; for example, an a9-9420 master and a Phenom slave, unless you compromise by restricting code to the older architecture. This combination is untried; it might work just as well as the other way round, or not. For more details, see for a discussion.

Matching implementation profiles and USE flags
Gentoo's greatest feature is its customization.. The approach allows for differing and  settings for master and slaves; Gentoo will allow a slave to use master code for packages with the same settings while compiling different code where the settings differ.

Since Gentoo profiles are largely a set of default USE flags, if the master has a different profile to the slave there may be many different USE settings between the two machines. This may mean the majority of packages have to be recompiled for the slave, negating the benefits of the master/slave approach.

Sharing the portage tree
The master and slave machines may share the same portage tree over. This saves the slave from carrying the portage tree, and saves having to process. However, it's impossible to run any commands on the slave when not connected to the master, which may be a significant limitation. (This configuration works well when both DISTDIR and PKGDIR have their default values, so the portage tree contains everything needed to build code.)

Alternatively, they may share just (or whatever PKGDIR is set to) via NFS, and the each have their own portage tree. In this case, the slave may use against the master's. This approach is a little more cumbersome, but allows the slave to process portage commands whether or not connected to the master.

The following works using the first arrangement under NFSv4, with being a bind mount for :

(See NFSv4 for more information. NFSv3 needs a slightly different configuration (see NFS).

Sharing the configuration
contains the configuration. The central feature of the master/slave approach, the differing configurations, prohibits simply sharing this through NFS. Instead, we use, and exploit portage's ability to handle configuration directories instead of file for  and so on.

Since portage processes files in configuration directories in collating sequence order, if the master has files beginning 01... and the slaves have files beginning 02..., portage will use the master files as a basis, and override them with the entries in the slave files. Therefore we need to synchronise the master 01 files using rsync configured on the master with:

The following shell script will copy all 01-prefixed files of interest; the contents of get sync'ed in toto, as they're not themselves configuration, the relevant part of that is in. (Substitute master with your master system's network name or address.)

Master configuration
As described, put all the generic configuration information in files with names prefixed by 01. Here's a couple of examples:

Slave configuration
As described, the differences between the slave and master configurations are held in files with 02- prefixed names. For example:

Operation
Run as normal on the master.

Before running it on the slave, start on the master, and run  on the slave. Then start on the master. then on the slave, run:

Note the purple output, which is portage's way of saying "Here's one I prepared earlier". Notice also the green output where portage calculated that the master package's code is unsuitable for this slave.

Compiler --march settings
The configurations above use --march=native on both master and slave. This works for me. Gcc of course is at liberty to generate code that exploits hardware features on the master that might not exist on the slave. As it works for me, it appears that it only generates feature-sensitive code if the appropriate value is present in CPU_FLAGS|X86, so portage detects packages sensitive to these flags and compiles the package separately for the slave. Truly magic. I expected this to end in tears.

If your experience differs, the solution is to choose an explicit, less-specific, value of --march such as k8.

The code generated, in either case, will get --mtune defaulting to the same architecture, unless overridden. This might impose a small performance impact on the slave.