Editorial review of Tracking for Multiple Machines.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
8482759824
commit
9682d6c602
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44732
1 changed files with 38 additions and 50 deletions
|
|
@ -2408,24 +2408,25 @@ Building everything..
|
|||
</indexterm>
|
||||
|
||||
<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.
|
||||
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 xml:id="small-lan-preliminaries">
|
||||
<title>Preliminaries</title>
|
||||
the rest of the machines mount that work via <acronym>NFS</acronym>. This section
|
||||
outlines a method of doing so. For more information about using
|
||||
<acronym>NFS</acronym>, refer to <xref
|
||||
linkend="network-nfs"/>.</para>
|
||||
|
||||
<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
|
||||
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
|
||||
sufficient spare CPU to run <command>make buildworld</command>
|
||||
and <command>make buildkernel</command>. Select a machine to
|
||||
be the <emphasis>test machine</emphasis>, which will test
|
||||
sufficient spare <acronym>CPU</acronym> to run <command>make buildworld</command>
|
||||
and <command>make buildkernel</command>.</para>
|
||||
|
||||
<para>Select a machine to
|
||||
be the <firstterm>test machine</firstterm>, which will test
|
||||
software updates before they are put into production. This
|
||||
<emphasis>must</emphasis> be a machine that can afford to be
|
||||
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
|
||||
<filename>/usr/obj</filename> and
|
||||
<filename>/usr/src</filename> from the same machine, and at
|
||||
the same point. Ideally, those directories are on two
|
||||
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> from the build machine via
|
||||
<acronym>NFS</acronym>. For multiple build sets,
|
||||
<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
|
||||
the build set agree with the build machine. That means that
|
||||
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
|
||||
<varname>KERNCONF</varname> in
|
||||
<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
|
||||
configuration files for each machine in <filename
|
||||
class="directory">/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>
|
||||
if it is going to build their kernels.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="small-lan-base-system">
|
||||
<title>The Base System</title>
|
||||
configuration files for each machine in its <filename
|
||||
class="directory">/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>.</para>
|
||||
|
||||
<para>On the build machine, build the kernel and world as
|
||||
described in <xref linkend="make-buildworld"/>, but do not
|
||||
install anything. After the build has finished, go to the
|
||||
test machine, and install the built kernel. If this machine
|
||||
mounts <filename>/usr/src</filename> and
|
||||
<filename>/usr/obj</filename> via NFS, enable the network and
|
||||
mount these directories after rebooting to single user mode.
|
||||
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, install the new kernel and world and run
|
||||
described in <xref linkend="makeworld"/>, but do not
|
||||
install anything on the build machine. Instead, install the built kernel
|
||||
on the test machine. On the test machine, mount
|
||||
<filename>/usr/src</filename> and
|
||||
<filename>/usr/obj</filename> via <acronym>NFS</acronym>. Then, run
|
||||
<command>shutdown now</command> to go to single-user mode in order to
|
||||
install the new kernel and world and run
|
||||
<command>mergemaster</command> as usual. When done, reboot to
|
||||
return to normal multi-user operations for this
|
||||
machine.</para>
|
||||
return to normal multi-user operations.</para>
|
||||
|
||||
<para>After verifying 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 xml:id="small-lan-ports">
|
||||
<title>Ports</title>
|
||||
|
||||
<para>The same ideas can be used for the ports tree. The first
|
||||
critical step is to mount <filename>/usr/ports</filename> from
|
||||
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
|
||||
<para>The same methodology can be used for the ports tree. The first
|
||||
step is to share <filename>/usr/ports</filename> via
|
||||
<acronym>NFS</acronym> to all the machines in the build set. To
|
||||
configure <filename>/etc/make.conf</filename> to
|
||||
share distfiles, set <varname>DISTDIR</varname> to a common
|
||||
shared directory that is writable by whichever user
|
||||
<systemitem class="username">root</systemitem> is mapped to by
|
||||
the NFS mounts. Each machine should set
|
||||
<varname>WRKDIRPREFIX</varname> to a local build directory.
|
||||
Finally, if the system is to build and distribute packages,
|
||||
set <varname>PACKAGES</varname> to a directory similar to
|
||||
the <acronym>NFS</acronym> mount. Each machine should set
|
||||
<varname>WRKDIRPREFIX</varname> to a local build directory, if
|
||||
ports are to be built locally.
|
||||
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>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
Loading…
Reference in a new issue