diff --git a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml index 58e1f8ac7a..8067d8845f 100644 --- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1633,8 +1633,110 @@ Building everything.. - + + + + + Mike + Meyer + + + + Tracking for multiple machines + + If you 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, while the rest of the + machines mount that work via NFS. This section outlines a + method of doing so. + + + 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 is 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 machine, 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 + /etc/make.conf on all the machines in + the build set agrees 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 its kernel + name set with KERNCONF in + /etc/make.conf, and the build machine + should list them all in KERNCONF, listing + its own kernel first. The build machine must have the kernel + configuration files for each machine in + /usr/src/sys/arch/conf + if it is going to build their kernels. + + + + The base system + + Now that all that is done, you are ready to build + everything. Build the kernel and world as described in on the build machine, + but do not install anything. After the build has finished, go + to the test machine, and install the kernel you just + built. 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 this is to boot to multi-user, + then run shutdown now to go to single user + mode. Once there, you can install the new kernel and world and run + mergemaster just as you normally would. When + done, reboot to return 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 mapped to by your NFS mounts. Each + machine should set WRKDIRPREFIX to a + local build directory. Finally, if you are going to be + building and distributing packages, you should set + PACKAGES to a directory similar to + DISTDIR. + + +