svn commit: r44942 - head/en_US.ISO8859-1/articles/freebsd-update-server
Benedict Reuschling
bcr at FreeBSD.org
Sat May 24 20:23:35 UTC 2014
Author: bcr
Date: Sat May 24 20:23:35 2014
New Revision: 44942
URL: http://svnweb.freebsd.org/changeset/doc/44942
Log:
Whitespace fixes (bad tag indents, wrap long lines) that igor complained
about. Translators can ignore.
Modified:
head/en_US.ISO8859-1/articles/freebsd-update-server/article.xml
Modified: head/en_US.ISO8859-1/articles/freebsd-update-server/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/freebsd-update-server/article.xml Sat May 24 19:59:04 2014 (r44941)
+++ head/en_US.ISO8859-1/articles/freebsd-update-server/article.xml Sat May 24 20:23:35 2014 (r44942)
@@ -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>
-
-
- <author><personname><firstname>Jason</firstname><surname>Helfman</surname></personname><affiliation>
+<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>
<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 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 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 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 GB, and the webserver space needed to distribute
+ these updates is
2.6 GB.</para>
</listitem>
@@ -108,21 +123,24 @@
<sect1 xml:id="Configuration">
<title>Configuration: Installation & 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>
-
- <screen>&prompt.user; <userinput>svn co http://svn.freebsd.org/base/user/cperciva/freebsd-update-build freebsd-update-server</userinput></screen>
+ <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>
+
+ <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 x
<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>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>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>
</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 &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 <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>
</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 x
</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"
<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"
<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
<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
&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 fil
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 st
</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 st
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 st
<!-- 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 st
</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>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>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>
<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 st
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.
More information about the svn-doc-all
mailing list