Available in Nexus Repository OSS and Nexus Repository Pro
is a command line package management utility for Linux distributions using the RPM package manager. It allows for many commonly used Linux packages to be easily installed on to distributions such as RedHat, CentOS and Fedora. or "Yellowdog Updater, Modified"
Nexus Repository Manager OSS and Nexus Repository Manager Pro support the Yum repository format for proxy repositories. This allows the repository manager to take advantage of the packages in public Yum repositories without incurring repeated downloads of packages. This will also allow you to perform offline installs, for example allowing you to install CentOS without a connection to the internet.
Upgrading Yum repositories from version 2 to version 3 is currently not supported.
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.
Minimal configuration steps are:
- Define Name e.g. yum-proxy
- Define URL for Remote storage, e.g.
- Pick a Blob store for Storage
We do not create a default Yum proxy repository as there are many. Determine which repositories are appropriate for your environment.
Hosting Yum Repositories
A hosted repository for Yum can be used to upload your own RPMs as well as third-party RPMs. To host a Yum RPM, create a new yum (hosted) repository as documented in Repository Management.
When creating a Yum Hosted repository, you'll need to pick a Repodata Depth. This sets the level that the repodata metadata folder will be created initially as well as the expected folder depth that the rpms can be at (or deeper than) to match. Rpms with less depth will be rejected by Nexus Repository Manager.
For example, if your package is created at
/games/lol/ashe.rpm then the Repodata Depth would be 2 and when pushing the rpm in 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 it'd be rejected. In either case, pushing
/games/wow/horde/thrall.rpm would be fine, it having a depth more than both 1 and 2.
It is possible to configure a Layout Policy which defaults to Strict. When this is set to Strict, only yum-specific files (rpm, comps.xml) can be uploaded. When this is set to Permissive, any file of any type can be uploaded.
A Layout Policy of Permissive is required to use the Maven deploy plugin with a Yum Hosted repository.
Minimal configuration steps for creating a Yum Hosted repository are:
- Define Name e.g. yum-hosted
- Select a value for Repodata Depth
- Pick a Blob store for Storage
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.
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.
Minimal configuration steps are:
Select Blob store for Storage
Add Yum repositories to the Members list in the desired order
A typical, useful example would be to group the proxy repository that proxies an external Yum repository (for example CentOS), a hosted Yum repository for internal rpms, and another hosted Yum repository for third-party rpms.
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.
Unlike Yum Hosted, metadata for a Yum Group is not generated until a request or search is made against the group.
Yum group will only merge content of members that are using the same endpoint as other members. As an 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, i.e. using a repodepth of 3 and pushing your rpms to
http://<ip-address>/repository/yum-hosted/7/os/x86_64/example.rpm for centos7 OS and x86_64 architecture respectively.
Deviating from a common structure will not merge metadata; taking the example above if the rpms were pushed 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 specific details on how to configure your client in below subsection.
Deploying Packages to Yum Hosted Repositories
The Yum client does not come with a method for uploading RPMs however many other tools can be used to upload files to a hosted Yum repository using a simple
HTTP PUT. The following example uses the
curl command and the default credentials of the admin user to upload a
test.rpm file to a hosted Yum repository with the name
curl -v --user 'admin:admin123' --upload-file ./test.rpm http://localhost:8081/repository/yum-hosted/test.rpm
When an RPM is uploaded, the Yum metadata will be generated after the configured value (default 60 seconds).
The task Repair - Rebuild Yum repository metadata (repodata) can also be configured to create the metadata if the standard generation fails. This is not typically needed, thus is regarded as a Repair task. Further information about tasks can be found in Configuring and Executing Tasks.
Comps.xml (package grouping)
Yum package groups are supported by uploading a comps.xml file or a comps.xml.gz file (the exact filename must be used for it to be detected by the repository manager and included 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
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.
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 Manager 3, but is not explicitly supported.
Configuring Yum Client
nexus.repo file in
/etc/yum.repos.d/ that looks similar to the following:
[nexusrepo] name=Nexus Repository baseurl=http://<serveraddress:port>/repository/yum-proxy/$releasever/os/$basearch/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 priority=1
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 inspecting the components and assets and their details, as described in Browsing Repositories and Repository Groups.
Searching for Yum packages can be performed in the user interface, too. It finds all packages that are currently stored in the repository manager, as described in Searching for Components.