Why use Nexus 3 as Yum repository?

Sonatype Nexus Repository
1

I need some good selling points for choosing Nexus as Yum repository.
Today we use plain file storage and createrepo for our RPMs.

Advantages:
Search Capabilities
++

Why does nexus give us more control over the RPMs, compared to simple file storage?

We already use Nexus as repository manager for Java and JavaScript. We also plan on using it as our Docker registry.

2

I would like to know the answer to this if someone has the experience. We are currently using a spacewalk server for this, and it seems needlessly complicated. But… the Nexus repo would have to be able to help control the roll out of patches through the network rather than everyone at the same time.

3

If you are already using NXRM3 then you probably already know all these but the benefits of the repository manager are:

  • Caching of proxied RPMs to insulate your teams from upstream outages.
  • REST API and Scripting API for interfacing with 3rd party systems.
  • UI for browsing, searching and managing RPMs
  • Centralized security including integration with other systems (LDAP, Crowd, User Tokens etc.)
  • Having everything in a single place for ease of backup and maintenance.
  • Staging functionality (pro only) for controlling release pipelines.
  • Storage management tools to cleanup old RPMs.
  • Createrepo is run automatically as RPMs are added, updated or removed.
  • Repositories (both proxy and hosted) can be managed behind a group repository meaning users only need to point at a single URL and repositories can then be added / removed without having to update workstation configuration.
  • The CentOS remotes remove old RPMs periodically. Having these cached in NXRM will give you reproducible builds.

I’m sure there are more but I haven’t had my coffee yet so I’ll let others dive in :smile:
Hope this Helps!

1 Like
4

Thanks many good points for NXRM Yum.

Can these tools also be used to move old RPMs?, as we do not want to delete them, but just move them away from the repository.

You mentioned in another discussion something about this.

This is contrary to the documentation. It says the update runs at a configured interval (default 60 seconds).

5

Can these tools also be used to move old RPMs?, as we do not want to delete them, but just move them away from the repository.

There is nothing automated for this yet but you could use the move functionality via the REST api (Pro only)

This is contrary to the documentation. It says the update runs at a configured interval (default 60 seconds).

Good point. When you make a change to the contents of a YUM hosted repository NXRM waits 60 seconds (configurable) before updating the metadata because metadata generation is expensive and you might be uploading more than one RPM. So it is run automatically whenever a change is made but you won’t see the changes for 60 seconds.

6

Thanks, that was good to know. Perhaps this should be mentioned in the documentation, or perhaps be made clearer.

7

Hello,
I checked to make sure and we do have this here: https://help.sonatype.com/display/NXRM3/Yum+Repositories#YumRepositories-DeployingPackagestoYumHostedRepositories
If you have suggestions how to make more clear, please let us know.
Thanks!
Joe Tom

8

One footnote mention the repo update:

When an RPM is uploaded, the Yum metadata will be generated after the configured value (default 60 seconds).

After reading jstephens explanation it was clear after reading the documentation again what that sentence meant.

9

This looks really interesting. We have a file storage staging repository today to put the RPMs until the verification phase has run successfully.