mirror-tutorial/po zh_CN.po,NONE,1.1

Mon Apr 23 13:32:20 UTC 2007

Author: bbbush

Update of /cvs/docs/mirror-tutorial/po
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6628/po

Added Files:
	zh_CN.po 
Log Message:
update translation 11t35u

--- NEW FILE zh_CN.po ---
msgid ""
msgstr ""
"Project-Id-Version: mirror-tutorial\n"
"POT-Creation-Date: 2007-04-23 21:28+0800\n"
"PO-Revision-Date: 2007-04-23 21:31+0800\n"
"Last-Translator: Yijun Yuan <bbbush.yuan at gmail.com>\n"
"Language-Team: LANGUAGE <LL at li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: en_US/doc-entities.xml:4(title) 
msgid "Local entities for Mirror Tutorial"
msgstr "é•œåƒæ•™ç¨‹å®šä¹‰çš„å®žä½“"

#: en_US/doc-entities.xml:7(comment) 
msgid "Document name"
msgstr "æ–‡æ¡£å"

#: en_US/doc-entities.xml:8(text) 
msgid "mirror-tutorial"
msgstr "mirror-tutorial"

#: en_US/doc-entities.xml:11(comment) 
msgid "Version number"
msgstr "ç‰ˆæœ¬"

#: en_US/doc-entities.xml:12(text) 
msgid "1.0.1"
msgstr "1.0.1"

#: en_US/doc-entities.xml:15(comment) 
msgid "Date of last revision"
msgstr "æœ€è¿‘çš„ä¿®è®¢æ—¥æœŸ"

#: en_US/doc-entities.xml:16(text) 
msgid "2006-08-07"
msgstr "2006-08-07"

#: en_US/doc-entities.xml:19(comment) 
msgid "Document ID"
msgstr "æ–‡æ¡£ç¼–å· ID"

#: en_US/doc-entities.xml:20(text) 
msgid "<use entity=\"DOCNAME\"/>-<use entity=\"DOCVERSION\"/> (<use entity=\"DOCDATE\"/>)"
msgstr "<use entity=\"DOCNAME\"/>-<use entity=\"DOCVERSION\"/> (<use entity=\"DOCDATE\"/>)"

#: en_US/doc-entities.xml:26(comment) 
msgid "Local version of Fedora Core for this document"
msgstr "æœ¬æ–‡æ¡£å¯¹åº”çš„ Fedora Core ç‰ˆæœ¬"

#: en_US/doc-entities.xml:27(text) 
msgid "4"
msgstr "4"

#: en_US/doc-entities.xml:30(comment) 
msgid "URL for list of project mirrors"
msgstr ""

#: en_US/doc-entities.xml:31(text) 
msgid "<ulink url='http://fedora.redhat.com/Download/mirrors.html' />"
msgstr ""

#: en_US/rpm-info.xml:15(rights) 
msgid "OPL"
msgstr ""

#: en_US/rpm-info.xml:16(version) 
msgid "1.0"
msgstr ""

#: en_US/rpm-info.xml:19(year) 
msgid "2004"
msgstr ""

#: en_US/rpm-info.xml:20(year) 
msgid "2005"
msgstr ""

#: en_US/rpm-info.xml:21(holder) 
msgid "Paul W. Frields"
msgstr ""

#: en_US/rpm-info.xml:23(title) 
msgid "Mirror Tutorial"
msgstr ""

#: en_US/rpm-info.xml:24(desc) 
msgid "Installing and maintaining a local Fedora mirror"
msgstr ""

#: en_US/rpm-info.xml:28(details) 
msgid "Fix mirror list URL (#201558)"
msgstr ""

#: en_US/rpm-info.xml:32(details) 
msgid "Add lftp section and push to 1.0"
msgstr ""

#: en_US/rpm-info.xml:36(details) 
msgid "Minor revision updating entity names and incorporating variablelist."
msgstr ""

#: en_US/rpm-info.xml:40(details) 
msgid "Minor revision fixing service reload command."
msgstr ""

#: en_US/rpm-info.xml:44(details) 
msgid "Fixed createrepo and yum-arch command issues (#172819)."
msgstr ""

#: en_US/rpm-info.xml:48(details) 
msgid "Added some additional information about repository configuration (#172815, #172819)."
msgstr ""

#: en_US/rpm-info.xml:53(details) 
msgid "Added some security info and fixes (#169584)."
msgstr ""

#: en_US/rpm-info.xml:57(details) 
msgid "Added client configuration section."
msgstr ""

#: en_US/rpm-info.xml:61(details) 
msgid "Some style changes and more indexing."
msgstr ""

#: en_US/rpm-info.xml:65(details) 
msgid "Fix default network sharing protocol (#169581, #169584)"
msgstr ""

#: en_US/rpm-info.xml:69(details) 
msgid "Use bug reporting entity, add BETA classification."
msgstr ""

#: en_US/rpm-info.xml:73(details) 
msgid "Add entities and draft notice."
msgstr ""

#: en_US/rpm-info.xml:77(details) 
msgid "Minor note on yum versioning for repodata; fixed entities ref."
msgstr ""

#: en_US/rpm-info.xml:81(details) en_US/rpm-info.xml:85(details) 
msgid "Minor corrections."
msgstr ""

#: en_US/rpm-info.xml:89(details) 
msgid "Updated repository setup to include createrepo."
msgstr ""

#: en_US/rpm-info.xml:93(details) 
msgid "Incorporated all suggested changes by KWade."
msgstr ""

#: en_US/rpm-info.xml:97(details) 
msgid "Brought introduction section in line with Fedora Documentation Project standards."
msgstr ""

#: en_US/rpm-info.xml:101(details) 
msgid "Additional style editing."
msgstr ""

#: en_US/rpm-info.xml:105(details) 
msgid "Style editing."
msgstr ""

#: en_US/rpm-info.xml:109(details) 
msgid "Revised screen sections to use inline tags as discussed on fedora-docs-list; minor error corrections."
msgstr ""

#: en_US/rpm-info.xml:113(details) 
msgid "Initial version for editorial process."
msgstr ""

#: en_US/mirror-tutorial.xml:18(title) 
msgid "Introduction"
msgstr ""

#: en_US/mirror-tutorial.xml:20(title) 
msgid "Purpose"
msgstr ""

#: en_US/mirror-tutorial.xml:21(para) 
msgid "This tutorial presents a number of related topics that allow an administrator to seamlessly integrate mirroring and update services for Fedora. Use these services to provision a classroom, laboratory, or office. These service provisions also increase ease of use and enhance user experience. They also add to the perceived value of non-proprietary operating systems and software."
msgstr ""

#: en_US/mirror-tutorial.xml:19(section) 
msgid "<placeholder-1/><placeholder-2/>&BUG-REPORTING; Audience You will find this tutorial more useful if you are a system administrator, or a \"power user\" familiar with the following topics: system installation and administration Basic Internet protocols (HTTP/Web) Using a command line interface About Mirrors A mirror mirror 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. The site from which you retrieve files to build your mirror is called an upstream mirror mirror upstream . If possible, choose an upstream mirror that is located close to you geographically. This reduces unnecessary traffic across transcontinental section!
 s of the Internet, where bandwidth is limited and expensive. Use only upstream mirrors that are intended for public access, unless you have permission from the upstream mirror site administrator. Additional Resources For more information on installing see the at . For more information on basic Internet protocols, see http://library.albany.edu/internet/internet.html, or search Google at http://www.google.com/. For more general information about mirrors, see http://en.wikipedia.org/wiki/Mirror_(computing). Acknowledgements Karsten Wade provided editorial services and kept the style crisp and consistent. Stuart Ellis provided some additional security-related information. Planning and Setup The Distribution Structure The distribution distribution , which is the collection of all -related files, uses the directory tree in . It may include multiple versions of . The tree design makes it easier to \"trim\" unnecessary or undesired files. When you set up a mirror, duplicate this tr!
 ee exactly, or as closely as possible. If you duplicate the tr!
 ee, it
ll be easier to automate nightly updates. Fedora directory tree fedora +-- linux +-- core |-- 1 | ... +-- | +-- SRPMS | +-- i386 | | +-- debug | | +-- iso | | +-- os | | +-- Fedora | | +-- SRPMS | | +-- images | | +-- isolinux | +-- x86_64 +-- development | ... +-- test | ... +-- updates +-- 1 | ... +-- | +-- SRPMS | +-- i386 | +-- x86_64 +-- testing +-- 1 | ... +-- +-- SRPMS +-- i386 +-- x86_64 Naming conventions Throughout the rest of the document, /var/www/mirror 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 . See for more information. The site name mirror.example.com represents the upstream mirror. The fedora/linux/core//arch/os directory contains a copy of all the original distribution files for . They are the same files found on the DVD and CD-ROM version of the distribution. The subfolder contains all the files that are necessar!
 y for installation, including the entire collection of RPM packages. The images folder contains copies of any floppy diskette or CD-ROM images that boot a system into installation or rescue modes. The fedora/linux/core//arch/iso folder contains images of the CD-ROM version of the distribution. RPM packages RPM RPM , originally the Red Hat Package Manager and now the RPM Package Manager, is not just a file format. RPM is also a system that 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 http://www.rpm.org/. The SRPMS folders under architecture-specific branches are links that point to the main SRPMS folder for that distribution. For example, fedora/linux/core/2/i386/os/SRPMS is a link that points to fedora/linux/core/2/SRPMS. A mirror consists of at least the original ISO images or the distribution files. If possible, include both, provided you have!
  sufficient disk space and/or bandwidth. Copying the Original !
 Distri
ion 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 fedora/linux/core//arch/os folder. Then copy all files from the folder of each of the remaining Installation discs into the fedora/linux/core//arch/os/ folder on the server. Copy all the files from the SRPMS folder on each of the \"Sources\" discs to the fedora/linux/core//SRPMS folder on the server. Make a link in the os folder that occurs under each architecture. Follow this example: cd /var/www/mirror/fedora/linux/core//i386/os/Fedora ln ../../SRPMS SRPMS The documentation for anaconda anaconda , the installation program, calls this directory structure an exploded tree exploded tree . This is because the package data on each CD is extracted, or exploded, to a large directory tree with a predetermined structure. The anaconda installer expects !
 this structure to some extent. If you only include CD images, create a mirror suitable for installation services by mounting each CD image under the arch/os/ directory. Make a directory for each disc, naming them disc1, disc2, and so on. Mount each disc on the appropriate folder, and add entries to /etc/fstab to perform this mount automatically in case of a reboot. Each entry looks like this: /path/i386/iso/FC-i386-disc1.iso /path/i386/os/disc1 iso9660 defaults 0 0 The anaconda installer application automatically detects these folders and uses them properly. In addition, system configuration tools such as system-config-packages also continue to work properly when pointed at the parent of the ISO image mount points. 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. also comes in a ISO format DVD !
 image, which alleviates this problem. Users who do not have DV!
 D burn
 hardware, however, cannot use this image to make discs for their own use. You only need a single line in /etc/fstab for mounting the DVD ISO image. The entry looks like this: /path/i386/iso/FC-i386-DVD.iso /path/i386/os iso9660 defaults 0 0 Trimming Branches 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: Older versions of (any numbered directory). 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 . Users who cannot install a previous version may not be able to use . Your users might need to perform software-related tasks such as building packages for different releases. Always remain aware of the needs of your users during the planning stage. Folders for architectures!
  your site does not support. 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. The development folder (formerly \"Rawhide\"). This folder contains all the latest \"bleeding-edge\" packages from the . If you participate in active development, you should not trim this branch. 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. The testing folders. These branches contain updates that are being subjected to quality assurance through public testing, as well as the test or \"pre-release\" versions of the distribution. The testing folder under the main core tree is where test versions of the distribution, such as , are kept. (Users of test distributio!
 ns are often directed to use the development branch to update !
 packag
) The testing folder, under updates, contains package updates that have not yet passed the public testing phase. The debug folders. 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 development, you should not trim these folders. If you trim this branch, you may still download individual packages as needed from a nearby public mirror site. The SRPMS folders (and links thereto). These folders contain the original source for all the binary RPM packages in the distribution. You may download these packages individually as needed to save space on your local mirror. Unless your site closely manages workstation configuration, you should probably not trim any of the updates branches for the distributions you support. These locations contain packages with bug fixes, security patches, and errata updates that your users probably want. Downloading the Files Locate a!
  public mirror site for by referring to the main project site's mirror page, . 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. Download Using HTTP or FTP To download via HTTP or FTP, use either the wget or lftp command. The 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 distribution: cd /var/www/mirror wget --mirror -np -nH --cut-dirs=2 http://mirror.example.com/pub/mirror/fedora/linux/core// Note the options used above: --mirror turns on recursion (descends into all subdirectories), and duplicates file timestamps; -np prevent!
 s wget from ascending into the parent directory; -nH prevents !
 wget f
 writing a directory named after the host (in this case, mirror.example.com); --cut-dirs=n truncates the first n directories in the path. In the example above, --cut-dirs=2 prevents wget from writing the /pub/mirror portion of the path into your mirror. The same syntax works for both HTTP and FTP upstream 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 wget man pages for more information. The lftp command works like the wget command, and mirrors the content of a HTTP or FTP server. The wget command, however, does not delete old files locally. This feature is important for update repository mirrors to stay synchronized to upstream mirrors. New files are created and old files are automatically removed from the upstream mirrors on a frequent basis. The lftp command synchroniz!
 es files and directories from a remote host like rsync, but uses HTTP or FTP protocols. Use the following command to mirror the entire distribution with lftp: cd /var/www/mirror \\ lftp -c \"open http://mirror.example.com/pub/mirror/linux/core//i386/ \\ mirror --delete --verbose\" The -c parameter executes a set of commands in a lftp process. Commands are separated with to prevent the lftp command from executing if the cd command fails. The commands in the lftp command set work the same way. The command syntax A B is often shorthand for \"if A returns success, run B.\" An explanation of the lftp commands follows: open connects to the site and changes directory automatically. mirror fetches all files and directories recursively in the current directory. The --delete option excludes all local files that are not in the remote directory. The --verbose option prints some information in the screen and is optional. The lftp command above mantains an exact copy of the directory for!
  you. It downloads only new or changed files, and deletes only!
  those
at no longer exist on the upstream mirror. As with wget, it is possible you may download some unwanted files. The lftp command supports regular expressions for excluding files within a mirror command. The command below shows how to mirror an current distribution updates repository, excluding debug and repodata directories: cd /var/www/mirror \\ lftp -c \"set mirror:exclude-regex 'debug\\/|repodata\\/' \\ open http://mirror.example.com/pub/mirror/linux/core/updates//i386/ \\ mirror --delete --verbose\" Consult the lftp man pages for more details and usage options. Using Proxy for HTTP or FTP retrieval If you are behind a proxy or firewall, you may need to use a HTTP proxy to mirror files. To do this, export the environment variables http_proxy and ftp_proxy before you run the wget or lftp commands: export http_proxy=http://username:password@host:port export ftp_proxy=http://username:password@host:port The rsync Command Use the rsync command to synchronize a set of files and/o!
 r directories with a remote host. It operates in much the same way as rcp, but it is usually faster. One reason for the speed is that rsync has a special protocol that evaluates and skips files (or portions of files) that are already downloaded. Begin by identifying the modules available on the upstream mirror site you have chosen. Note that the double colon \"::\" is always used after the host name to separate it from the rest of the rsync path. The following command generates a list of \"modules\" on the upstream mirror. rsync mirror.example.org:: 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 fedora-linux-core module is equivalent to the fedora/linux/core path found at the main download server. To list the contents of the distribution folder on the upstream server, issue the following command. Do n!
 ot forget the trailing slash \"/\". Without it, you only recei!
 ve a l
ing of a folder name that matches the last component of the remote path. rsync mirror.example.org::fedora-linux-core// Downloading Using rsync To download via rsync, 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 folder, and its contents are copied. rsync filehouse.example.org::files/misc/ /var/www/misc/ When downloading using rsync for mirror purposes, use some of the command line switches to improve performance and feedback. The switches -PHav enable the following rsync features: -P recover partially-downloaded files, and show a progress meter -H preserve hard links -a recurse all directories, and preserve as much file information as possible, including timestamps, ownership, permissions, device files (if you are running as root), a!
 nd soft links -v give verbose feedback to the screen Remove the -v 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 from an upstream site. Example command downloads many gigabytes of files 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. rsync -PHav mirror.example.org::fedora-linux-core// /var/www/mirror/fedora/linux/core/ The -n switch performs a \"dry run\" using the other given parameters. Use this switch to test any rsync command if you are unsure what files you will receive. See also . The -z switch enables compression during the rsync process. The server compresses data before transmission, and the client decompresses the data before writing it to disk. Compression using rsync The vast majority of the distribution consists of RPM files, which are already c!
 ompressed data. Therefore, additional compression does not sav!
 e time
nd instead induces an unnecessary load on the upstream mirror CPU. As a courtesy, do not use the -z switch for this purpose. 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. Possible data loss 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 require performing the copying steps outlined in 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: What is your current working directory? Use pwd to find out, if you are unsure. Are you logged in as root? If you are using SELinux extensions, what is your current security cont!
 ext? Have you tested this command using the -n switch (see )? Use the --exclude switch, along with a simple pattern, to disallow download of certain files and/or folders. For instance, --exclude \"*.iso\" excludes the download of any file whose name ends with the string \".iso\". Use the --delete 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 file debris 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. Wildcards are permitted with rsync commands, including the asterisk *, question mark ?, and brackets [ ]. 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 ** pattern matches !
 any character, including slashes; a single asterisk * matches !
 any ch
cter, 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 , where certain folder names appear in every version. Pattern matching wildcards 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 --exclude \"**x86_64**\". This matches not only folders marked x86_64, but also files such as ISO images for x86_64, which are indicated by file names such as FC-x86_64-disc1.iso. Process a long list of exclusions and deletions with the --exclude-from and --delete-from options. Follow each tag with a file name that includes a list of patterns, one per line, to be matched by the appropriate option!
 . These syntax hints only scratch the surface of rsync, but suffice to make your first mirror. Once you have selected your site and formulated your excludes and deletes, run your rsync command with the -n option. Redirect output to a file so you can examine the resulting list of files in the editor or pager of your choice. The following example mirrors the entire distribution, with --exclude options that avoid downloading: Any information for x86_64 architecture; Any yum headers (see ); Any debuginfo packages; and, CD or DVD images. The -n switch is included for testing purposes. Backslashes at the ends of lines indicate this example is a single command line. rsync -Pan --delete --exclude \"**x86_64**\" --exclude \"**headers**\" \\ --exclude \"**debug**\" --exclude \"**iso**\" \\ mirror.example.com::fedora-linux-core// \\ /var/www/mirror/fedora/core/ Maintaining Your Mirror mirrors are even more useful when they are more than just a snapshot of the distribution at release t!
 ime. Most mirror administrators also choose to carry updates a!
 nd err
 packages. Repositories of updates or development trees change daily, and your mirror should reflect these changes. rsync etiquette 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 should not require notification, as they are rarely more than a few megabytes. However, the development tree routinely turns over several hundred megabytes nightly. Take these factors into consideration before putting any maintenance scripts into effect. Once your rsync command is working as desire, you may want to place it in a nightly cron script. The cron 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 cron job follows some simple guidelines: If your upstream mirror o!
 nly synchronizes once or twice daily, run your job after 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. Be sure you have sufficient disk space for additional packages. The updates tree in particular grows over time as more errata packages are released. Always test your script thoroughly before allowing it to run automatically. Use a -n or -v switch in the rsync 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 crontab(5) man pages for additional information, with the command man 5 crontab. Server Configuration This section describes how to set up a HTTP (Web) server to support installation and software ma!
 nagement applications. Installing The Apache Web Server provid!
 es the
ache server in the httpd package. The httpd package is included on systems installed with the Server installation type. You may have installed it later in order to run websites or Web applications. also offers alternative HTTP servers, which are beyond the scope of this document. To install the httpd package, if you have not already done so, use the following command: su -c 'yum install httpd' Enter the password for the root account when prompted. To start the service, use the following command: su -c '/sbin/service httpd start' Enter the password for the root account when prompted. To enable this service to load automatically at boot time, use the following command: su -c '/sbin/chkconfig --level 345 httpd on' Enter the password for the root account when prompted. The default firewall configuration for blocks access from remote systems. To enable other systems to connect to your HTTP service, use the system-config-securitylevel utility: Choose Desktop System Settings Securi!
 ty Level . Enter the password for the root account when prompted. Select WWW (HTTP) from the list of services. When prompted, select Yes to update the firewall configuration. Configuring The Apache Web Server To enable HTTP access to the files in your mirror directory, create the configuration file /etc/httpd/conf.d/mirror.conf. The following listing is an example: Apache 2.x configuration file for mirror You must use root privileges to create or copy files in the directory /etc/httpd/conf.d/. To update an active httpd service with a new configuration, use the following command: su -c '/sbin/service httpd reload' Enter the password for the root account when prompted. Your clients may now visit any area of your mirror by using the URL http://server.mydomain.org/mirror/path. Apache and The default configuration for permits Apache to use files in the /var/www/ directory. If you build your mirror in another directory, you may need to modify the policy. Solving Dependencies Ever!
 y RPM package has a RPM header header that contains all the vi!
 tal in
mation about that package. This information includes name, version and release, contents, the capabilities provided by the package, and any prerequisites. These prerequisites may include dependencies RPM dependencies . A dependency is a requirement for one or more additional packages. 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. provides the yum utility for solving these dependencies automatically, providing an improved user experience. The Yellow Dog Updater Modified, or yum yum , is a Python-based system for computing and solving RPM dependencies. A yum 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 requests all necessary RPM packages once it has finished. The yum command relies on rpm functions to perform many of the computations involved in the process. A drawback to yum 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 yum command can download many megabytes of headers almost instantly on a standard Ethernet LAN. The yum utility is the most popular update method for . For more information about using yum, refer to . Configuring Repositories A yum repository repository is a collection of packages on a server which supports yum clients. Repositories can serve both types of clients if desired. To set up a yum repository, you must write a directory that contains information which the clients require !
 to resolve RPM dependencies. The directory's name depends on t!
 he ver
n of yum it supports. It is permissible to have both kinds of repository information in a single repository. To support older yum clients, use the yum-arch command. To support current yum clients, use the createrepo command. Supporting 3 and beyond 3 ships with a newer version of yum. To support 3 yum clients, you must use createrepo on your server's repositories. yum-arch The yum-arch command creates a directory named headers/ which supports older versions of yum (before 2.2). The yum-arch program searches recursively through a target directory and any subdirectories for RPM packages, and includes them in the header data. The yum-arch command always creates the headers/ directory in the current working directory. Therefore you should change your working directory to the directory where you want headers/ to appear. cd /var/www/mirror/fedora/linux/core//i386/os su -c 'yum-arch -ls .' Enter the root password at the prompt. The -l switch follows symbolic links. The -s switch in!
 cludes SRPMS (source RPM packages) in the header list. The command above creates the yum header cache in the directory /var/www/mirror/fedora/linux/core//i386/os/headers/. createrepo The createrepo command creates repository information to support newer versions of yum (and possibly other repository client programs). The createrepo command stores this data in a folder named repodata. Run createrepo against the directory under which you want the repodata directory to appear. The createrepo program also searches recursively for RPM packages to include in the repository data. The following command creates the repository data in the directory /var/www/mirror/fedora/linux/core//i386/os/repodata. su -c 'createrepo /var/www/mirror/fedora/linux/core//i386/os' To create repository data for package groups in addition to the package files, use the createrepo -g command. The -g option requires a parameter which points to the group file, relative to the given location of the package dat!
 a. The following command creates the package group data corres!
 pondin
o the repository directly above. Note the relative location of the group file /var/www/mirror/fedora/linux/core/i386/os/Fedora/base/comps.xml. su -c 'createrepo -g Fedora/base/comps.xml /var/www/mirror/fedora/linux/core//i386/os' You may have certain clients who update their version of yum in a non-prescribed way. To minimize problems for your clients, create both kinds of repository data for any repositories. The extra repository information is relatively small and will not affect your mirror's proper function. Repository Locations Typically you will run yum-arch or createrepo against at least the following locations: The stock distribution; for example, /var/www/mirror/fedora/linux/core//i386/os/. For yum-arch, use the -l and -s options to follow the linked directory SRPMS and include the source packages therein. Official updates to the distribution; for example, /var/www/mirror/fedora/linux/core/updates//. Once again, for yum-arch use -l and/or -s if appropriate. Client C!
 onfiguration Client systems that use yum to contact your mirror also require configuration. The yum repository configuration files are located in /etc/yum.repos.d and end with the suffix .repo. Below is an example configuration file. Example /etc/yum.repos.d/fedora-mirror.repo [mirror] name=Fedora Core $releasever - $basearch - Base baseurl=http://server.mydomain.net/mirror/fedora/linux/core/$releasever/$basearch enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora Client systems should use a repository configuration file for each branch your mirror provides. The base distribution and released updates, for example, each require a separate configuration file. If you want clients to use your mirror in place of the official repositories, disable the existing repositories. To do this, edit the client's file for the official repository to include the directive enabled=0. You will need root access to edit these files. Many repositories provide their own installa!
 ble RPM packages containing these configuration files. When a !
 user i
alls the RPM, the new files in /etc/yum.repos.d/ reference that repository. These packages simplify the addition of new repositories for end users. Whether you use such a package yourself will depend on the number and skill set of clients your repository serves."
msgstr ""

#. Put one translator per line, in the form of NAME <EMAIL>, YEAR1, YEAR2.
#: en_US/mirror-tutorial.xml:0(None) 
msgid "translator-credits"
msgstr ""