Date: Tue, 19 Mar 2002 01:10:02 -0800 (PST) From: Martin Heinen <martin@sumuk.de> To: freebsd-doc@FreeBSD.org Subject: Re: docs/36042: [PATCH] There's not a good description of shared builds in the handbook Message-ID: <200203190910.g2J9A2x75180@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/36042; it has been noted by GNATS.
From: Martin Heinen <martin@sumuk.de>
To: Mike Meyer <mwm@mired.org>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: docs/36042: [PATCH] There's not a good description of shared builds in the handbook
Date: Tue, 19 Mar 2002 10:00:01 +0100
On Mon, Mar 18, 2002 at 09:12:19AM -0000, Mike Meyer wrote:
> The handbook describes updating the system on a single
> machine, but doesn't deal with the very common case of someone
> wanting multiple machines to track the same branch.
That's really missing and we should put the section
into the handbook.
> --- chapter.sgml.orig Mon Mar 18 02:27:48 2002
> +++ chapter.sgml Mon Mar 18 03:11:25 2002
> @@ -1625,6 +1629,98 @@
> </qandaset>
> </sect2>
> </sect1>
> +
> + <sect1 id="small-lan">
> + <title>Tracking for multiple machines</title>
> +
> + <para>If you have a small lan—or a large one—and 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, and the rest of the
> + machines mount that work via NFS. This section outlines a
> + method of doing that that works.</para>
^^^^^^^^^^
Omit 'that works', this avoids doubling 'that'. Also all procedures
given in the handbook should be working.
> +
> + <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's going to be the
^^^^
It's -> It is
> + 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 machihne, but need not be.</para>
^^^^^^^^
machine
> +
> + <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
Building on NFS volumes isn't a good thing. Although possible,
we shouldn't mention that here.
> + as well. If you have multiple build sets, /usr/src should be
^^^^^^^^
<filename>/usr/src</filename>
> + on one build machine, and NFS mounted on the rest.</para>
> +
> + <para>Finally make sure that the
> + <filename>/etc/make.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 that any machine in the build set is going to
> + install. Also, each build machine should have it's kernel
> + name as <varname>KERNCONF</varname> in
> + <filename>/etc/make.conf</filename>, and the build machine
> + should list them all in <option>KERNCONF</option>, listing
> + it's own kernel first.</para>
It seems obvious, but we should mention to copy the kernel
configuration files to the build machine.
> + </sect2>
> +
> + <sect2>
> + <title>The base system</title>
> +
> + <para>Now that all that is done, you're read to build
^^^^^^^^^^^
you are ready
> + everything. Build the kernel and world as described <xref
> + linkend="make-buildworld">above</xref> on the build machine,
^^^^^
this is bad linking practice. Instead name the target of the link:
in section <xref linkend="make-buildworld">Compile and Install
the Base System</xref>
> + but don't install anything. After the build has finished, go
^^^^^
do not
> + to the test machine, and install the kernel you just
> + build. 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 that is to boot to multi-user,
> + then do <command>shutdown now</command> to go to single user
> + mode. Once there, you can install the world and run
> + <command>mergemaster</command> just as you normally do. Once
> + done, use the <reboot>command</reboot> to reboot to normal
> + multi-user operations for this machine.</para>
The procedure is different to normal build and should be outlined
inside <screen>.
> +
> + <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 /usr/ports from the same machine to
^^^^^^^^^^
<filename>/usr/ports</filename>
> + all the machines in the build set. You can then set up
> + <filename>/etc/make.conf</filename> properly to share
> + distfiles. You should set <varname>DISTDIR</varname> to a
> + common shared directory that is writable by whichever user
> + root is going to be mapped to by your NFS mounts. Each
> + machine should set <varname>WRKDIRPREFIX</varname> to a
> + local build directory. Finally, if you're going to be
> + building and distributing packages, you should set
> + <varname>PACKAGES</varname> to a directory similar to
> + <varname>DISTDIR</varname>.</para>
> + </sect2>
> + </sect1>
> </chapter>
Please put two spaces at the end of sentences.
--
Marxpitn
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203190910.g2J9A2x75180>