os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Whitespace fixes (bad tag indents, wrap long lines) that igor complained

Browse source 
about. Translators can ignore.
This commit is contained in:
Benedict Reuschling 2014-05-24 20:23:35 +00:00
parent 713eec090c
commit 17d158057d
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44942
1 changed files with 228 additions and 183 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

411
en_US.ISO8859-1/articles/freebsd-update-server/article.xml
View file

@ -1,15 +1,22 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd" [
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE article PUBLIC
"-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd" [
<!ENTITY fbus.ap "<application xmlns='http://docbook.org/ns/docbook'>FreeBSD Update Server</application>">
]>
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<info><title>Build Your Own &os; Update Server</title>
<article xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:lang="en">
<info>
<title>Build Your Own &os; Update Server</title>
<author><personname><firstname>Jason</firstname><surname>Helfman</surname></personname><affiliation>
<author>
<personname>
<firstname>Jason</firstname>
<surname>Helfman</surname>
</personname>
<affiliation>
<address>&a.jgh.email;</address>
</affiliation></author>
</affiliation>
</author>
<copyright>
<year>2009</year>
@ -30,35 +37,40 @@
<releaseinfo>$FreeBSD$</releaseinfo>
<abstract>
<para>This article describes building an internal &fbus.ap;.
The <link xlink:href="http://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/">freebsd-update-server</link>
is written by &a.cperciva.email;, Security Officer Emeritus of &os;.
For users that think it is convenient to update their systems
against an official update server, building their own &fbus.ap; may
help to extend its functionality by supporting manually-tweaked
&os; releases or by providing a local mirror that will allow faster
updates for a number of machines.</para>
</abstract>
<abstract>
<para>This article describes building an internal &fbus.ap;.
The <link
xlink:href="http://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/">freebsd-update-server</link>
is written by &a.cperciva.email;, Security Officer Emeritus of
&os;. For users that think it is convenient to update their
systems against an official update server, building their own
&fbus.ap; may help to extend its functionality by supporting
manually-tweaked &os; releases or by providing a local mirror
that will allow faster updates for a number of
machines.</para>
</abstract>
</info>
<sect1 xml:id="acknowledgments">
<title>Acknowledgments</title>
<para>This article was subsequently printed at <link xlink:href="http://bsdmag.org/magazine/1021-bsd-as-a-desktop">BSD
Magazine</link>.</para>
<para>This article was subsequently printed at <link
xlink:href="http://bsdmag.org/magazine/1021-bsd-as-a-desktop">BSD
Magazine</link>.</para>
</sect1>
<sect1 xml:id="introduction">
<title>Introduction</title>
<para>Experienced users or administrators are often responsible for
several machines or environments. They understand the difficult
demands and challenges of maintaining such an infrastructure.
Running a &fbus.ap; makes it easier to deploy security and software
patches to selected test machines before rolling them out to
production. It also means a number of systems can be updated from the
local network rather than a potentially slower Internet connection.
This article outlines the steps involved in creating an internal
<para>Experienced users or administrators are often responsible
for several machines or environments. They understand the
difficult demands and challenges of maintaining such an
infrastructure. Running a &fbus.ap; makes it easier to deploy
security and software patches to selected test machines before
rolling them out to production. It also means a number of
systems can be updated from the local network rather than a
potentially slower Internet connection. This article outlines
the steps involved in creating an internal
&fbus.ap;.</para>
</sect1>
@ -80,9 +92,10 @@
</listitem>
<listitem>
<para>A user account with at least 4&nbsp;GB of available space.
This will allow the creation of updates for 7.1 and 7.2, but the
exact space requirements may change from version to version.</para>
<para>A user account with at least 4&nbsp;GB of available
space. This will allow the creation of updates for 7.1 and
7.2, but the exact space requirements may change from
version to version.</para>
</listitem>
<listitem>
@ -91,10 +104,12 @@
</listitem>
<listitem>
<para>A web server, like <link xlink:href="&url.books.handbook;/network-apache.html">Apache</link>,
with over half of the space required for the build. For instance,
test builds for 7.1 and 7.2 consume a total amount of 4&nbsp;GB,
and the webserver space needed to distribute these updates is
<para>A web server, like <link
xlink:href="&url.books.handbook;/network-apache.html">Apache</link>,
with over half of the space required for the build. For
instance, test builds for 7.1 and 7.2 consume a total amount
of 4&nbsp;GB, and the webserver space needed to distribute
these updates is
2.6&nbsp;GB.</para>
</listitem>
@ -108,21 +123,24 @@
<sect1 xml:id="Configuration">
<title>Configuration: Installation &amp; Setup</title>
<para>Download the <link xlink:href="http://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/">
freebsd-update-server</link> software by installing <package>devel/subversion </package>, and execute:</para>
<para>Download the <link
xlink:href="http://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/">
freebsd-update-server</link> software by installing
<package>devel/subversion </package>, and execute:</para>
<screen>&prompt.user; <userinput>svn co http://svn.freebsd.org/base/user/cperciva/freebsd-update-build freebsd-update-server</userinput></screen>
<screen>&prompt.user; <userinput>svn co
http://svn.freebsd.org/base/user/cperciva/freebsd-update-build
freebsd-update-server</userinput></screen>
<para>Update <filename>scripts/build.conf</filename> appropriately.
It is sourced during all build operations.</para>
<para>Update <filename>scripts/build.conf</filename>
appropriately. It is sourced during all build
operations.</para>
<para>Here is the default <filename>build.conf</filename>, which should
be modified to suit your environment.</para>
<para>Here is the default <filename>build.conf</filename>, which
should be modified to suit your environment.</para>
<informalexample>
<programlisting>
# Main configuration file for FreeBSD Update builds. The
<programlisting># Main configuration file for FreeBSD Update builds. The
# release-specific configuration data is lower down in
# the scripts tree.
@ -149,57 +167,57 @@ MASTERDIR=update-master.freebsd.org<co xml:id="mstdir-id"/></programlisting>
<calloutlist>
<callout arearefs="ftp-id">
<para>This is the location where ISO images are downloaded from (by
the <function>fetchiso()</function> subroutine
of <filename>scripts/build.subr</filename>). The location
configured is not limited to FTP URIs. Any URI scheme
supported by standard &man.fetch.1; utility should work
fine.</para>
<para>This is the location where ISO images are downloaded
from (by the <function>fetchiso()</function> subroutine of
<filename>scripts/build.subr</filename>). The location
configured is not limited to FTP URIs. Any URI scheme
supported by standard &man.fetch.1; utility should work
fine.</para>
<para>Customizations to the <function>fetchiso()</function> code can
be installed by copying the
default <filename>build.subr</filename> script to the release and
architecture-specific area
at <filename>scripts/RELEASE/ARCHITECTURE/build.subr</filename>
and applying local changes.</para>
<para>Customizations to the <function>fetchiso()</function>
code can be installed by copying the default
<filename>build.subr</filename> script to the release and
architecture-specific area at
<filename>scripts/RELEASE/ARCHITECTURE/build.subr</filename>
and applying local changes.</para>
</callout>
<callout arearefs="buildhost-id">
<para>The name of the build host. This information will be
displayed on updated systems when issuing:</para>
<para>The name of the build host. This information will be
displayed on updated systems when issuing:</para>
<screen>&prompt.user; <userinput>uname -v</userinput></screen>
</callout>
<callout arearefs="sshkey-id">
<para>The <application>SSH</application> key for uploading files to
the update server. A key pair can be created by
typing <command>ssh-keygen -t dsa</command>. This parameter is
optional; standard password authentication will be used as a
fallback authentication method when <literal>SSHKEY</literal> is
not defined.</para>
<para>The <application>SSH</application> key for uploading
files to the update server. A key pair can be created by
typing <command>ssh-keygen -t dsa</command>. This parameter
is optional; standard password authentication will be used
as a fallback authentication method when
<literal>SSHKEY</literal> is not defined.</para>
<para>The &man.ssh-keygen.1; manual page has more detailed
information about <application>SSH</application> and the
appropriate steps for creating and using one.</para>
<para>The &man.ssh-keygen.1; manual page has more detailed
information about <application>SSH</application> and the
appropriate steps for creating and using one.</para>
</callout>
<callout arearefs="mstacct-id">
<para>Account for uploading files to the update
server.</para>
<para>Account for uploading files to the update server.</para>
</callout>
<callout arearefs="mstdir-id">
<para>Directory on the update server where files are uploaded
to.</para>
<para>Directory on the update server where files are uploaded
to.</para>
</callout>
</calloutlist>
<para>The default <filename>build.conf</filename> shipped with
the <application>freebsd-update-server</application> sources is
suitable for building &arch.i386; releases of &os;. As an example of
building an update server for other architectures, the following steps
outline the configuration changes needed for &arch.amd64;:</para>
<para>The default <filename>build.conf</filename> shipped with the
<application>freebsd-update-server</application> sources is
suitable for building &arch.i386; releases of &os;. As an
example of building an update server for other architectures,
the following steps outline the configuration changes needed for
&arch.amd64;:</para>
<procedure>
<step>
@ -211,13 +229,13 @@ MASTERDIR=update-master.freebsd.org<co xml:id="mstdir-id"/></programlisting>
</step>
<step>
<para>Install a <filename>build.conf</filename> in the
newly created build directory. The build configuration
options for &os; 7.2-RELEASE on &arch.amd64; should be similar
<para>Install a <filename>build.conf</filename> in the newly
created build directory. The build configuration options
for &os; 7.2-RELEASE on &arch.amd64; should be similar
to:</para>
<informalexample>
<programlisting># SHA256 hash of RELEASE disc1.iso image.
<programlisting># SHA256 hash of RELEASE disc1.iso image.
export RELH=1ea1f6f652d7c5f5eab7ef9f8edbed50cb664b08ed761850f95f48e86cc71ef5<co xml:id="sha256-id"/>
# Components of the world, source, and kernels
@ -233,17 +251,22 @@ export EOL=1275289200<co xml:id="eol-id"/></programlisting>
<calloutlist>
<callout arearefs="sha256-id">
<para>The &man.sha256.1; hash key for the desired release, is
published within the respective <link xlink:href="&url.base;/releases/">release announcement</link>.</para>
<para>The &man.sha256.1; hash key for the desired release,
is published within the respective <link
xlink:href="&url.base;/releases/">release
announcement</link>.</para>
</callout>
<callout arearefs="eol-id">
<para>To generate the "End of Life" number for
<filename>build.conf</filename>, refer to the "Estimated
EOL" posted on the <link xlink:href="&url.base;/security/security.html">&os;
Security Website</link>. The value
of <literal>EOL</literal> can be derived from the date listed on
the web site, using the &man.date.1; utility, for example:</para>
<para>To generate the "End of Life" number for
<filename>build.conf</filename>, refer to the "Estimated
EOL" posted on the <link
xlink:href="&url.base;/security/security.html">&os;
Security Website</link>. The value of
<literal>EOL</literal> can be derived from the date
listed on the web site, using the &man.date.1; utility,
for example:</para>
<screen>&prompt.user; <userinput>date -j -f '%Y%m%d-%H%M%S' '20090401-000000' '+%s'</userinput></screen>
</callout>
</calloutlist>
@ -254,10 +277,11 @@ export EOL=1275289200<co xml:id="eol-id"/></programlisting>
<sect1 xml:id="build">
<title>Building Update Code</title>
<para>The first step is to run <filename>scripts/make.sh</filename>.
This will build some binaries, create directories, and generate an RSA
signing key used for approving builds. In this step, a passphrase will
have to be supplied for the final creation of the signing key.</para>
<para>The first step is to run
<filename>scripts/make.sh</filename>. This will build some
binaries, create directories, and generate an RSA signing key
used for approving builds. In this step, a passphrase will have
to be supplied for the final creation of the signing key.</para>
<screen>&prompt.root; <userinput>sh scripts/make.sh</userinput>
cc -O2 -fno-strict-aliasing -pipe findstamps.c -o findstamps
@ -281,8 +305,8 @@ Verifying - enter aes-256-cbc encryption password:</screen>
<note>
<para>Keep a note of the generated key fingerprint. This value
is required in <filename>/etc/freebsd-update.conf</filename> for
binary updates.</para>
is required in <filename>/etc/freebsd-update.conf</filename>
for binary updates.</para>
</note>
<para>At this point, we are ready to stage a build.</para>
@ -292,8 +316,8 @@ Verifying - enter aes-256-cbc encryption password:</screen>
&prompt.root; <userinput>sh scripts/init.sh <replaceable>amd64 7.2-RELEASE</replaceable></userinput></screen>
</informalexample>
<para>What follows is a sample of an <emphasis>initial</emphasis> build
run.</para>
<para>What follows is a sample of an <emphasis>initial</emphasis>
build run.</para>
<screen>&prompt.root; <userinput>sh scripts/init.sh amd64 7.2-RELEASE</userinput>
Mon Aug 24 16:04:36 PDT 2009 Starting fetch for FreeBSD/amd64 7.2-RELEASE
@ -341,11 +365,13 @@ world|base|/usr/lib/libalias_ftp.a
<warning>
<para>During this second build cycle, the network time protocol
daemon, &man.ntpd.8;, is turned off. Per &a.cperciva.email;,
Security Officer Emeritus of &os;, "the <link xlink:href="http://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/">freebsd-update-server</link>
build code needs to identify timestamps which are stored in files so
that they can be ignored when comparing builds to determine which
files need to be updated. This timestamp-finding works by doing two
builds 400 days apart and comparing the results."</para>
Security Officer Emeritus of &os;, "the <link
xlink:href="http://svnweb.freebsd.org/base/user/cperciva/freebsd-update-build/">freebsd-update-server</link>
build code needs to identify timestamps which are stored in
files so that they can be ignored when comparing builds to
determine which files need to be updated. This
timestamp-finding works by doing two builds 400 days apart and
comparing the results."</para>
</warning>
<screen>Mon Aug 24 17:54:07 PDT 2009 Extracting world+src for FreeBSD/amd64 7.2-RELEASE
@ -417,12 +443,12 @@ they look sensible, then run
# sh -e approve.sh amd64 7.2-RELEASE
to sign the release.</screen>
<para>Approve the build if everything is correct. More information on
determining this can be found in the distributed source
file named <filename>USAGE</filename>. Execute
<filename>scripts/approve.sh</filename>, as directed. This will sign
the release, and move components into a staging area suitable for
uploading.</para>
<para>Approve the build if everything is correct. More
information on determining this can be found in the distributed
source file named <filename>USAGE</filename>. Execute
<filename>scripts/approve.sh</filename>, as directed. This will
sign the release, and move components into a staging area
suitable for uploading.</para>
<informalexample>
<screen>&prompt.root; <userinput>cd /usr/local/freebsd-update-server</userinput>
@ -436,8 +462,8 @@ Wed Aug 26 12:50:06 PDT 2009 Copying files to upload staging area for FreeBSD/am
Wed Aug 26 12:50:07 PDT 2009 Updating databases for FreeBSD/amd64 7.2-RELEASE
Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE</screen>
<para>After the approval process is complete, the upload procedure may
be started.</para>
<para>After the approval process is complete, the upload procedure
may be started.</para>
<informalexample>
<screen>&prompt.root; <userinput>cd /usr/local/freebsd-update-server</userinput>
@ -445,9 +471,9 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE
</informalexample>
<note>
<para>In the event update code needs to be re-uploaded, this may be
done by changing to the public distributions directory for the
target release and updating attributes of the
<para>In the event update code needs to be re-uploaded, this may
be done by changing to the public distributions directory for
the target release and updating attributes of the
<emphasis>uploaded</emphasis> file.</para>
<informalexample>
@ -460,12 +486,13 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE
avoid making the instructions Apache-specific here. -->
<!-- there are specific web instructions in the uploaded code that pertain to Apache. I believe it is worded fine here, now, and if others choose to use another web server, that is their choice to figure out -->
<para>The uploaded files will need to be in the
document root of the webserver in order for updates
to be distributed. The exact configuration will vary depending on the
web server used. For the <application>Apache</application> web server,
please refer to the <link xlink:href="&url.books.handbook;/network-apache.html">Configuration of
Apache servers</link> section in the Handbook.</para>
<para>The uploaded files will need to be in the document root of
the webserver in order for updates to be distributed. The exact
configuration will vary depending on the web server used. For
the <application>Apache</application> web server, please refer
to the <link
xlink:href="&url.books.handbook;/network-apache.html">Configuration
of Apache servers</link> section in the Handbook.</para>
<!-- This note seems either out of place. I find it hard to read and it
is a bit difficult to understand why it is related to the rest of
@ -489,37 +516,45 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE
<!-- What is a 'KeyPrint'? -->
<para>Update client's <literal>KeyPrint</literal> and
<literal>ServerName</literal> in
<filename>/etc/freebsd-update.conf</filename>, and perform updates as
instructed in the <link xlink:href="&url.books.handbook;/updating-upgrading-freebsdupdate.html">&os;
<filename>/etc/freebsd-update.conf</filename>, and perform
updates as instructed in the <link
xlink:href="&url.books.handbook;/updating-upgrading-freebsdupdate.html">&os;
Update</link>
<!-- One sentence, two instances of 'in'. We can probably reword this
<!-- One sentence, two instances of 'in'. We can probably
reword this
part to avoid repetition. -->
<!-- What about "place client's new keyprint and servername values to
freebsd-update.conf, ..."? gabor -->
section of the Handbook.</para>
<!-- What about "place client's new keyprint and servername
values to
freebsd-update.conf, ..."? gabor --> section of the
Handbook.</para>
<!-- Sorry folks, but I disagree here. I believe it is worded fine. If anything, drop everything after "perform" and change "updates" to "FreeBSD Updates" and link that to the handbook -->
<important>
<para>In order for &fbus.ap; to work properly, updates
for both the <emphasis>current</emphasis> release and the
release <emphasis>one wants to upgrade to</emphasis> need to be
built. This is necessary for determining the differences of
files between releases. For example, when upgrading a &os;
system from 7.1-RELEASE to 7.2-RELEASE, updates will need to be built
and uploaded to your distribution server for both versions.</para>
<para>In order for &fbus.ap; to work properly, updates for both
the <emphasis>current</emphasis> release and the release
<emphasis>one wants to upgrade to</emphasis> need to be built.
This is necessary for determining the differences of files
between releases. For example, when upgrading a &os; system
from 7.1-RELEASE to 7.2-RELEASE, updates will need to be built
and uploaded to your distribution server for both
versions.</para>
</important>
<para>For reference, the entire run of <link xlink:href="init.txt"><filename>init.sh</filename></link> is
<para>For reference, the entire run of <link
xlink:href="init.txt"><filename>init.sh</filename></link> is
attached.</para>
</sect1>
<sect1 xml:id="patch">
<title>Building a Patch</title>
<para>Every time a <link xlink:href="&url.base;/security/advisories.html">security advisory</link>
or <link xlink:href="&url.base;/security/notices.html">security notice</link>
is announced, a patch update can be built.</para>
<para>Every time a <link
xlink:href="&url.base;/security/advisories.html">security
advisory</link> or <link
xlink:href="&url.base;/security/notices.html">security
notice</link> is announced, a patch update can be
built.</para>
<para>For this example, 7.1-RELEASE will be used.</para>
@ -537,38 +572,43 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE
</listitem>
</itemizedlist>
<para>Create the patch directory of the respective release
under <filename>/usr/local/freebsd-update-server/patches/</filename>.</para>
<para>Create the patch directory of the respective release under
<filename>/usr/local/freebsd-update-server/patches/</filename>.</para>
<informalexample>
<screen>&prompt.user; <userinput>mkdir -p /usr/local/freebsd-update-server/patches/7.1-RELEASE/</userinput>
&prompt.user; <userinput>cd /usr/local/freebsd-update-server/patches/7.1-RELEASE</userinput></screen>
</informalexample>
<para>As an example, take the patch for &man.named.8;. Read the advisory,
and grab the necessary file from <link xlink:href="&url.base;/security/advisories.html">&os; Security
Advisories</link>. More information on interpreting the advisory,
can be found in the <link xlink:href="&url.books.handbook;/security-advisories.html">&os; Handbook</link>.</para>
<para>As an example, take the patch for &man.named.8;. Read the
advisory, and grab the necessary file from <link
xlink:href="&url.base;/security/advisories.html">&os; Security
Advisories</link>. More information on interpreting the
advisory, can be found in the <link
xlink:href="&url.books.handbook;/security-advisories.html">&os;
Handbook</link>.</para>
<para>In the <link xlink:href="http://security.freebsd.org/advisories/FreeBSD-SA-09:12.bind.asc">security brief</link>,
this advisory is called <literal>SA-09:12.bind</literal>. After
downloading the file, it is required to rename the file to an
appropriate patch level. It is suggested to keep this consistent with
official &os; patch levels, but its name may be freely chosen.
For this build, let us follow the currently established practice of
&os; and call this <literal>p7</literal>. Rename the file:</para>
<para>In the <link
xlink:href="http://security.freebsd.org/advisories/FreeBSD-SA-09:12.bind.asc">security
brief</link>, this advisory is called
<literal>SA-09:12.bind</literal>. After downloading the file,
it is required to rename the file to an appropriate patch level.
It is suggested to keep this consistent with official &os; patch
levels, but its name may be freely chosen. For this build, let
us follow the currently established practice of &os; and call
this <literal>p7</literal>. Rename the file:</para>
<informalexample>
<screen>&prompt.user; <userinput>cd /usr/local/freebsd-update-server/patches/7.1-RELEASE/; mv bind.patch 7-SA-09:12.bind </userinput></screen>
</informalexample>
<note>
<para>When running a patch level build, it is assumed that previous
patches are in place. When a patch build is run, it will run all
patches contained in the patch directory.</para>
<para>When running a patch level build, it is assumed that
previous patches are in place. When a patch build is run, it
will run all patches contained in the patch directory.</para>
<para>There can be custom patches added to any build. Use the number
zero, or any other number.</para>
<para>There can be custom patches added to any build. Use the
number zero, or any other number.</para>
</note>
<warning>
@ -577,18 +617,18 @@ Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE
patch.</para>
</warning>
<para>At this point, a <emphasis>diff</emphasis> is ready to be built.
The software checks first to see if a
<filename>scripts/init.sh</filename> has been run on the respective
release prior to running the diff build.</para>
<para>At this point, a <emphasis>diff</emphasis> is ready to be
built. The software checks first to see if a
<filename>scripts/init.sh</filename> has been run on the
respective release prior to running the diff build.</para>
<informalexample>
<screen>&prompt.root; <userinput>cd /usr/local/freebsd-update-server</userinput>
&prompt.root; <userinput>sh scripts/diff.sh <replaceable>amd64 7.1-RELEASE 7</replaceable></userinput></screen>
</informalexample>
<para>What follows is a sample of a <emphasis>differential</emphasis>
build run.</para>
<para>What follows is a sample of a
<emphasis>differential</emphasis> build run.</para>
<screen>&prompt.root; <userinput>sh -e scripts/diff.sh amd64 7.1-RELEASE 7</userinput>
Wed Aug 26 10:09:59 PDT 2009 Extracting world+src for FreeBSD/amd64 7.1-RELEASE-p7
@ -704,8 +744,8 @@ the new builds.</screen>
&prompt.root; <userinput>sh scripts/upload.sh <replaceable>amd64 7.1-RELEASE</replaceable></userinput></screen>
</informalexample>
<para>For reference, the entire run of
<link xlink:href="diff.txt"><filename>diff.sh</filename></link> is
<para>For reference, the entire run of <link
xlink:href="diff.txt"><filename>diff.sh</filename></link> is
attached.</para>
</sect1>
@ -732,17 +772,20 @@ the new builds.</screen>
<itemizedlist>
<listitem>
<para>If a custom release is built using the native
<command>make release</command> <link xlink:href="&url.articles.releng;/release-build.html">procedure</link>,
<application>freebsd-update-server</application> code will work
from your release. As an example, a release without ports or
documentation can be built by clearing functionality pertaining
to documentation subroutines <function> findextradocs ()</function>,
<function>addextradocs ()</function> and altering the download
location in <function>fetchiso ()</function>, respectively, in
<filename>scripts/build.subr</filename>. As a last step, change
the &man.sha256.1; hash in <filename>build.conf</filename> under
your respective release and architecture and you are ready to build
off your custom release.</para>
<command>make release</command> <link
xlink:href="&url.articles.releng;/release-build.html">procedure</link>,
<application>freebsd-update-server</application> code will
work from your release. As an example, a release without
ports or documentation can be built by clearing
functionality pertaining to documentation subroutines
<function> findextradocs ()</function>,
<function>addextradocs ()</function> and altering the
download location in <function>fetchiso ()</function>,
respectively, in <filename>scripts/build.subr</filename>.
As a last step, change the &man.sha256.1; hash in
<filename>build.conf</filename> under your respective
release and architecture and you are ready to build off your
custom release.</para>
<screen># Compare ${WORKDIR}/release and ${WORKDIR}/$1, identify which parts
# of the world|doc subcomponent are missing from the latter, and
@ -752,17 +795,18 @@ the new builds.</screen>
# Add extra docs to ${WORKDIR}/$1
addextradocs () {
}
</screen>
}</screen>
</listitem>
<listitem>
<para>Adding <option>-j <replaceable>NUMBER</replaceable></option>
flags to <buildtarget>buildworld</buildtarget> and
<para>Adding <option>-j
<replaceable>NUMBER</replaceable></option> flags to
<buildtarget>buildworld</buildtarget> and
<buildtarget>obj</buildtarget> targets in the
<filename>scripts/build.subr</filename> script may speed up
processing depending on the hardware used, however it is not
necessary. Using these flags in other targets is not
recommended, as it may cause the build to become unreliable.</para>
recommended, as it may cause the build to become
unreliable.</para>
<screen> # Build the world
log "Building world"
@ -777,11 +821,12 @@ the new builds.</screen>
</listitem>
<listitem>
<para>Create an appropriate <link xlink:href="&url.books.handbook;/network-dns.html">DNS</link>
SRV record for the update server, and put others behind it with
variable weights. Using this facility will provide update
mirrors, however this tip is not necessary unless you wish to
provide a redundant service.</para>
<para>Create an appropriate <link
xlink:href="&url.books.handbook;/network-dns.html">DNS</link>
SRV record for the update server, and put others behind it
with variable weights. Using this facility will provide
update mirrors, however this tip is not necessary unless you
wish to provide a redundant service.</para>
<screen> _http._tcp.update.myserver.com. IN SRV 0 2 80 host1.myserver.com.
SRV 0 1 80 host2.myserver.com.