From owner-freebsd-doc Mon Mar 18 1:20:10 2002 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A239C37B417 for ; Mon, 18 Mar 2002 01:20:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2I9K1C06619; Mon, 18 Mar 2002 01:20:01 -0800 (PST) (envelope-from gnats) Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 1090237B419 for ; Mon, 18 Mar 2002 01:12:27 -0800 (PST) Received: (qmail 36861 invoked by uid 100); 18 Mar 2002 09:12:19 -0000 Message-Id: <20020318091219.36860.qmail@mired.org> Date: 18 Mar 2002 09:12:19 -0000 From: Mike Meyer Reply-To: Mike Meyer To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.113 Subject: docs/36042: [PATCH] There's not a good description of shared builds in the handbook 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 >Number: 36042 >Category: docs >Synopsis: [PATCH] There's not a good description of shared builds in the handbook >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Mon Mar 18 01:20:01 PST 2002 >Closed-Date: >Last-Modified: >Originator: Mike Meyer >Release: FreeBSD 4.5-STABLE i386 >Organization: Meyer Consulting >Environment: System: FreeBSD guru.mired.org 4.5-STABLE FreeBSD 4.5-STABLE #1: Sun Mar 17 05:18:14 CST 2002 mwm@guru.mired.org:/sharetmp/obj/usr/src/sys/GURU i386 >Description: 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. >How-To-Repeat: Read through the handbook. >Fix: The attached English patch to the books/handbook/cutting-edge/chapter.sgml adds a section at the end that describes how to set things up so one machine keeps sources and does the builds, and others install those, including dealing with the ports tree. --- chapter.sgml.orig Mon Mar 18 02:27:48 2002 +++ chapter.sgml Mon Mar 18 03:11:25 2002 @@ -32,6 +32,10 @@ Nik Clayton + + Mike + Meyer + @@ -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. + + + 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 + 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. + + 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 + as well. If you have multiple build sets, /usr/src should be + 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. + + + + The base system + + Now that all that is done, you're read to build + everything. Build the kernel and world as described above on the build machine, + but don't install anything. After the build has finished, go + 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. + + 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 + 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. + +