Add a new section on shared builds
Approved by: murray Submitted by: Mike Meyer <mwm@mired.org> PR: docs/36042
This commit is contained in:
Ceri Davies
parent
6d65135f72
commit
6bd8626bfe
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=12551
1 changed files with 103 additions and 1 deletions
|
|
@ -1633,8 +1633,110 @@ Building everything..
|
|||
</qandaset>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="small-lan">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Mike</firstname>
|
||||
<surname>Meyer</surname>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect1info>
|
||||
<title>Tracking for multiple machines</title>
|
||||
|
||||
<para>If you have multiple machines that you want to track the
|
||||
same source tree, then having all of them download sources and
|
||||
rebuild everything seems like a waste of resources: disk space,
|
||||
network bandwidth, and CPU cycles. It is, and the solution is
|
||||
to have one machine do most of the work, while the rest of the
|
||||
machines mount that work via NFS. This section outlines a
|
||||
method of doing so.</para>
|
||||
|
||||
<sect2 id="small-lan-preliminaries">
|
||||
<title>Preliminaries</title>
|
||||
|
||||
<para>First, identify a set of machines that is going to run
|
||||
the same set of binaries, which we will call a
|
||||
<emphasis>build set</emphasis>. Each machine can have a
|
||||
custom kernel, but they will be running the same userland
|
||||
binaries. From that set, choose a machine to be the
|
||||
<emphasis>build machine</emphasis>. It is going to be the
|
||||
machine that the world and kernel are built on. Ideally, it
|
||||
should be a fast machine that has sufficient spare CPU to
|
||||
run <command>make world</command>. You will also want to
|
||||
choose a machine to be the <emphasis>test
|
||||
machine</emphasis>, which will test software updates before they
|
||||
are put into production. This <emphasis>must</emphasis> be a
|
||||
machine that you can afford to have down for an extended
|
||||
period of time. It can be the build machine, but need not be.</para>
|
||||
|
||||
<para>All the machines in this build set need to mount
|
||||
<filename>/usr/obj</filename> and
|
||||
<filename>/usr/src</filename> from the same machine, and at
|
||||
the same point. Ideally, those are on two different drives
|
||||
on the build machine, but they can be NFS mounted on that machine
|
||||
as well. If you have multiple build sets,
|
||||
<filename>/usr/src</filename> should be on one build machine, and
|
||||
NFS mounted on the rest.</para>
|
||||
|
||||
<para>Finally make sure that
|
||||
<filename>/etc/make.conf</filename> on all the machines in
|
||||
the build set agrees with the build machine. That means that
|
||||
the build machine must build all the parts of the base
|
||||
system that any machine in the build set is going to
|
||||
install. Also, each build machine should have its kernel
|
||||
name set with <makevar>KERNCONF</makevar> in
|
||||
<filename>/etc/make.conf</filename>, and the build machine
|
||||
should list them all in <makevar>KERNCONF</makevar>, listing
|
||||
its own kernel first. The build machine must have the kernel
|
||||
configuration files for each machine in
|
||||
<filename>/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>
|
||||
if it is going to build their kernels.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>The base system</title>
|
||||
|
||||
<para>Now that all that is done, you are ready to build
|
||||
everything. Build the kernel and world as described in <xref
|
||||
linkend="make-buildworld"> on the build machine,
|
||||
but do not install anything. After the build has finished, go
|
||||
to the test machine, and install the kernel you just
|
||||
built. If this machine mounts <filename>/usr/src</filename>
|
||||
and <filename>/usr/obj</filename> via NFS, when you reboot
|
||||
to single user you will need to enable the network and mount
|
||||
them. The easiest way to do this is to boot to multi-user,
|
||||
then run <command>shutdown now</command> to go to single user
|
||||
mode. Once there, you can install the new kernel and world and run
|
||||
<command>mergemaster</command> just as you normally would. When
|
||||
done, reboot to return to normal multi-user operations for this
|
||||
machine.</para>
|
||||
|
||||
<para>After you are certain that everything on the test
|
||||
machine is working properly, use the same procedure to
|
||||
install the new software on each of the other machines in
|
||||
the build set.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Ports</title>
|
||||
|
||||
<para>The same ideas can be used for the ports tree. The first
|
||||
critical step is mounting <filename>/usr/ports</filename> from
|
||||
the same machine to all the machines in the build set. You can
|
||||
then set up <filename>/etc/make.conf</filename> properly to share
|
||||
distfiles. You should set <makevar>DISTDIR</makevar> to a
|
||||
common shared directory that is writable by whichever user
|
||||
root is mapped to by your NFS mounts. Each
|
||||
machine should set <makevar>WRKDIRPREFIX</makevar> to a
|
||||
local build directory. Finally, if you are going to be
|
||||
building and distributing packages, you should set
|
||||
<makevar>PACKAGES</makevar> to a directory similar to
|
||||
<makevar>DISTDIR</makevar>.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
|
|
|
|||
Loading…
Reference in a new issue