mirror-tutorial - en to pt translation catalogue (34 entries)

en: Local entities for Mirror Tutorial
pt: Entidades locais do Tutorial de Replicação

en: Document name
pt: Nome do documento

en: Version number
pt: Número da versão

en: Date of last revision
pt: Data da última revisão

en: Document ID
pt: ID do Documento

en: Local version of Fedora Core for this document
pt: Versão local do Fedora Core para este documento

en: URL for list of project mirrors
pt: URL da lista de réplicas do projecto

en: Mirror Tutorial
pt: Tutorial de Replicação

en: Installing and maintaining a local Fedora mirror
pt: Instalar e manter uma réplica local do Fedora

en: Fix mirror list URL (#201558)
pt: Correcção do URL da lista de réplicas (#201558)

en: Add lftp section and push to 1.0
pt: Adição da secção do 'lftp' e mudança para o 1.0

en: Minor revision updating entity names and incorporating variablelist.
pt: Pequena revisão com actualização dos nomes das identidades e incorporação da lista de variáveis.

en: Minor revision fixing service reload command.
pt: Pequena revisão para corrigir o comando de reinício do serviço.

en: Fixed createrepo and yum-arch command issues (#172819).
pt: Correcção das questões relacionadas com o 'createrepo' e o 'yum-arch' (#172819).

en: Added some additional information about repository configuration (#172815, #172819).
pt: Adição de alguma informação sobre a configuração do repositório (#172815, #172819).

en: Added some security info and fixes (#169584).
pt: Adição de alguma informação de segurança e correcções (#169584).

en: Added client configuration section.
pt: Adição da secção de configuração do cliente.

en: Some style changes and more indexing.
pt: Algumas mudanças de estilo e mais indexação.

en: Fix default network sharing protocol (#169581, #169584)
pt: Correcção do protocolo de partilha de rede predefinido (#169581, #169584)

en: Use bug reporting entity, add BETA classification.
pt: Usar a entidade de comunicação de erros, adição da classificação BETA.

en: Add entities and draft notice.
pt: Adição de entidades e da nota de rascunho.

en: Minor note on yum versioning for repodata; fixed entities ref.
pt: Nota sobre a versão do 'yum' no 'repodata'; correcção das referências de entidades.

en: Minor corrections.
pt: Pequenas correcções.

en: Updated repository setup to include createrepo.
pt: Actualização da configuração do repositório para incluir o 'createrepo'.

en: Incorporated all suggested changes by KWade.
pt: Incorporação de todas as alterações sugeridas pelo KWade.

en: Brought introduction section in line with Fedora Documentation Project standards.
pt: Alinhamento da secção da introdução com as normas do Projecto de Documentação do Fedora.

en: Additional style editing.
pt: Edição adicional do estilo.

en: Style editing.
pt: Edição do estilo.

en: Revised screen sections to use inline tags as discussed on fedora-docs-list; minor error corrections.
pt: Revisão das secções 'screen' para usar marcas incorporadas, como discutido na fedora-docs-list; pequenas correcções de erros.

en: Initial version for editorial process.
pt: Versão inicial para o processo de edição.

en: Introduction
pt: Introdução

en: Purpose
pt: Objectivo

en: 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.
pt: Este tutorial apresenta um conjunto de tópicos relacionados, que permitem a um administrador integrar de forma transparente os serviços de replicação e actualização no Fedora. Use estes serviços, por exemplo, numa sala de aulas, laboratório ou escritório. Estas ofertas de serviços aumentam também a facilidade de utilização e melhoram a experiência do utilizador. Adicionam também alguma mais-valia aos sistemas operativos e 'software' não-proprietário.

en: <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 sections 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 tree exactly, or as closely as possible. If you duplicate the tree, it will 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 necessary 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 Distribution 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 DVD burning 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 distributions are often directed to use the development branch to update packages.) 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 prevents wget from ascending into the parent directory; -nH prevents wget from 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 synchronizes 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 that 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/or 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 not forget the trailing slash "/". Without it, you only receive a listing 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), and 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 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 -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 context? 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 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 , 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 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. 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 only 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 management applications. Installing The Apache Web Server provides the Apache 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 Security 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 Every RPM package has a RPM header header 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 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 the version 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 includes 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 data. The following command creates the package group data corresponding to 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 Configuration 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 installable RPM packages containing these configuration files. When a user installs 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.
pt:  &nbsp;.
