fedora-docs/mirror-tutorial Makefile, NONE, 1.1 mirror-tutorial-en.xml, NONE, 1.1
Karsten Wade (kwade)
fedora-docs-commits at redhat.com
Thu May 5 19:04:46 UTC 2005
Author: kwade
Update of /cvs/docs/fedora-docs/mirror-tutorial
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8568
Added Files:
Makefile mirror-tutorial-en.xml
Log Message:
These should be the latest changes I made to Paul's original, hopefully the diff is still sane.
--- NEW FILE Makefile ---
###############################################################################
# Makefile for RHLP docs project
# Created by: Tammy Fox <tfox at redhat.com>
# Last edited by: Tammy Fox <tfox at redhat.com>
# WARNING: need passivetex 1.24 for pdf generation to work
# License: GPL
# Copyright 2003 Tammy Fox, Red Hat, Inc.
###############################################################################
XSLPDF = ../xsl/main-pdf.xsl
XSLHTML = ../xsl/main-html.xsl
LANG = en
DOCNAME = mirror-tutorial-$(LANG)
XMLFILE = $(DOCNAME).xml
######################################################
html:
@xmlto html -x $(XSLHTML) -o $(DOCNAME) $(XMLFILE)
@mkdir -p $(DOCNAME)/stylesheet-images
@cp ../stylesheet-images/*.png $(DOCNAME)/stylesheet-images
@cp ../css/fedora.css $(DOCNAME)
pdf-%:
@xmlto pdf -x $(XSLPDF) $(XMLFILE)
######################################################
clean:
@rm -rfv *.html *.pdf *.tex $(DOCNAME)
--- NEW FILE mirror-tutorial-en.xml ---
<!-- $Id: -->
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY % FEDORA-ENTITIES-EN SYSTEM "../common/fedora-entities-en.xml">
%FEDORA-ENTITIES-EN;
<!ENTITY BOOKID "mirror-tutorial-0.23 (2004-09-08)"> <!-- change version of manual and date here -->
]>
<article id="mirror-tutorial" lang="en">
<articleinfo>
<title>Mirror Tutorial</title>
<copyright>
<year>
2004
</year>
<holder>
Paul W. Frields
</holder>
</copyright>
<authorgroup>
<author>
<surname>
Frields
</surname>
<firstname>
Paul
</firstname>
<othername role="mi">
W.
</othername>
</author>
</authorgroup>
&LEGALNOTICE;
<revhistory>
<revision>
<revnumber>0.2</revnumber>
<date>2004-08-31</date>
<authorinitials>PaulWFrields</authorinitials>
<revdescription>
<para>
Initial version for editorial process.
</para>
</revdescription>
</revision>
<revision>
<revnumber>0.21</revnumber>
<date>2004-09-02</date>
<authorinitials>PaulWFrields</authorinitials>
<revdescription>
<para>
Revised screen sections to use inline tags as discussed on
fedora-docs-list; minor error corrections.
</para>
</revdescription>
</revision>
<revision>
<revnumber>0.22</revnumber>
<date>2004-09-06</date>
<authorinitials>PaulWFrields</authorinitials>
<revdescription>
<para>
Style editing.
</para>
</revdescription>
</revision>
<revision>
<revnumber>0.23</revnumber>
<date>2004-09-08</date>
<authorinitials>PaulWFrields</authorinitials>
<revdescription>
<para>
Additional style editing.
</para>
</revdescription>
</revision>
</revhistory>
</articleinfo>
<section id="sn-introduction">
<title>Introduction</title>
<section id="sn-purpose">
<title>Purpose</title>
<para>
This tutorial presents a number of related topics that allow an
administrator to seamlessly integrate mirroring and update services for
&FC;. These services are used to provision a classroom, laboratory, or
office. These service provisions also increase ease of use and enhance
user experience, adding to the perceived value of non-proprietary
operating systems and software.
</para>
<note>
<title>A note about &FC; and this document</title>
<para>
This document applies to &FC; &FCVER;, which may not be the newest
release of &FC;. Find more information about the newest version at
&FP-URL;.
</para>
</note>
</section>
<section id="sn-audience">
<title>Audience</title>
<para>
You will find this tutorial more useful if you are a system
administrator, or a &FC; <quote>power user</quote> familiar with the
following topics:
</para>
<itemizedlist>
<listitem>
<para>
&FC; system installation
</para>
</listitem>
<listitem>
<para>
Basic Internet protocols (HTTP/Web, FTP)
</para>
</listitem>
<listitem>
<para>
Using a command line interface
</para>
</listitem>
</itemizedlist>
</section>
<section id="sn-about-mirrors">
<title>About Mirrors</title>
<para>
A <emphasis>mirror</emphasis>
<indexterm><primary>mirror</primary></indexterm> is a server that
provides a copy of one or more collections of files. Mirroring a site
reduces traffic to the original source site, thus spreading the stress
and bandwidth costs of many users across many sites. Side benefits of
running a local mirror include very fast access through the local
network, providing custom services to local users, and increasing your
skills in managing Internet services.
</para>
<para>
The site from which you retrieve files to build your mirror is called an
<emphasis>upstream mirror</emphasis><indexterm>
<primary>mirror</primary> <secondary>upstream</secondary>
</indexterm>. If possible, choose an upstream mirror that is located
close to you geographically. This reduces unnecessary traffic across
transcontinental sections of the Internet, where bandwidth is limited
and expensive.
</para>
</section>
<section id="sn-additional-resources">
<title>Additional Resources</title>
<para>
For more information on installing &FC; see the &FC; &IG;<!-- at
&IG-URL; -->. For more information on basic Internet protocols, see
<ulink
url="http://library.albany.edu/internet/internet.html">http://library.albany.edu/internet/internet.html</ulink>,
or search Google at <ulink
url="http://www.google.com/">http://www.google.com/</ulink>. For more
general information about mirrors, see <ulink
url="http://en.wikipedia.org/wiki/Mirror_(computing)">http://en.wikipedia.org/wiki/Mirror_(computing)</ulink>.
</para>
</section>
<section id="sn-acknowledgements">
<title>Acknowledgements</title>
<para>
Karsten Wade provided editorial services, keeping the style crisp and
consistent.
</para>
</section>
</section>
<section id="sn-planning-and-setup">
<title>Planning and Setup</title>
<!-- I see you removed the following to <para>s in an edit, was this -->
<!-- intentional? -->
<para>
A <firstterm>mirror</firstterm>
<indexterm><primary>mirror</primary></indexterm> is a server that provides
a copy of one or more collections of files. Mirroring a site reduces
traffic to the original source site, thus spreading the stress and
bandwidth costs of many users across many sites. Side benefits of running
a local mirror include very fast access through the local network,
providing custom services to local users, and increasing your skills in
managing Internet services.
</para>
<para>
The <firstterm>upstream mirror</firstterm><indexterm>
<primary>mirror</primary>
<secondary>upstream</secondary> </indexterm> is the site you retrieve
files from to build your mirror. If possible, choose an upstream mirror
that is located close to you geographically. This reduces unnecessary
traffic across transcontinental sections of the Internet, where bandwidth
is limited and expensive.
</para>
<section id="sn-hierarchy">
<title>The Distribution Structure</title>
<para>
The &FED; <firstterm>distribution</firstterm><indexterm>
<primary>distribution</primary>
</indexterm>, which is the collection of all &FED;-related files, uses
the directory tree in <xref linkend="ex-fedora-dir-tree"/>. It may
include multiple versions of &FC;. The tree design makes trimming of
unnecessary or undesired files easier. When setting up a mirror,
duplicate this tree exactly, or as closely as possible. Doing so makes
automating nightly updates easier.
</para>
<example id="ex-fedora-dir-tree">
<title>Fedora directory tree</title>
<screen>
<computeroutput>fedora
+-- linux
+-- core
|-- 1
| ...
+-- &FCVER;
| +-- SRPMS
| +-- i386
| | +-- debug
| | +-- iso
| | +-- os
| | +-- Fedora
| | +-- SRPMS
| | +-- images
| | +-- isolinux
| +-- x86_64
+-- development
| ...
+-- test
| ...
+-- updates
+-- 1
| ...
+-- &FCVER;
| +-- SRPMS
| +-- i386
| +-- x86_64
+-- testing
+-- 1
| ...
+-- &FCVER;
+-- SRPMS
+-- i386
+-- x86_64</computeroutput>
</screen>
</example>
<note>
<title>Naming conventions</title>
<para>
Throughout the rest of the document,
<filename>/var/ftp/pub/mirror</filename> represents the folder where
all your mirrored files are stored. You may substitute a different
location. This location simplifies sharing your mirror, due to the
shipping configuration of &FC;. See <xref linkend="sn-server-config"/>
for more information. The site name
<computeroutput>mirror.example.com</computeroutput> represents the
upstream mirror.
</para>
</note>
<para>
The
<filename>fedora/linux/core/&FCVER;/<replaceable>arch</replaceable>/os</filename>
directory contains a copy of all the original distribution files for
&FC; &FCVER;. They are the same files found on the CD-ROM version of the
distribution. The <filename>&FED;</filename> subfolder contains all the
files that are necessary for installation, including the entire
collection of &FC; RPM packages. The <filename>images</filename> folder
contains copies of any floppy diskette or CD-ROM images that boot a
system into installation or rescue modes. The
<filename>fedora/linux/core/&FCVER;/<replaceable>arch</replaceable>/iso</filename>
folder contains images of the CD-ROM version of the distribution.
</para>
<note>
<title>RPM packages</title>
<para>
<firstterm>RPM</firstterm><indexterm>
<primary>RPM</primary>
</indexterm>, originally the Red Hat Package Manager, now the RPM
Package Manager, is not just a file format. RPM is also a system which
tracks and interconnects software and version information. The RPM
system is quite popular, and many other Linux distributions use RPM as
well. Read more information on RPM at <ulink
url="http://www.rpm.org/">http://www.rpm.org/</ulink>. This document
contains helpful hints on making the most of RPM, in <xref
linkend="sn-server-config"/> and
<xref linkend="sn-client-config"/>.
</para>
</note>
<para>
The <filename>SRPMS</filename> folders under architecture-specific
branches are links which point to the main <filename>SRPMS</filename>
folder for that distribution. For example,
<filename>fedora/linux/core/2/i386/os/SRPMS</filename> is a link which
points to <filename>fedora/linux/core/2/SRPMS</filename>.
</para>
<para>
A &FED; mirror consists of at least the original ISO images
<emphasis>or</emphasis> the distribution files. If possible, include
both, provided you have sufficient disk space and/or bandwidth.
</para>
</section>
<section id="sn-copying-original-distribution">
<title>Copying the Original Distribution</title>
<para>
If you already have reliable CD-ROM installation discs of a
distribution, reduce your initial bandwidth and time spent mirroring by
copying the files from the discs to your server. Copy all files from
Installation Disc 1 into the
<filename>fedora/linux/core/&FCVER;/<replaceable>arch</replaceable>/os</filename>
folder. Then copy all files from the <filename>&FED;</filename> folder
of each of the remaining installation discs into the
<filename>fedora/linux/core/&FCVER;/<replaceable>arch</replaceable>/os/&FED;</filename>
folder on the server.
</para>
<para>
Copy all the files from the <filename>SRPMS</filename> folder on each of
the <quote>Sources</quote> discs to the
<filename>fedora/linux/core/&FCVER;/SRPMS</filename> folder on the
server. Make a link in the <filename>os</filename> folder that occurs
under each architecture. Follow this example:
</para>
<screen>
<userinput>cd /var/ftp/pub/mirror/fedora/linux/core/&FCVER;/i386/os/Fedora
ln ../../SRPMS SRPMS</userinput>
</screen>
<para>
The documentation for <application>anaconda</application><indexterm>
<primary>anaconda</primary>
</indexterm>, the &FC; installation program, calls this directory
structure an <firstterm>exploded tree</firstterm><indexterm>
<primary>exploded tree</primary>
</indexterm>. This is because the package data on each CD is extracted,
or exploded, to a large directory tree with a predetermined structure.
The <application>anaconda</application> installer expects this structure
to some extent.
</para>
<para>
If you <emphasis>only</emphasis> include CD images, create a mirror
suitable for installation services by mounting each CD image under the
<filename><replaceable>arch</replaceable>/os/</filename> directory. Make
a directory for each disc, naming them <filename>disc1</filename>,
<filename>disc2</filename>, and so on. Mount each disc on the
appropriate folder, and add entries to <filename>/etc/fstab</filename>
to perform this mount automatically in case of a reboot. Each entry
looks like this:
</para>
<screen>
<computeroutput>/path/i386/iso/FC&FCVER;-i386-disc1.iso /path/i386/os/disc1 iso9660 defaults 0 0</computeroutput>
</screen>
<para>
The <application>anaconda</application> application automatically
detects these folders and uses them properly. In addition, system
configuration tools such as
<application>system-config-packages</application> also continue to work
properly when pointed at the parent of the ISO image mount points.
</para>
<!-- FIXME: Is the above true? See other questions below... -->
<para>
There are drawbacks to using CD ISO images in this fashion. For
instance, no one directory contains the entire distribution of RPM
packages. Soft links circumvent this problem, but your server security
policies may not permit them. &FC; also comes in a ISO format DVD image,
which alleviates this problem. Users who do not have DVD burning
hardware, however, cannot use this image to make discs for their own
use.
</para>
</section>
<section id="sn-trimming-tree">
<title>Trimming Branches</title>
<para>
You may omit almost any branch of the tree that you do not plan to use.
Consider carefully the impact of excluding that folder. Branches you
might trim from your mirror include:
</para>
<variablelist>
<varlistentry>
<term>Older versions of &FC; (any numbered directory).</term>
<listitem>
<para>
Before you exclude an old version, ensure this does not adversely
affect any of your users. These adverse affects can come in many
forms. For example, the level of support for certain hardware
sometimes changes between releases of &FC;. Users who cannot
install a previous version may not be able to use &FC;. Your users
might need to perform software-related tasks such as building
packages for different &FC; releases. Always remain aware of the
needs of your users during the planning stage.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Folders for architectures your site does not support.</term>
<listitem>
<para>
If you do not have any x86-64 hosts to support, trimming these
folders eliminates several gigabytes of extra files. If you
support x86-64 hosts later, though, you must restore mirroring of
these branches.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>The <filename>development</filename> folder (formerly
<filename>rawhide</filename>).</term>
<listitem>
<para>
This folder contains all the latest bleeding-edge packages from
the &FP;. If you participate in active &FED; development, you
should not trim this branch. &FED; development moves at a rapid
pace and requires frequent updates to the latest development
package versions. However, the frequent updates cause your mirror
to download significant amounts of material during the regular
update cycle.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>The <filename>testing</filename> folders.</term>
<listitem>
<para>
These branches contain updates that are being subjected to quality
assurance through public testing, as well as the test or
<firstterm>pre-release</firstterm> versions of the &FC;
distribution. The <filename>testing</filename> folder under the
main <filename>core</filename> tree is where test versions of the
distribution, such as &FC; &FCTESTVER;, are kept. (Users of &FC;
test distributions are often directed to use the
<filename>development</filename> branch to update packages.) The
<filename>testing</filename> folder, under
<filename>updates</filename>, contains package updates that have
not yet passed the public testing phase.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>The <filename>debug</filename> folders.</term>
<listitem>
<para>
These folders contain packages that enable developers and skilled
users to interpret data created when a program crashes or
encounters a bug. If you participate actively in &FED;
development, you should not trim these folders. If you trim this
branch, you may still download individual packages on an
basis from a nearby public mirror site. <!-- removed
<foreignphrase> mainly because the stylesheet italicized it, yet
the term is neither new nor noteworthy enough to make it stand out
like that ... the usage is correct and may not even be overboard,
but the format outcome is jarring for the reader, and I'd prefer
not to have to hack the XSL to make this bigger. Maybe next time?
-->
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>The <filename>SRPMS</filename> folders (and links
thereto).</term>
<listitem>
<para>
These folders contain the original source for all the binary RPM
packages in the distribution. You may download these packages on
an ad hoc basis if you need to save space on your local mirror.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Unless your site closely manages workstation configuration, you should
probably not trim any of the <filename>updates</filename> branches for
the distributions you support. These locations contain packages handling
bug fixes, security patches, and errata updates which your users
probably want.
</para>
</section>
<section id="sn-download-files">
<title>Downloading the Files</title>
<para>
Locate a public mirror site for &FC; by referring to the main project
site's mirror page, &FDP-URL;. Once you have selected a nearby mirror
site, note what services it offers (FTP, HTTP, and/or rsync). A mirror
is usually servicing a large number of users. Choose off-peak hours,
when possible, to download a large set of files. Be aware of any
timezone differences when estimating off-peak hours.
</para>
<section id="sn-http-and-ftp-download">
<title>Download Using HTTP or FTP</title>
<para>
To download via HTTP or FTP, use the <command>wget</command> command.
<command>wget</command> recurses subdirectories automatically and
pulls down entire trees of data with a single command. If you are not
careful, however, it is possible to pull down much more data than you
intended. The following commands mirror the entire current &FC;
distribution:
</para>
<screen>
<userinput>cd /var/ftp/pub/mirror
wget --mirror -np -nH --cut-dirs=<replaceable>2</replaceable> http://mirror.example.com/pub/mirror/fedora/linux/core/&FCVER;/</userinput>
</screen>
<para>
Note the options used above:
</para>
<itemizedlist>
<listitem>
<para>
<option>--mirror</option> turns on recursion (descends into all
subdirectories), and duplicates file timestamps;
</para>
</listitem>
<listitem>
<para>
<option>-np</option> prevents <command>wget</command> from
ascending into the parent directory;
</para>
</listitem>
<listitem>
<para>
<option>-nH</option> prevents <command>wget</command> from
writing a directory named after the host (in this case,
<filename><replaceable>mirror.example.com</replaceable></filename>);
</para>
</listitem>
<listitem>
<para>
<option>--cut-dirs=<replaceable>n</replaceable></option>
truncates the first <replaceable>n</replaceable> directories in
the path. In the example above, <command>--cut-dirs=2</command>
prevents <command>wget</command> from writing the
<filename><replaceable>/pub/mirror</replaceable></filename>
portion of the path into your mirror.
</para>
</listitem>
</itemizedlist>
<para>
The same syntax works for both HTTP and FTP mirrors. It is possible
that you may download some extraneous files if the HTTP site formats
its pages for browser viewing. These files can be safely deleted, but
return each time the mirror updates unless you exclude them using
special options. See the <command>wget</command> man pages for more
information.
</para>
</section>
<section id="sn-rsync">
<title>The <command>rsync</command> Command</title>
<para>
Use the <command>rsync</command> command to synchronize a set of files
and/or directories with a remote host. It operates in much the same
way as <command>rcp</command>, but it is usually faster. One reason
for the speed is that <command>rsync</command> has a special protocol
that evaluates and skips files (or portions of files) that are already
downloaded.
</para>
<para>
Begin by identifying the modules available on the upstream mirror site
you have chosen. Note that the double colon
<computeroutput>::</computeroutput> is always used after the host name
to separate it from the rest of the <command>rsync</command> path. The
following command generates a list of <firstterm>modules</firstterm>
on the upstream mirror.
</para>
<screen>
<userinput>rsync mirror.example.org::</userinput>
</screen>
<para>
These modules are roughly equivalent to top-level directories, and
they follow the same rules. To list any subdirectory of the upstream
mirror, add the directory path to the command above. For example, on
many mirrors, the <filename>fedora-linux-core</filename> module is
equivalent to the <filename>fedora/linux/core</filename> path found at
the &FP; main download server. To list the contents of the &FC;
&FCVER; distribution folder on the upstream server, issue the
following command. Do not forget the trailing slash
<computeroutput>/</computeroutput>. Without it, you only receive a
listing of a folder name that matches the last component of the remote
path.
</para>
<screen>
<userinput>rsync mirror.example.org::fedora-linux-core/&FCVER;/</userinput>
</screen>
</section>
<section id="sn-rsync-download">
<title>Downloading Using <command>rsync</command></title>
<para>
To download via <command>rsync</command>, add a destination path on
your system to the end of the command line. The resulting tree of
files from the listing you perform are downloaded to the local path
you specify. Remember, if you leave off the trailing slash on the
remote path, then the last component of that path is created as a new
folder inside the target directory, and its contents are copied.
</para>
<screen>
<userinput>rsync filehouse.example.org::files/misc/ /var/ftp/pub/misc/</userinput>
</screen>
<para>
When downloading using <command>rsync</command> for mirror purposes,
use some of the command line switches to improve performance and
feedback. The switches <option>-PHav</option> enable the following
<command>rsync</command> features:
</para>
<itemizedlist>
<listitem>
<para>
<command>-P</command> — recover partially-downloaded files,
and show a progress meter
</para>
</listitem>
<listitem>
<para>
<command>-H</command> — preserve hard links
</para>
</listitem>
<listitem>
<para>
<command>-a</command> — recurse all directories, and preserve
as much file information as possible, including timestamps,
ownership, permissions, device files (if you are running as root),
and soft links
</para>
</listitem>
<listitem>
<para>
<command>-v</command> — give verbose feedback to the screen
</para>
</listitem>
</itemizedlist>
<para>
Remove the <command>-v</command> switch if you run this mirroring
process as part of a script, or have no need to monitor progress. The
following example mirrors all available versions of &FC; from an
upstream site.
</para>
<caution>
<title>Example command downloads many gigabytes of files</title>
<para>
This command downloads many gigabytes of files, and is intended for
use as an example only. Do not run this command if you do not
understand the consequences.
</para>
</caution>
<screen>
<userinput>rsync -PHav mirror.example.org::fedora-linux-core/&FCVER;/ /var/ftp/pub/mirror/fedora/core/&FCVER;</userinput>
</screen>
<para id="rsync-n-switch">
The <command>-n</command> switch performs a <quote>dry run</quote>
using the other given parameters. Use this switch to test any
<command>rsync</command> command if you are unsure what files you will
receive. See also <xref
linkend="rsync-possible-data-loss"/>.
</para>
<para>
The <command>-z</command> switch enables compression during the
<command>rsync</command> process. The server compresses data before
transmission, and the client decompresses the data before writing it
to disk.
</para>
<tip>
<title>Compression using <command>rsync</command></title>
<para>
The vast majority of the &FC; distribution consists of RPM files,
which are already compressed data. Therefore, additional compression
does not save time, and instead induces an unnecessary load on the
upstream mirror CPU. As a courtesy, do not use the
<command>-z</command> switch for this purpose.
</para>
</tip>
<para>
The next section features some additional switches that can be used to
automatically trim branches from the tree of downloaded folders. With
proper usage, they result in a mirror that is exactly as organized and
full-featured as any high-volume public upstream site.
</para>
<warning id="rsync-possible-data-loss">
<title>Possible data loss</title>
<para>
If you are not exceedingly careful in using these switches, it is
possible to delete large portions of your mirrored data. Fixing this
problem might simply require performing the copying steps outlined
in <xref linkend="sn-copying-original-distribution"/> above. On the
other hand, if you are also careless about your destination path,
and you are running as root, you could put your entire system at
risk. Know your environment before using these switches:
</para>
<itemizedlist>
<listitem>
<para>
What is your current working directory? Use
<command>pwd</command> to find out, if you are unsure.
</para>
</listitem>
<listitem>
<para>
Are you logged in as root? If you are using SELinux extensions,
what is your current security context?
</para>
</listitem>
<listitem>
<para>
Have you tested this command using the <command>-n</command>
switch (see <xref linkend="rsync-n-switch"/>)?
</para>
</listitem>
</itemizedlist>
</warning>
<para>
Use the <command>--exclude</command> switch, along with a simple
pattern, to disallow download of certain files and/or folders. For
instance, <command>--exclude "*.iso"</command> excludes the download
of any file that has the string <quote>x86_64</quote> in its filename.
</para>
<para>
Use the <command>--delete</command> switch, again with a pattern, to
remove any file from the local system which does not have a match on
the upstream mirror. This switch prevents unwanted <firstterm>file
debris</firstterm> from cropping up in your mirror. You can also use
it to retroactively trim branches of the tree which you no longer wish
to maintain or download.
</para>
<para>
Wildcards are permitted with <command>rsync</command> commands,
including the asterisk <computeroutput>*</computeroutput>, question
mark <computeroutput>?</computeroutput>, and brackets
<computeroutput>[ ]</computeroutput>. The question mark and brackets
work as in the shell; the former matches any single character, while
the brackets define a set of characters to be matched. Asterisks are
especially powerful when combined with a portion of a file name. The
double asterisk <computeroutput>**</computeroutput> pattern matches
any character, <emphasis>including slashes</emphasis>; a single
asterisk <computeroutput>*</computeroutput> matches any character, but
stops at a slash. Therefore, be judicious about using either. The
double asterisk is very useful for mirroring a tree that includes
multiple instances of directories and files that contain a pattern. A
good example is mirroring several versions of &FC;, where certain
folder names appear in every version.
</para>
<tip>
<title>Pattern matching wildcards</title>
<para>
Use double asterisks to trim out directories that repeat throughout
a mirrored tree. For example, when mirroring for a site that
only uses i386 architecture machines, you may trim all files and
folders marked for x86_64 architecture, using the switch
<command>--exclude "**x86_64**"</command>. This matches not only
folders marked <filename>x86_64</filename>, but also files such as
ISO images for x86_64, which are indicated by file names such as
<filename>FC&FCVER;-x86_64-disc1.iso</filename>.
</para>
</tip>
<para>
Process a long list of exclusions and deletions with the
<command>--exclude-from</command> and <command>--delete-from</command>
options. Follow each tag with a file name that includes a list of
patterns, one per line, to be matched by the appropriate option.
</para>
<para>
These syntax hints only scratch the surface of
<command>rsync</command>, but suffice to make your first mirror. Once
you have selected your site and formulated your excludes and deletes,
run your <command>rsync</command> command with the
<command>-n</command> option. Redirect output to a file so you can
examine the resulting list of files in the editor or pager of your
choice.
</para>
<para>
The following example mirrors the entire &FC; &FCVER; distribution,
with <command>--exclude</command> options that avoid downloading:
</para>
<itemizedlist>
<listitem>
<para>
Any information for x86_64 architecture;
</para>
</listitem>
<listitem>
<para>
Any <command>yum</command> headers (see <xref
linkend="sn-repositories"/>);
</para>
</listitem>
<listitem>
<para>
Any <filename>debuginfo</filename> packages; and,
</para>
</listitem>
<listitem>
<para>
CD or DVD images.
</para>
</listitem>
</itemizedlist>
<para>
The <command>-n</command> switch is included for testing purposes.
Backslashes at the ends of lines indicate this example is a single
command line.
</para>
<screen>
<userinput>rsync -Pan --delete --exclude "**x86_64**" --exclude "**headers**" \
--exclude "**debug**" --exclude "**iso**" \
mirror.example.com::fedora-linux-core/&FCVER;/ \
/var/ftp/pub/mirror/fedora/core/&FCVER;</userinput>
</screen>
</section>
</section>
<section id="sn-maintenance">
<title>Maintaining Your Mirror</title>
<para>
&FED; mirrors are even more useful when they are more than just a
snapshot of the distribution at release time. Most mirror administrators
also choose to carry updates and errata packages. Repositories of
updates or development trees change daily, and your mirror should
reflect these changes.
</para>
<important>
<title><command>rsync</command> etiquette</title>
<para>
If you plan to do regular updates of your mirror that include large
amounts of data, you should ask permission from the administrator of
the upstream mirror. Downloading nightly package updates for the
official releases of &FC; &FCVER; should not require notification, as
they are rarely more than a few megabytes. However, the
<filename>development</filename> tree routinely turns over several
hundred megabytes nightly. Take these factors into consideration
before putting any maintenance scripts into effect.
</para>
</important>
<para>
Once your <command>rsync</command> command is working as desire, you may
want to place it in a nightly <command>cron</command> script. The
<command>cron</command> system allows you to schedule
regularly-occurring jobs on your system. The intervals are highly
configurable, but a nightly run keeps your mirror synchronized with
updates and errata. Make sure your nightly <command>cron</command> job
follows some simple guidelines:
</para>
<itemizedlist>
<listitem>
<para>
If your upstream mirror only synchronizes once or twice daily, run
your job <emphasis>after</emphasis> the upstream mirror completes
its update. This insures your mirror not only gets the freshest
material, but also does not interfere with the upstream server's
bandwidth while it runs its job. If you do not know this time, it is
usually safe to plan your downloads for pre-dawn hours.
</para>
</listitem>
<listitem>
<para>
Be sure you have sufficient disk space for additional packages. The
<filename>updates</filename> tree in particular grows over time as
more errata packages are released.
</para>
</listitem>
<listitem>
<para>
Always test your script thoroughly before allowing it to run
automatically. Use a <command>-n</command> or <command>-v</command>
switch in the <command>rsync</command> command line for testing, and
then remove it once you have completed testing. Remember that the
results are e-mailed to your account on your system unless you
specify differently. Read the <command>crontab(5)</command> man
pages for additional information, with the command <command>man 5
crontab</command>.
</para>
</listitem>
</itemizedlist>
</section>
</section>
<section id="sn-server-config">
<title>Server Configuration Planning</title>
<para>
Decide what services your mirror will offer to clients. There are at least
three services useful for providing &FED; installation and update
services: HTTP, FTP, and NFS. Some or all of these services can be used
for offering post-installation functions such as updates or installing
additional packages.
</para>
<para>
Install the <filename>vsftpd</filename> package for FTP services. Install
the <filename>httpd</filename> package to use the Apache HTTP server. Most
&FC; systems already have the <command>nfs-utils</command> package
installed, which contains the NFS server.
</para>
<para>
To start a service, use the <command>/sbin/service
<replaceable>service</replaceable> start</command> command. To enable that
server by default at boot time, use the <command>chkconfig
<replaceable>service</replaceable> on</command> command.
</para>
<para>
One recommended method is to download all mirrored files into
<filename>/var/ftp/pub</filename>, add a link in
<filename>/var/www/html</filename> that points to
<filename>/var/ftp/pub</filename>, and share out
<filename>/var/ftp/pub</filename> via NFS as well. FTP and HTTP services
do not require any further configuration to work properly.
<emphasis>However, you should evaluate your site's security needs before
enabling them.</emphasis> NFS service configuration is explained below
in <xref linkend="sn-nfs-config"/>.
</para>
<para>
To share out the public FTP area via HTTP, issue the following
command:
</para>
<screen>
<userinput>ln -s /var/ftp/pub /var/www/html/pub</userinput>
</screen>
<para>
Your clients may now visit any area of your mirror by using the URL
<replaceable>http://server.mydomain.org/pub/path</replaceable>. To create
an NFS share, add a line to <filename>/etc/exports</filename>. This
example shares out the &FC; &FCVER; i386 stock distribution with read-only
access for any host in the <computeroutput>mydomain.org</computeroutput>
domain.
</para>
<screen>
<userinput>/var/ftp/pub/linux/fedora/core/&FCVER;/i386/os *.mydomain.org(ro,sync,root_squash)</userinput>
</screen>
<para>
To reread the NFS server configuration files and export the new share, use
the following command:
</para>
<screen>
<userinput>exportfs -ar</userinput>
</screen>
<para>
Refer to <xref linkend="sn-nfs-config"/> for a list of commands for
starting services both on demand and at boot time.
</para>
<section id="sn-solving-dependencies">
<title>How to Solve Dependencies</title>
<para>
Every RPM package has a <emphasis>header</emphasis> that contains all
the vital information about that package. This information includes
name, version and release, contents, the capabilities provided by the
package, and any prerequisites. These prerequisites may include
<emphasis>dependencies</emphasis><indexterm>
<primary>dependencies</primary>
</indexterm>. A dependency is a requirement for one or more additional
packages.
</para>
<para>
Packages installed without satisfying their dependencies may not work
correctly. Dependencies may create a problem for users who are trying to
install a single package. Manually determining and resolving
dependencies is difficult. &FC; has several methods for solving these
dependencies automatically, providing an improved user experience.
</para>
<section id="sn-rhn-history">
<title>Red Hat Network</title>
<para>
<emphasis>Red Hat Network</emphasis><indexterm>
<primary>Red Hat Network</primary>
</indexterm>, or <emphasis>RHN</emphasis><indexterm>
<primary>RHN</primary>
<see>Red Hat Network</see>
</indexterm>, is a systems management and deployment tool that was
introduced in Red Hat Linux, and continues to be used with Red Hat
Enterprise Linux. RHN makes updates available to registered users, and
allows them to remotely schedule and manage their systems using a
single Web-based console. The client systems run the
<application>up2date</application> application to communicate with
RHN.
</para>
<para>
Although &FC; systems do not inter-operate with RHN, they still include
an <application>up2date</application> client. This client is
enhanced to support non-RHN update services. These services, like RHN,
solve RPM package dependencies automatically.
</para>
</section>
<section id="sn-yum">
<title><command>yum</command></title>
<para>
The Yellow Dog Updater Modified, or
<emphasis>yum</emphasis><indexterm>
<primary>yum</primary>
</indexterm>, is a Python-based system for computing and solving RPM
dependencies. A <command>yum</command> client retrieves a cache of
headers from its repository server, as well as a list of available RPM
packages and their exact locations on the server. It can do this via
HTTP or FTP, as well as using standard file system calls (either local
or remote via NFS). The client computes solutions to any package
dependencies using the downloaded header information, and simply
requests all necessary RPM packages once it has finished. The
<command>yum</command> command relies on <command>rpm</command> to
perform all computation involved in the process.
</para>
<para>
A drawback to <command>yum</command> is that the first time it is run,
it must download a header for every package installed on the system in
order to determine available updates. However, running a local mirror
nullifies this drawback. The <command>yum</command> command can, of
course, download many megabytes of headers almost instantly on a
standard Ethernet LAN. <command>yum</command> is the most popular
update method for &FC;.
</para>
</section>
</section>
<section id="sn-repositories">
<title>Configuring Repositories</title>
<para>
A <command>yum</command> <emphasis>repository</emphasis><indexterm>
<primary>repository</primary>
<secondary>yum</secondary>
</indexterm> is a collection of packages on a server which supports
<command>yum</command> clients. Repositories can serve both types of
clients if desired.
</para>
<para>
To set up a <command>yum</command> repository, you must write a
directory of header information from which the clients pull the data
they require. The directory is named <filename>headers</filename>. It is
created by using the command <command>yum-arch</command>, which is run
against the directory <emphasis>under which</emphasis> you want the
<filename>headers</filename> directory to appear. The
<command>yum-arch</command> program searches recursively through that
directory and any subdirectories for RPM packages, and includes them in
the header data.
</para>
<screen>
<userinput>yum-arch -l -s /var/ftp/pub/linux/fedora/core/&FCVER;/i386/os</userinput>
</screen>
<para>
The <command>-l</command> switch follows symbolic links. This is useful
in the first case below. The <command>-s</command> switch includes SRPMS
(source RPM packages) in the header list. The command above creates the
<command>yum</command> header cache in the directory
<filename>/var/ftp/pub/linux/fedora/core/&FCVER;/i386/os/headers</filename>.
Typically <command>yum-arch</command> is run against at least the
following locations:
</para>
<itemizedlist>
<listitem>
<para>
The stock distribution; for example,
<filename>/var/ftp/pub/linux/fedora/core/&FCVER;/i386/os/</filename>.
Use the <command>-l</command> and <command>-s</command> options to
follow the linked directory <filename>SRPMS</filename> and include
the source packages therein.
</para>
</listitem>
<listitem>
<para>
Official updates to the distribution; for example,
<filename>/var/ftp/pub/linux/fedora/core/updates/&FCVER;/</filename>.
Once again use <command>-l</command> and/or <command>-s</command> if
appropriate.
</para>
</listitem>
</itemizedlist>
</section>
<section id="sn-nfs-config">
<title>Configuring NFS</title>
<para>
Some client-side utilities also resolve dependencies automatically.
These utilities require more detailed configuration of the client
workstation. For more information, see <xref
linkend="sn-client-config"/> below. These utilities, however, require
standard file system access to package collections. For this reason, you
may require NFS on your mirror. Configuration of the client depends
in large part on how you decide to implement NFS sharing on the mirror.
</para>
<para>
It is difficult to share subdirectories of other shared directories.
Therefore, think of your mirror as offering many services, each one to
be considered for NFS sharing. For example, share both the stock
distribution of &FC; 2 and the stock distribution of &FC; 3.
</para>
<para>
The client side tools discussed later can use a directory of ISO images
or an exploded tree of package data (see <xref
linkend="sn-copying-original-distribution"/>). You may share out any or
all of these, provided your shares do not clash as described above.
</para>
<!--
FIXME: Can system-config-packages use a directory of loopback-mounted
images like FTP/HTTP installs in anaconda? See additional FIXME below.
-->
<para>
To share via NFS, edit the <filename>/etc/exports</filename> file. A
typical share, exported with read-only access for any host on any
network, looks like this:
</para>
<screen>
<computeroutput>/mnt/media *(ro,all_squash,async)</computeroutput>
</screen>
<para>
The <command>all_squash</command> option ensures that no users accessing
the share using their local root account receive equivalent access on
the share. This feature keeps some small measure of security even on a
public share, since a file readable only by root on the server is not
readable by an NFS client. The <command>async</command> option allows
asynchronous read/writes, which is not dangerous in this case because
the share is read-only. The <command>*</command> is a host designator,
in this case matching any host name or IP address. You may wish to
restrict this share to your internal network. You may declare either a
matching name or IP address specification. You can find more detailed
information by reading the man pages for the
<filename>/etc/exports</filename> file by using the command <command>man
5 exports</command>.
</para>
<important>
<title>Access control format</title>
<para>
Be certain that you do not have a space between the host specification
and the option listing in parentheses <computeroutput>(
)</computeroutput>. A space causes the NFS daemon to consider that
entry as <emphasis>two separate access controls</emphasis>. In the
example above, a space causes the first access control to match all
hosts and allow write access, which is the default! The second access
control is never reached because the first matches any host first.
</para>
</important>
<para>
To share the proper directories from your mirror, use one of the
following forms. To share your exploded tree, export the directory that
contains the &FED; folder (note the capitalization). For i386
architectures:
</para>
<screen>
<userinput>/var/ftp/pub/linux/fedora/core/&FCVER;/i386/os *(ro,all_squash,async)</userinput>
</screen>
<para>
To share a directory full of ISO images, export that directory:
</para>
<screen>
<userinput>/var/ftp/pub/linux/fedora/core/&FCVER;/i386/iso *(ro,all_squash,async)</userinput>
</screen>
<!--
FIXME: Find out if this works first.
<para>
To share a directory full of <emphasis>mounted</emphasis> ISO images,
export that directory. Do not share each mount point separately. The
mount points should be named <filename>disc1</filename>,
<filename>disc2</filename>, and so forth:
</para>
<screen>
<userinput>/var/ftp/pub/linux/fedora/core/&FCVER;/i386/mounts *(ro,all_squash,async)</userinput>
</screen>
-->
<para>
Once you have edited the <filename>/etc/exports</filename> file, make
sure that the NFS server is installed and started properly on the
mirror. The <filename>portmap</filename> and
<filename>nfs-utils</filename> packages must be installed. Configure
them to be turned on at boot time by default.
</para>
<screen>
<userinput>/sbin/chkconfig portmap on
/sbin/chkconfig nfslock on
/sbin/chkconfig nfs on</userinput>
</screen>
<para>
To check if any of these services are currently running, use the
<command>/sbin/service <replaceable>service_name</replaceable>
status</command> command:
</para>
<screen>
<userinput>/sbin/service portmap status
/sbin/service nfslock status
/sbin/service nfs status</userinput>
</screen>
<para>
To restart a service, use the <command>/sbin/service
<replaceable>service_name</replaceable> restart</command> command:
</para>
<screen>
<userinput>/sbin/service portmap restart
/sbin/service nfslock restart
/sbin/service nfs restart</userinput>
</screen>
<para>
If any service is not started, use the command <command>/sbin/service
<replaceable>service_name</replaceable> start</command> to start it, as
in the following examples:
</para>
<screen>
<userinput>/sbin/service portmap start
/sbin/service nfslock start
/sbin/service nfs start</userinput>
</screen>
<para>
To change your exports when the NFS service is already running, use the
command <command>/usr/sbin/exportfs -ar</command>. The command
<command>/usr/sbin/showmount -e</command> displays a list of the
current NFS exports on the local host machine.
</para>
</section>
</section>
<section id="sn-client-config">
<title>Client Configuration</title>
<para>
You must also correctly configure the client workstations that use your
mirror. Using the mirror as a source for RPM packages, clients may have
seamless access for installing basic software through
<application>system-config-packages</application>, solving RPM package
installations at the command line, and pulling bug fix and security errata
updates.
</para>
<section id="sn-system-config-packages">
<title>Configuring <application>system-config-packages</application></title>
<para>
Users typically run the
<application>system-config-packages</application> application from the
GUI menu, by choosing <guimenu>System Settings</guimenu>,
<guimenuitem>Add/Remove Applications</guimenuitem>. This program allows
the user to change the stock installation, provided no updates have
taken place yet that interfere.
</para>
<para>
Often, <application>system-config-packages</application> stops
functioning optimally after certain updates are installed. This is
because <application>system-config-packages</application> solves
dependencies based on the stock distribution. It is impossible for
<application>system-config-packages</application> to predict version
numbers of updates. If you intend to carry updates on your mirror, you
should be aware that installing certain updates causes
<application>system-config-packages</application> to lose its
effectiveness. Some sites do not mirror all updates due to configuration
management concerns. The guidance in this section is especially useful
in those scenarios.
</para>
<tip id="tp-s-c-p-stock-only">
<title><application>up2date</application> and
<application>system-config-packages</application></title>
<para>
If you plan to carry updates on your mirror, as most administrators
do, you will probably not use
<application>system-config-packages</application> much. Once the
installed package versions become out of sync with the stock
distribution versions, <application>up2date</application> becomes much
more useful. The preferred method for installing a package in that
case would be <command>up2date --install
<replaceable>package_name</replaceable></command>. See <xref
linkend="sn-up2date"/> for more information.
</para>
</tip>
<section id="sn-autofs">
<title>Setting Up <command>autofs</command></title>
<para>
The <command>autofs</command><indexterm>
<primary>autofs</primary>
</indexterm> facility allows a &FC; system to mount file systems on
demand. The <filename>/etc/auto.master</filename> file contains an
<emphasis>automounter map</emphasis><indexterm>
<primary>automounter map</primary>
</indexterm>
<indexterm>
<primary>map</primary>
<secondary>automounter</secondary>
<see>automounter map</see>
</indexterm>. On &FC;, the automounter map is a list of additional
definition files that should be loaded, one for each directory in the
map. An example line from <filename>/etc/auto.master</filename> is
shown below:
</para>
<screen>
<computeroutput>/misc /etc/auto.misc --timeout=60</computeroutput>
</screen>
<para>
The first term in the line is the directory which is reserved for
automounting. The second term is the automount file which should be
consulted to determine any maps for that directory. The third term in
the example indicates that if a map under /misc is not busy for 60
seconds, it is unmounted.
</para>
<para>
The <filename>/etc/auto.misc</filename> file contains entries similar
to the following example.
</para>
<screen>
<computeroutput>remote -ro,soft,intr host.foobar.org:/pub</computeroutput>
</screen>
<para>
This line is contained in the automounter map file for the
<filename>/misc</filename> directory. The first term is a key which is
the name of a directory that appears upon demand. The second term is
actually a list of options, identical to those that would be used for
a real <command>mount</command> command. The final term is the file
system (local or remote) to mount. In the above example, if the user
of this station accesses the directory
<filename>/misc/remote</filename>, an NFS mount is automatically
performed. The user's command appears to hesitate, depending on how
fast the NFS server responds. Then <filename>/misc/remote</filename>
appears to be full of whatever content is on host.foobar.org in the
<filename>/pub</filename> NFS share.
</para>
<para>
You can use this function to provide NFS access to the stock
distribution for &FC;. Choose a directory to map in the
<filename>/etc/auto.master</filename> file, and match it to a
corresponding automounter map file. The easiest way to do this is to
simply remove the comment <computeroutput>#</computeroutput> from the
front of the line attaching <filename>/misc</filename> to
<filename>/etc/auto.misc</filename>. The default timeout should be
sufficient.
</para>
<para>
Make an entry in <filename>/etc/auto.misc</filename> similar to
this. You can have multiple entries, each one with a different
key. For instance, each key could be mapped to a different version of
&FC; that you have available on the local mirror.
</para>
<screen>
<userinput>fc&FCVER; -ro,soft,intr mirror.mydomain.org:/var/ftp/pub/linux/fedora/core/&FCVER;</userinput>
</screen>
<para>
Now restart the <command>autofs</command> service:
</para>
<screen>
<userinput>/sbin/service autofs restart</userinput>
</screen>
<para>
To access the stock distribution for &FC; &FCVER; the user can simply
type <command>cd /misc/fc&FCVER;</command>. The share is automatically
mounted and the files simply appear in that local directory.
</para>
</section>
<section id="sn-shared-desktop-s-c-p">
<title><filename>/usr/share/applications/system-config-packages</filename></title>
<para>
Now that <command>autofs</command> has been configured, your client
workstations need to be configured so that
<application>system-config-packages</application> points to the
mirror's NFS share. Edit the
<filename>/usr/share/applications/system-config-packages</filename>
file's <command>Exec=</command> line to add a switch pointing to the
share:
</para>
<screen>
<userinput>Exec=/usr/bin/system-config-packages --tree=/misc/fc&FCVER;/i386/os</userinput>
</screen>
<para>
When users choose <guimenu>System Settings</guimenu>,
<guimenuitem>Add/Remove Applications</guimenuitem> from the GUI main
menu, the system now automatically resolves package dependencies from
the mirror. The restrictions stated above in <xref
linkend="tp-s-c-p-stock-only"/> apply.
</para>
</section>
<section id="sn-rpm-aid">
<title>The <command>rpm --aid</command> Switch</title>
<para>
The <command>--aid</command> switch for the <command>rpm</command>
command also automatically solves dependencies. It performs this
function based on the <filename>rpmdb-fedora</filename> package. That
package is a preset database for a system that has every RPM package
in the &FC; distribution installed. Even if a system does not
<emphasis>itself</emphasis> have every package installed, it can
consult the <filename>rpmdb-fedora</filename> package database to see
what such a system <emphasis>would</emphasis> look like. By using the
<command>--aid</command> switch, clients can issue a single
<command>rpm --install --aid</command> command against an original
&FC; package, and have all dependencies automatically installed as
well.
</para>
<para>
Two steps are required for this process. First, install the
<filename>rpmdb-fedora</filename> package:
</para>
<screen>
<userinput>rpm --install /misc/fc&FCVER;/i386/os/&FED;/RPMS/rpmdb-fedora-*.rpm</userinput>
</screen>
<para>
Then, edit the file <filename>/etc/rpm/macros.solve</filename>, which
is part of the <filename>rpmdb-fedora</filename> package. Change the
following lines to enable package resolution:
</para>
<screen>
<computeroutput>%_solve_pkgsdir /misc/fc&FCVER;/i386/os/&FED;/RPMS/
%_solve_name_fmt %{?_solve_pkgsdir}%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm</computeroutput>
</screen>
<para>
Users now issue a single command to install any package from
the stock distribution, and all dependencies are solved for
them. For example:
</para>
<screen>
<userinput>rpm --install --aid /misc/fc&FCVER;/i386/os/&FED;/RPMS/kdeutils-*.rpm</userinput>
</screen>
<para>
If a user forgets the <command>--aid</command> switch, they
still receive hints. Normally <command>rpm</command>
displays a slightly cryptic list of capability requirements,
instead of straightforward package names. If you edit
<filename>/etc/rpm/macros.solve</filename> as shown,
<command>rpm</command> displays a list of required package
names instead.
</para>
<para>
Package dependency solutions using <command>--aid</command>
are also restricted as shown above in <xref
linkend="tp-s-c-p-stock-only"/>.
</para>
</section>
</section>
<section id="sn-up2date">
<title>Configuring <application>up2date</application></title>
<para>
The <application>up2date</application> application in &FC; now
allows use of <command>yum</command> and
<command>apt</command> repositories. The client must have a
configuration that points at the desired repositories.
</para>
<section id="sn-up2date-config">
<title><filename>/etc/sysconfig/rhn/up2date</filename></title>
<para>
The <filename>/etc/sysconfig/rhn/up2date</filename> file
controls the global configuration of the
<application>up2date</application> application. This file is
well commented and is not explained in great detail
here. Here are some points to keep in mind, however:
</para>
<itemizedlist>
<listitem>
<para>
By default, the user must intervene to update
<command>kernel</command> packages. See the
<command>pkgSkipList</command> variable. At the command
line, use the <command>-f</command> option to force an
override. At the GUI interface,
<application>up2date</application> allows the user to
override.
</para>
</listitem>
<listitem>
<para>
By default, <command>up2date</command> does not remove
old <command>kernel</command> packages. See the
<command>pkgsToInstallNotUpdate</command> variable. When
<command>up2date</command> installs a new kernel
package, the old version remains in place until removed
explicitly.
</para>
</listitem>
<listitem>
<para>
The configuration file also allows use of an HTTP proxy
if desired. A number of variables pertain to this
function.
</para>
</listitem>
<listitem>
<para>
By default, <application>up2date</application> sends
mail to <email>root at localhost</email> when packages are
updated in batch mode. (Running <command>up2date
-u</command> starts <application>up2date</application>
in batch mode.) See the <command>adminAddress</command>
option. If you support multiple clients and intend to
use batch mode at your site, you should set a new
address here.
</para>
</listitem>
</itemizedlist>
</section>
<section id="sn-up2date-sources">
<title><filename>/etc/sysconfig/rhn/sources</filename></title>
<para>
The <filename>/etc/sysconfig/rhn/sources</filename> file is used to
declare the repositories that are used with
<application>up2date</application>. A repository is declared in any of
the following ways:
</para>
<screen>
<computeroutput>apt <replaceable>label</replaceable> <replaceable>service:server</replaceable> <replaceable>path</replaceable> <replaceable>repository_name</replaceable>
yum <replaceable>label</replaceable> <replaceable>URL</replaceable>
dir <replaceable>label</replaceable> <replaceable>local_path</replaceable></computeroutput>
</screen>
<para>
For <command>apt</command> repositories,
<command>service:server</command> is the standard Internet protocol
and host name — for example, http://mirror.example.com. For
<command>yum</command> repositories, the URL points to the directory
on a server which <emphasis>contains</emphasis> the
<filename>headers</filename> folder. A <command>dir</command>
repository simply points to a folder that contains RPM packages. The
folder may contain the RPM packages in subdirectories.
</para>
<para>
The <command>yum-mirror</command> syntax points to a file that is a
list of alternative sources for the same repository:
</para>
<screen>
<computeroutput>yum-mirror <replaceable>label</replaceable> <replaceable>URL</replaceable></computeroutput>
</screen>
<para>
Edit <filename>/etc/sysconfig/rhn/sources</filename> for the clients
at your site to point to your repository. For any repository, point to
the URL for the directory containing the <filename>headers</filename>
folder. You created this folder using <command>yum-arch</command> in
<xref linkend="sn-repositories"/>. You will likely have two
repositories, one for the stock distribution and one for updates.
Examples are shown below; you may wish to point to an internal address
rather than an outward-facing server. Use a URL appropriate to your
network and Apache configuration.
</para>
<screen>
<userinput>yum fedora-core-2 http://www.mydomain.org/pub/linux/fedora/core/2/i386/os
yum fc2-updates http://www.mydomain.org/pub/linux/fedora/core/updates/2/i386</userinput>
</screen>
</section>
</section>
</section>
<!--
FIXME:
The following section is out of scope for now. When more documents are
available, this would make a great "see also" section.
<section id="sn-advanced-topics">
<title>Advanced Topics</title>
<para>
No outline here yet. Suggestions: distributing via kickstart (xref
kickstart tutorial?); rolling custom RPMs, starting with up2date; rolling
custom distro (xref RedHat-CD-HOWTO?)....
</para>
</section>
-->
<index id="generated-index">
</index>
</article>
More information about the Fedora-docs-commits
mailing list