# Yum Repositories ## Introduction [Yum or "Yellowdog Updater, Modified"](http://yum.baseurl.org/) is a command line package management utility for Linux distributions using the RPM package manager. It allows you to easily install many commonly used Linux packages on distributions such as RedHat, CentOS, and Fedora. **Note** We do not currently support upgrading Yum repositories on Nexus Repository version 2 to Nexus Repository version 3. Nexus Repository does not support new Yum v4 features. ## Proxying Yum Repositories You can set up a Yum proxy repository to access a remote repository location. To proxy a Yum repository, you simply create a new _yum (proxy)_ as documented in [Repository Management](https://help.sonatype.com/en/repository-management.html "Repository Management"). Minimal configuration steps are as follows: - Define _Name_ (e.g., `yum-proxy`) - Define URL for _Remote storage_ (e.g., `http://mirror.centos.org/centos/`) - Pick a _Blob store_ for _Storage_ **Note** Nexus Repository does not create a default Yum proxy repository. You will need to determine which repositories are appropriate for your environment. See [Proxying RHEL Yum Repositories](https://help.sonatype.com/en/proxying-rhel-yum-repositories.html "Proxying RHEL Yum Repositories") for instructions on proxying Red Hat Enterprise Linux Yum repositories. Also, see [GPG signatures for Yum Proxy/Group](https://help.sonatype.com/en/gpg-signatures-for-yum-proxy-group.html "GPG signatures for Yum") for signing data with a GPG key. ## Hosting Yum Repositories A hosted repository for Yum can be used to upload both your own and third-party RPMs. To host a Yum RPM, create a new _yum (hosted)_ repository as documented in [Repository Management](https://help.sonatype.com/en/repository-management.html "Repository Management"). Minimal configuration steps for creating a Yum Hosted repository are as follows: - Define _Name_ e.g., `yum-hosted` - Select a value for _Repodata Depth_ - Pick a _Blob store_ for _Storage_ ### Repodata Depth When creating a hosted Yum repository, you'll need to pick a _Repodata Depth_. This sets the level at which the _repodata_metadata folder will be created as well as the expected minimum folder depth at which the RPMs can exist in order to match. Nexus Repository will reject RPMs with less depth. For example, if your package is created at `/games/lol/ashe.rpm,` then the _Repodata Depth_ would be "2." When pushing the RPM, the metadata would be created at that level. However, if you also had `/games/poker.rpm,` then you'd want to have _Repodata Depth_ equal to "1," which would account for both the `poker.rpm` and the `ashe.rpm` in this example. If you had _Repodata Depth_ as "2" and tried to push `/games/poker.rpm,` Nexus Repository would reject it. In either case, pushing `/games/wow/horde/thrall.rpm` would work as it has a depth greater than both "1" and "2." **Note** _Repodata Depth_ is an editable field after repository creation, however, it is not a recommended practice. Adjusting it to a value that's deeper than you have existing data will cause issues with your repository which would need to be resolved by a _Rebuild Yum Metadata_ task run, after the value is corrected. ### Layout Policy When configuring your hosted Yum repository, you can configure a _Layout Policy_ that defaults to _Strict_. When this is set to _Strict,_ users can only upload Yum-specific files (RPMs, comps.xml). When this is set to _Permissive,_ users can upload any file of any type. **Note** A _Layout Policy_ of _Permissive_ is required to use the Maven deploy plugin with a hosted Yum repository. ## Grouping Yum Repositories A repository group for Yum allows you to expose the aggregated content of multiple proxy and hosted Yum repositories with one URL to your client tools and is recommended to minimize configuration. To create a Yum group repository, create a new repository using the recipe _yum (group)_ as documented in [Repository Management](https://help.sonatype.com/en/repository-management.html "Repository Management"). Minimal configuration steps are as follows: - Define _Name_ - Select _Blob store_ for _Storage_ - Add Yum repositories to the _Members_ list in the desired order A typical example would be to group the following: 1. The proxy repository that proxies an external Yum repository (for example CentOS) 2. A hosted Yum repository for internal RPMs 3. another hosted Yum repository for third-party RPMs ### Notable Yum Group Functionality - Using the _repository URL_ of the repository group as your Yum _baseURL_ in your client tool gives you access to the RPMs in all member repositories with one URL. - Any RPM added to a hosted or proxy repository becomes immediately available to all users of the Yum repository group. - Metadata for a Yum group is not generated until a request or search is made against the group. - A Yum group will only merge the content of members that are using the same endpoint as other members. - For example, to be able to use a Yum group endpoint that contains a hosted repository and a proxied CentOS (configured endpoint `http://mirror.centos.org/centos/$version/os/$arch` ), your hosted structure should follow the same endpoint convention. This means using a repodepth of "3" and pushing your RPMs to `http:///repository/yum-hosted/7/os/x86_64/example.rpm` for CentOS 7 and x86_64 architecture respectively. - Deviating from a common structure will not merge metadata. - Using the same example in the point above, if you pushed the RPMs to the hosted repository as `http://localhost:8081/repository/yum-hosted/extras/x86_64/example.rpm`, the metadata will be available for use but it will not be merged. See the [Configuring Yum Client subsection](https://help.sonatype.com/en/yum-repositories.html#configuring-yum-client "Configuring Yum Client") for details on how to configure your Yum client. ## Deploying Packages to Yum Hosted Repositories The Yum client does not come with a method for uploading RPMs; however, you can use many other tools to upload files to a hosted Yum repository using a simple `HTTP PUT`. The following example uses the `curl` command and the admin user's default credentials to upload a `test.rpm` file to a hosted Yum repository with the name `test.rpm`: ``` curl -v --user 'admin:admin123' --upload-file ./test.rpm http://localhost:8081/repository/yum-hosted/test.rpm ``` Be default, Yum metadata is generated after 60 seconds when you upload an RPM. While not typically necessary, you can also configure the _Repair -__Rebuild Yum repository metadata (repodata)_ task to create the metadata if the standard generation fails. ## Comps.xml (Package Grouping) Nexus Repository supports Yum package groups when you upload a `comps.xml` file or a `comps.xml.gz` file. You must use the exact filename in order for Nexus Repository to detect the file and include it in the repomd.xml file. ``` curl -v --user 'admin:admin123' --upload-file ./b686d3a0f337323e656d9387b9a76ce6808b26255fc3a138b1a87d3b1cb95ed5-comps.xml http://localhost:8081/repository/yum-hosted/repodata/comps.xml curl -v --user 'admin:admin123' --upload-file ./b686d3a0f337323e656d9387b9a76ce6808b26255fc3a138b1a87d3b1cb95ed5-comps.xml.gz http://localhost:8081/repository/yum-hosted/repodata/comps.xml.gz ``` ## Installing Yum Yum should come pre-installed with RedHat, CentOS, Fedora, and a long list of Linux flavors. If your system does not have Yum preinstalled, you may have larger problems that cannot be solved in these docs. **Note** Fedora users are encouraged to use `http://dnf.baseurl.org/` as of Fedora version 20. DNF is currently backwards compatible and should work with Nexus Repository 3, but it is not explicitly supported. ## Configuring Yum Client Create a `nexus.repo` file in `/etc/yum.repos.d/` that looks similar to the following: **nexus.repo** ``` [nexusrepo] name=Nexus Repository baseurl=http:///repository/yum-proxy/$releasever/os/$basearch/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 repo_gpgcheck=0 priority=1 ``` ### GPG Check The example `nexus.repo` file shown above sets `repo_gpgcheck` to '0,' intentionally disabling GPG checks on the Yum metadata files. We do not consider it a risk to not perform GPG checks on metadata files. We believe the only attack vector would be to insert absolute URLs to a different remote. Nexus Repository removes absolute URLs from metadata files, which neutralizes this threat. Furthermore, the Yum packages that Nexus Repository downloads from the remote URLs will continue to be verified correctly by the Yum client since `gpgcheck` is set to '1'. **Note** Enabling `gpgcheck` tells the Yum client to verify the contents of the packages downloaded from Nexus Repository, but not the repository metadata files; Nexus Repository operations will overwrite these metadata files. If you have set `gpgcheck` to enabled, you'll want to provide the location of the `gpgkey`, replacing the value we've shown in the example above. ## Browsing Yum Repositories and Searching Packages You can browse Yum repositories in the user interface as described in [Browsing Repositories and Repository Groups](https://help.sonatype.com/en/browsing-repositories.html "Browsing Repositories"). You can also search for Yum packages in the user interface. This search finds all packages that are currently stored in Nexus Repository as described in [Searching for Components](https://help.sonatype.com/en/searching-for-components.html "Searching for Components"). ## Search results No results found