From owner-freebsd-doc Tue Mar 19 1:10:40 2002 Delivered-To: freebsd-doc@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5437537B41D for ; Tue, 19 Mar 2002 01:10:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2J9A2x75180; Tue, 19 Mar 2002 01:10:02 -0800 (PST) (envelope-from gnats) Date: Tue, 19 Mar 2002 01:10:02 -0800 (PST) Message-Id: <200203190910.g2J9A2x75180@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org Cc: From: Martin Heinen Subject: Re: docs/36042: [PATCH] There's not a good description of shared builds in the handbook Reply-To: Martin Heinen Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR docs/36042; it has been noted by GNATS. From: Martin Heinen To: Mike Meyer 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 @@ > > > > + > + > + Tracking for multiple machines > + > + 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. ^^^^^^^^^^ Omit 'that works', this avoids doubling 'that'. Also all procedures given in the handbook should be working. > + > + > + Preliminaries > + > + First, identify a set of machines that is going to run > + the same set of binaries, which we will call a > + build set. 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 > + build machine. 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 make world. You will also want to > + choose a machine to be the test > + machine, which will test software updates before they > + are put into production. This must 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. ^^^^^^^^ machine > + > + All the machines in this build set need to mount > + /usr/obj and > + /usr/src 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 ^^^^^^^^ /usr/src > + on one build machine, and NFS mounted on the rest. > + > + Finally make sure that the > + /etc/make.conf 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 KERNCONF in > + /etc/make.conf, and the build machine > + should list them all in , listing > + it's own kernel first. It seems obvious, but we should mention to copy the kernel configuration files to the build machine. > + > + > + > + The base system > + > + Now that all that is done, you're read to build ^^^^^^^^^^^ you are ready > + everything. Build the kernel and world as described + linkend="make-buildworld">above on the build machine, ^^^^^ this is bad linking practice. Instead name the target of the link: in section Compile and Install the Base System > + 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 /usr/src > + and /usr/obj 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 shutdown now to go to single user > + mode. Once there, you can install the world and run > + mergemaster just as you normally do. Once > + done, use the command to reboot to normal > + multi-user operations for this machine. The procedure is different to normal build and should be outlined inside . > + > + 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. > + > + > + > + Ports > + > + The same ideas can be used for the ports tree. The first > + critical step is mounting /usr/ports from the same machine to ^^^^^^^^^^ /usr/ports > + all the machines in the build set. You can then set up > + /etc/make.conf properly to share > + distfiles. You should set DISTDIR 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 WRKDIRPREFIX to a > + local build directory. Finally, if you're going to be > + building and distributing packages, you should set > + PACKAGES to a directory similar to > + DISTDIR. > + > + > 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