Use Nexus Repository Manager OSS as Nuget Server – Part 01

Mario Majcica - Featured Image

Author, Mario Majcica

Editor’s Note: This is a three part series by . In Part 01, Mario walks through the setup of Nexus Repository Manager OSS as a NuGet Server. In Part 02, he examines other considerations (Proxy, License and Vulnerability Tracking, Maintenance, Support and Documentation). Included in Part 02 is how to use Visual Studio to manage packages. In Part 03 there is a walk through of basic security setup and using LDAP for authentication.

If you’d like to be informed of upcoming articles by Mario and other authors, join TheNexus Community and receive updates every two weeks.

Introduction

In my work as a developer, I have heard a lot of excuses when it came to using NuGet packages. Mentioning Nexus Repository Manager OSS in .Net shops, didn’t “feel” right, either. However, when I started working with them, I found they worked exceptionally well together.

In this post I will tell you why this is so. I will guide you through the installation of Nexus Repository Manager and all the necessary setup tasks to create your own NuGet server. It will proxy the calls to NuGet.org and also store your own private packages. I will go through some details about the configuration and maintenance and show you how to set up your tooling in order to integrate with Nexus Repository Manager OSS.

I am going to try and convince you to start using NuGet and Nexus, and drop all of the excuses.

Prerequisites

First thing, make sure JRE is installed. In the command prompt run ‘java -version’. If the command executed successfully you are ready to go. If not, download the right version for your OS at http://www.java.com/en/download/manual.jsp Confirm you are running at least JRE version 8u31+, as it is strongly recommended by Sonatype.

Operating system requirements are specified at the following link https://support.sonatype.com/hc/en-us/articles/213464208-Sonatype-Nexus-System-Requirements.

Download the latest version of Sonatype Nexus at http://www.sonatype.org/nexus/go/ As of this writing, the current version is 2.12.0.

Installing Nexus Repository Manager OSS

In order to install Nexus Repository Manager OSS, extract the content of the downloaded file inside a directory. In my case this will be D:\Nexus. Once done, move to the folder called nexus-2.x.x-xx\bin and execute the following command: nexus install. When the install is complete, start Nexus Repository Manager with the command nexus start.

You will see something similar to this:

D:\Nexus\nexus-2.12.0-01\bin>nexus install
wrapper  | nexus installed.

D:\Nexus\nexus-2.12.0-01\bin>nexus start
wrapper  | Starting the nexus service...
wrapper  | Waiting to start...
wrapper  | Waiting to start...
wrapper  | Waiting to start...
wrapper  | Waiting to start...
wrapper  | Waiting to start...
wrapper  | nexus started.

D:\Nexus\nexus-2.12.0-01\bin>

Point your web browser to default address on which Nexus Repository Manager runs, http://localhost:8081/nexus.

If all went well you should see the following:

Nexus Repository

Login by following the link in the up-right corner. Default administrative account is admin with a password equal to admin123. Once logged in you will see in the menu on the left side additional options. We are now ready to start configuring our repositories.

I also advise you to check the list of recommended post installation configuration steps.

Nuget Proxy Repository

By default, Nexus Repository Manager OSS ships pre-configured with several repositories. If you intend to used it only as a Nuget repository/proxy you can remove all of them.

Nexus Repository Manager - Default Repositories

That is my case and I will remove all of of the available repositories. Once done, you should see a message saying, No repositories defined.

To add a repository that will proxy the call towards the Nuget.org public repository, click on the “Add” dropdown button and choose “Proxy Repository”.

Add a Proxy Repository

At the bottom of the screen you will be asked to fill in all the necessary details. Let’s analyze the important ones.

  • Repository ID: Choose a concise name here, as this will be a part of the feed url. (I will set it to ‘proxy’.)
  • Repository Name: This is just a name that will be assigned to this repository and it will only be visible from the Nexus repositories management interface. (I will set it to ‘Nuget.org proxy’.)
  • Provider: It needs to be set to NuGet.
  • Remote Storage Location: Here we will set the link to the NuGet.org feed. Currently it is https://www.nuget.org/api/v2/

This are all of the necessary parameters. Once filled in, you can click on Save.

Create a New Repo in Nexus

If you now select the just created repository and open the NuGet tab, you will find the link to your feed. In my case it is http://localhost:8081/nexus/service/local/nuget/proxy/.

The first part of the link is obviously wrong. You will not be able to use this feed from any other machine than the server itself. It is displayed as local host and that is equal to the url that we used to access the administration interface. It should be http://yournexusservername:8081/nexus/service/local/nuget/proxy/ where yournexusservername is the name of the machine. We will see later how to influence this url.

Nuget Private Repository

In case you have your own, private NuGet packages you would like to publish and retrieve, Nexus Repository Manager OSS can help with that, too. You need to create a hosted repository. For this repository, set the same settings as for the proxy, except the Remote Storage Location. I’ve set Repository ID to ‘private’ and Repository Name to ‘Nuget local repository’.

Once created, under the NuGet tab, you will find the personal API key needed to use via NuGet.exe in order to push a package to this repository.

API Key for NuGet Repository

In order for the authentication to work correctly, select ‘NuGet API-Key Realm’.

NuGet API-Key Realm

 

Under the Server settings, make sure that NuGet API-Key Realm is under the Selected Realms, which by default is NOT.

Now you can set your Api Key and push your package.

Living Under the Same Roof

Having multiple repositories and feeds can be unwieldy to setup and maintain. Nexus Repository Manager OSS offers a solution to consolidate multiple repositories under a single feed.

A repository group hides multiple repositories behind a single address/feed and allows us to modify the underlying repositories, add new ones or make other changes, without the need to change the configuration in any of your projects or in the tooling. Also it gives a lot of flexibility in setting up different policies and strategies in managing your repositories.

To create a Repository Group under the repository management, choose ‘Add’ then the ‘Repository Group’ option.

New Repository Group

The same settings are mandatory as for the private repository with one addition. You need to choose which repositories will be part of this group.

Tidying up

Link to our feed as it is right now is quite verbose and hard to recall,http://yournexusservername:8081/nexus/service/local/nuget/proxy/. Instead of pointing to yournexusservername we may consider adding a CNAME into our DNS and then point it to that machine. This will also ease the maintenance later on, if we do decide to move the service to another machine. In that case it will be sufficient to re-point DNS to the new machine and no changes to the feed URL will be necessary.

Another thing that stands out is the fact that Nexus Repository Manager OSS web server, as it’s feed services, do run on port 8081. If running Nexus Repository on port 80 (or 443 in case you plan to use SSL) is an option, it will be a better deal. You can also notice that nexus part, just after the port number, it also may not be necessary and removing it will shorten all of the url’s.

Let’s fix this!

I registered a CNAME in my domain and called it nexus. It points to my nexus server. Now by callinghttp://nexus.maio.local:8081/nexus I’m able to reach it. In order to get server running on port 80 and remove that nexus suffix, we need to get to the conf folder (in my case D:\Nexus\nexus-2.12.0-01\conf) and edit the file called nexus.properties. We are interested in changing the two properties under # Jetty section. First one is application-port which by default is set to 8081. You need to set this to 80. Second property we are going to change is nexus-webapp-context-path and we need to change if from /nexus to just a /. This will set the context root with no prefix and make our URL shorter. At the end your configuration file should look like following

...
# Jetty section
application-port=80
application-host=0.0.0.0
nexus-webapp=${bundleBasedir}/nexus
nexus-webapp-context-path=/
...

Now it will be sufficient to restart the nexus windows service in order the changes to take effect. In case no other application is using the port 80, restart should succeed and we are now able to get to the administrative interface by just calling http://nexus.maio.local/. Also my feed now changes to http://nexus.maio.local/service/local/nuget/proxy/ which is shorter and easier to remember.

There is a minor but still important detail. To make sure that the URL’s are not based on the upcoming request, you will need to set the base URL in the server settings.

Application Server Settings

Set the base URL accordingly to your CNAME, remove the nexus as context root and set the port accordingly. You would also like to check the Force Base URL option as then the current settings will be considered for all of the links and Nexus Repository Manager will not base any of them on the upcoming request URL.

This is Part 01 of a three part series. The second article in the series will be published on Thursday, March 31, 2016.

The following two tabs change content below.
Mario has shown his passion for computer and electronics since an early age. This drove his education towards IT and this dedication transformed itself into a full time job. During the past 10 years, he built tangible experience over application development and best practices, mostly on .Net platform. This also helped him understand the importance of the development process and the tooling supporting it. In the recent years, most of his assignments focused over ALM tasks helping companies and development teams with continuous integration, test automation, deployment, integration, and last but not least, enterprise application development. He has worked on all stages of the product development lifecycle, using an extensive range of technical skills, always striving for elegant solutions. Alongside the development skills, he has built hands-on experience on deploying, administering, using and maintaining the Microsoft Team Foundation Server. Mario has been successful in many projects and has worked on multiple platforms with an acute ability to pick up new technologies quickly. He is dedicated and proactive and always tries to communicate in manageable terms that are understandable to both technical and non-technical colleagues and customers. His main focus is always on bringing value to his customers. Mario shares this knowledge freely on his blog and as a speaker at numerous conferences.
Authors

Related posts

*

Top