Editorial review of Tracking for Multiple Machines.

Sponsored by:	iXsystems
This commit is contained in:
Dru Lavigne 2014-05-01 17:21:49 +00:00
parent 8482759824
commit 9682d6c602
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44732

View file

@ -2408,24 +2408,25 @@ Building everything..
</indexterm> </indexterm>
<para>When multiple machines need to track the same source tree, <para>When multiple machines need to track the same source tree,
it is a waste of disk space, network bandwidth, and CPU cycles it is a waste of disk space, network bandwidth, and <acronym>CPU</acronym> cycles
to have each system download the sources and rebuild everything. to have each system download the sources and rebuild everything.
The solution is to have one machine do most of the work, while 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 the rest of the machines mount that work via <acronym>NFS</acronym>. This section
outlines a method of doing so.</para> outlines a method of doing so. For more information about using
<acronym>NFS</acronym>, refer to <xref
<sect2 xml:id="small-lan-preliminaries"> linkend="network-nfs"/>.</para>
<title>Preliminaries</title>
<para>First, identify a set of machines which will run the same <para>First, identify a set of machines which will run the same
set of binaries, known as a <emphasis>build set</emphasis>. set of binaries, known as a <firstterm>build set</firstterm>.
Each machine can have a custom kernel, but will run the same Each machine can have a custom kernel, but will run the same
userland binaries. From that set, choose a machine to be the userland binaries. From that set, choose a machine to be the
<emphasis>build machine</emphasis> that the world and kernel <firstterm>build machine</firstterm> that the world and kernel
are built on. Ideally, this is a fast machine that has are built on. Ideally, this is a fast machine that has
sufficient spare CPU to run <command>make buildworld</command> sufficient spare <acronym>CPU</acronym> to run <command>make buildworld</command>
and <command>make buildkernel</command>. Select a machine to and <command>make buildkernel</command>.</para>
be the <emphasis>test machine</emphasis>, which will test
<para>Select a machine to
be the <firstterm>test machine</firstterm>, which will test
software updates before they are put into production. This software updates before they are put into production. This
<emphasis>must</emphasis> be a machine that can afford to be <emphasis>must</emphasis> be a machine that can afford to be
down for an extended period of time. It can be the build down for an extended period of time. It can be the build
@ -2433,14 +2434,12 @@ Building everything..
<para>All the machines in this build set need to mount <para>All the machines in this build set need to mount
<filename>/usr/obj</filename> and <filename>/usr/obj</filename> and
<filename>/usr/src</filename> from the same machine, and at <filename>/usr/src</filename> from the build machine via
the same point. Ideally, those directories are on two <acronym>NFS</acronym>. For multiple build sets,
different drives on the build machine, but they can be NFS
mounted on that machine as well. For multiple build sets,
<filename>/usr/src</filename> should be on one build machine, <filename>/usr/src</filename> should be on one build machine,
and NFS mounted on the rest.</para> and <acronym>NFS</acronym> mounted on the rest.</para>
<para>Finally, ensure that <filename>/etc/make.conf</filename> <para>Ensure that <filename>/etc/make.conf</filename>
and <filename>/etc/src.conf</filename> on all the machines in and <filename>/etc/src.conf</filename> on all the machines in
the build set agree with the build machine. That means that the build set agree with the build machine. That means that
the build machine must build all the parts of the base system the build machine must build all the parts of the base system
@ -2448,51 +2447,40 @@ Building everything..
each build machine should have its kernel name set with each build machine should have its kernel name set with
<varname>KERNCONF</varname> in <varname>KERNCONF</varname> in
<filename>/etc/make.conf</filename>, and the build machine <filename>/etc/make.conf</filename>, and the build machine
should list them all in <varname>KERNCONF</varname>, listing should list them all in its <varname>KERNCONF</varname>, listing
its own kernel first. The build machine must have the kernel its own kernel first. The build machine must have the kernel
configuration files for each machine in <filename configuration files for each machine in its <filename
class="directory">/usr/src/sys/<replaceable>arch</replaceable>/conf</filename> class="directory">/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>.</para>
if it is going to build their kernels.</para>
</sect2>
<sect2 xml:id="small-lan-base-system">
<title>The Base System</title>
<para>On the build machine, build the kernel and world as <para>On the build machine, build the kernel and world as
described in <xref linkend="make-buildworld"/>, but do not described in <xref linkend="makeworld"/>, but do not
install anything. After the build has finished, go to the install anything on the build machine. Instead, install the built kernel
test machine, and install the built kernel. If this machine on the test machine. On the test machine, mount
mounts <filename>/usr/src</filename> and <filename>/usr/src</filename> and
<filename>/usr/obj</filename> via NFS, enable the network and <filename>/usr/obj</filename> via <acronym>NFS</acronym>. Then, run
mount these directories after rebooting to single user mode. <command>shutdown now</command> to go to single-user mode in order to
The easiest way to do this is to boot to multi-user, then run install the new kernel and world and run
<command>shutdown now</command> to go to single user mode.
Once there, install the new kernel and world and run
<command>mergemaster</command> as usual. When done, reboot to <command>mergemaster</command> as usual. When done, reboot to
return to normal multi-user operations for this return to normal multi-user operations.</para>
machine.</para>
<para>After verifying that everything on the test machine is <para>After verifying that everything on the test machine is
working properly, use the same procedure to install the new working properly, use the same procedure to install the new
software on each of the other machines in the build software on each of the other machines in the build
set.</para> set.</para>
</sect2>
<sect2 xml:id="small-lan-ports"> <para>The same methodology can be used for the ports tree. The first
<title>Ports</title> step is to share <filename>/usr/ports</filename> via
<acronym>NFS</acronym> to all the machines in the build set. To
<para>The same ideas can be used for the ports tree. The first configure <filename>/etc/make.conf</filename> to
critical step is to mount <filename>/usr/ports</filename> from share distfiles, set <varname>DISTDIR</varname> to a common
the same machine to all the machines in the build set. Then,
configure <filename>/etc/make.conf</filename> properly to
share distfiles. Set <varname>DISTDIR</varname> to a common
shared directory that is writable by whichever user shared directory that is writable by whichever user
<systemitem class="username">root</systemitem> is mapped to by <systemitem class="username">root</systemitem> is mapped to by
the NFS mounts. Each machine should set the <acronym>NFS</acronym> mount. Each machine should set
<varname>WRKDIRPREFIX</varname> to a local build directory. <varname>WRKDIRPREFIX</varname> to a local build directory, if
Finally, if the system is to build and distribute packages, ports are to be built locally.
set <varname>PACKAGES</varname> to a directory similar to Alternately, if the build system is to build and distribute
packages to the machines in the build set,
set <varname>PACKAGES</varname> on the build system to a directory similar to
<varname>DISTDIR</varname>.</para> <varname>DISTDIR</varname>.</para>
</sect2>
</sect1> </sect1>
</chapter> </chapter>