Documentation Nexus Repository Manager 3.3

Chapter 4. Configuration

Available in Nexus Repository OSS and Nexus Repository Pro

4.1. Introduction

This chapter covers all aspects of configuring Nexus Repository Manager Pro and Nexus Repository Manager OSS. Specifically the sections and menu items of the Administration main menu are covered. It can be accessed by authorized users by pressing the Administration button figs/web/ui-admin-button-icon.png in the main toolbar.

[Tip]

The default user for accessing these features has the username admin and the password admin123. More fine-grained access can be configured as detailed in Chapter 6, Security.

The Administration menu contains the following sections:

Repository
The Repository section allows you to manage all Repositories and related configurations such as Routing and Targets.
IQ Server (Nexus Repository Manager Pro only)
The Server item allows you to configure the connection of Nexus Repository Manager Pro to Nexus IQ Server. Further documentation is available in the Nexus IQ Server documentation.
[Note]

If you desire to utilize Nexus Firewall to quarantine and block unacceptable components that may harm your repository manager, review the quick start guide. Firewall is only available to Nexus Repository Manager Pro users.

Security
This section provides access to all the configuration features related to authentication and authorization of users including Privileges, Roles, Users, but also LDAP, Atlassian Crowd, SSL Certificates and User Token.
Support
Access a number of features that allow you to administer and monitor your repository manager successfully like Logging and System Information.
System
The general configuration for getting started and running the repository manager with e.g., HTTP or Email Server settings, but also Capabilities and Tasks to run regularly and other configurations.

4.2. System Configuration

The System section of the Administration menu gives you access to a number of configuration features that you typically need to configure, after successful installation. The following sections detail:

4.2.1. Bundles

Available in Nexus Repository OSS and Nexus Repository Pro

The Nexus Repository Manager application runs on the OSGi container Apache Felix. All features and plugins are managed by the container and are implemented as OSGi bundles.

The Bundles feature view is available in the System section of the Administration main menu. It allows you to inspect a list of all the OSGi bundles that are deployed as part of the application and access detailed information about each bundle.

[Tip]

Find out more about OSGi and OSGi bundles on the website of the OSGi Alliance.

4.2.2. Accessing and Configuring Capabilities

Available in Nexus Repository OSS and Nexus Repository Pro

Capabilities are features of the repository manager and plugins that can be configured by a user in a generic administration feature view accessible in the System section of the Administration main menu via Capabilities.

The repository manager ships with a number of capabilities preinstalled and allows you to enable/disable them. An example capability is Outreach: Management displayed in Figure 4.1, “Outreach: Management Capability Settings”.

figs/web/capability-outreach.png

Figure 4.1. Outreach: Management Capability Settings


The list of capabilities can be filtered with the search input box in the header of the list and sorted by the different columns by pressing a column header. The list uses the following columns:

State
The state column does not have a title. Enabled capabilities have a green checkmark added on top of a blue icon. Disabled capabilities use a greyed out icon.
Type
The Type column provides the specific type of a capability in the list.
Category
The Category is optional and details the wider context the capability belongs to.
Description
The Description column contains further descriptive information about the capability.
Notes
The Notes column can contain user created text about the capability.

Every capability can be inspected and configured by selecting it in the list. The resulting view display the Summary view of the specific capability. This view includes the display of Type, State and optionally Category and Description in the Summary section as well as further information in the Status, About and Notes sections. The Status section displays a text message that details the status of the capability and any potential problems with the configuration. Depending on the capability, the reasons can vary widely. The About section displays a descriptive text about the purpose of the capability. The Notes field can be used to provide a descriptive text about the capability or any other notes related to it and can be persisted by pressing the Save button.

The Delete button below the title allows you to remove a capability and it’s configuration entirely. The Enable and Disable buttons on the other hand can be used to switch the state of the capability.

The Settings view allows you to activate or deactivate the capability with the Enable this capability checkbox. Below this checkbox, each capability type has specific additional configuration parameters available. Once you have completed the configuration, press the Save button.

The capabilities management feature view supports adding new capabilities by pressing the Create capability button above the list and selecting the desired capability Type from the list. The next view allows you to perform any capability-specific configuration and finish the process by pressing the Create capability button below the parameters.

Many of the built-in capabilities and plugins can be configured in the Capabilities administration section but also in other more user friendly, targeted user interface sections, e.g., the user token feature of Nexus Repository Manager Pro can be administrated by using the interface available via the User Token menu item in the Security section of the Administration menu as well as by editing the user token capability. Other capabilities are internal functionality and sometimes managed automatically by the responsible plugin. Some optional configuration like the branding plugin or advanced features of the smart proxy configuration are only done in the capabilities administration.

Usage of specific capabilities to achieve a variety of tasks is detailed in parts of the documentation.

[Warning]

In many cases you will not need to configure anything in Capabilities unless explicitly instructed to do so by the support team. Execute any capability changes with caution, potentially backing up your configuration before proceeding.

4.2.3. Email Server

Available in Nexus Repository OSS and Nexus Repository Pro

The repository manager may send out email messages for a number of reasons. In order for these messages to be delivered, you need to configure the connection to the SMTP server under the Email Server menu item in the System section of the Administration menu as displayed in Figure 4.2, “Email Server Configuration”.

figs/web/admin-system-emailserver.png

Figure 4.2. Email Server Configuration


The following configuration options are available:

Enabled
Determines whether email sending is activated or not, independent of a server being configured.
Host and Port
The name of the host and the port to use to connect to the SMTP server.
Use the Nexus truststore
This checkbox allows you to configure the repository manager to use its certificate truststore. You can also view and import the certificate from the email server. Further details are documented in Section 6.10, “Configuring SSL”.
Username and Password
The credentials of the user of the SMTP server to use for authentication.
From address
This parameter defines the email address used in the From: header of any email sent by the repository manager. Typically, this is configured as a "Do-Not-Reply" email address or a mailbox or mailing list monitored by the administrators of the repository manager.
Subject prefix
This parameter allows you to define a prefix used in the subject line of all emails sent by the repository manager. This allows the recipients to set up automatic filtering and sorting easily. An example is [Nexus Notification].
SSL/TLS options

These options can be used to configure usage of Transport Layer Security (TLS) and Secure Sockets Layer (SSL) when emails are sent by the repository manager using SMTP. These options include the ability to use STARTTLS, which upgrades the initially established, plain connection to be encrypted when sending emails. The following options are available to you:

Enable STARTTLS support for insecure connections
This checkbox allows you to enable support for upgrading insecure connections using STARTTLS.
Require STARTTLS support
This checkbox requires that insecure connections are upgraded using STARTTLS. If this is not supported by the SMTP server, no emails are sent.
Enable SSL/TLS encryption upon connection
This checkbox enables SSL/TLS encryption for the transport on connection using SMTPS/POPS.
Enable server identity check
This option verifies the server certificate when using TLS or SSL, following the RFC 2595 specification.

Once you have configured the parameters you can use the Verify email server button to confirm the configured parameters and the successful connection to the server. You are asked to provide an email address that should receive a test email message. Successful sending is confirmed in a message.

4.2.4. Nodes

The Nodes screen provides a summary of all active nodes. The screen keeps a record of all running nodes that you can manage for single or multiple deployments of nodes, in table form. To view the status of your active node click Nodes in the Administration menu under System. When you click a row, you get a detailed summary of the chosen node.

The summary lists:

  • Node Identity, a unique ID accessible via the System Information
  • Local, true for the server you’re currently accessing
  • Socket Address, the address corresponding to the server

If you run multiple nodes the Nodes screen displays all synchronized nodes in the table. The client you use to view your local node (e.g. browser) will be listed as true. View the table to monitor and verify server connections.

Also, from the Nodes screen you can protect your server’s database from write access by activating read-only mode. This allows you to avoid modifications to your server configuration and blob stores when performing system maintenance. To enable it:

  1. Click Nodes, under System in the Administration menu
  2. Click Enable read-only mode
[Warning]

Anything that would require a change to a database will fail during read-only mode.

The button becomes Disable read-only mode when enabled. A banner appears above the main toolbar, notifying you that read-only mode is activated.

Disabling read-only mode, by clicking the Disable read-only mode button returns the server to its original, writable state.

4.2.5. Base URL Creation

The Base URL is the address end users apply when navigating to the user interface. The repository manager only uses this value to construct absolute URLs to your user interface inside of email notifications.

The most common reason why the address would be different is if you have a reverse proxy that terminates HTTP requests at an address different from where the repository manager is running.

To set the Base URL:

  • Go to the System section of the Administration menu and select Capabilities.
  • Search for an existing Base URL capability and select it if it exists or click the Create capability button and choose Base URL from the Select Capability Type list.
  • Enter a new URL value.
  • Press the Create capability to add the Base URL.

4.2.6. HTTP and HTTPS Request and Proxy Settings

Available in Nexus Repository OSS and Nexus Repository Pro

The repository manager uses HTTP requests to fetch content from remote servers. In some cases a customization of these requests is required. Many organizations use proxy servers for any outbound HTTP network traffic. The connection to these proxy servers from the repository manager needs to be configured to allow it to reach remote repositories. All this can be configured in the HTTP configuration available via the System section of the Administration menu and displayed in Figure 4.3, “Configuring HTTP Request Settings”.

figs/web/admin-system-http.png

Figure 4.3. Configuring HTTP Request Settings


User-agent customization
The HTTP configuration in User-agent customization allows you to append a string to the User-Agent HTTP header field. This can be a required customization by your proxy servers.
Connection/Socket timeout and attempts
The amount of time in seconds the repository manager waits for a request to succeed when interacting with an external, remote repository as well as the number of retry attempts to make when requests fail can be configured with these settings.

If your repository manager instance needs to reach public repositories like the Central Repository via a proxy server, you can configure the connection to a proxy server. Typically such an internal proxy server proxies HTTP as well as HTTPS connections to external repositories. In this case you configure a HTTP proxy. Select the checkbox beside HTTP Proxy and configure the parameters in the sections displayed in Figure 4.4, “Configuring HTTP Proxy Settings”. If your organization uses a separate, additional proxy server for HTTPS connections, you have to configure it in the HTTPS Proxy section.

[Tip]

This is a critical initial step for many Enterprise deployments of Nexus Repository Manager Pro and Nexus Repository Manager OSS, since these environments are typically secured via an HTTP/HTTPS proxy server for all outgoing internet traffic.

figs/web/admin-system-http-proxy.png

Figure 4.4. Configuring HTTP Proxy Settings


You can specify the HTTP proxy host and the HTTP proxy port of the HTTP or HTTPS proxy server and, optionally, the Authentication details for Username and Password. If a Windows NT LAN Manager is used to authenticate with the proxy server you can configure the needed connection details in Windows NTLM hostname and Windows NTLM domain.

In addition, you can configure a number of hosts that the repository manager reaches directly, ignoring the proxy settings. Requests to them should not go through the configured HTTP/HTTPS proxy. These hosts can be configured in the Hosts to exclude from HTTP/HTTPS proxy setting. You can add a hostname in the input box and add it with the + button. The * character can be used for wildcard matching for numerous host names allowing a setting such as *.example.com. Entries can be removed with the x button.

Figure 4.4, “Configuring HTTP Proxy Settings” shows the HTTP Proxy administration interface. The HTTPS configuration interface looks the same and is found below the HTTP configuration.

4.2.7. Configuring and Executing Tasks

Available in Nexus Repository OSS and Nexus Repository Pro

The repository manager allows you to schedule the execution of maintenance tasks. The tasks can carry out regular maintenance steps that will be applied to all repositories or to specific repositories on a configurable schedule or simply perform other system maintenance. Use the Tasks menu item in the System section of the Administration menu to access the feature view, shown in Figure 4.5, “Managing Tasks”, that allows you to manage your Tasks.

figs/web/tasks.png

Figure 4.5. Managing Tasks


The list interface allows you to add new tasks with the Create task button as well as inspect and work with the configured tasks. The list shows the following columns:

Name
A user-defined name for the task to identify it in the user interface and log files.
Type
The type of action the scheduled task executes. The list of available task types is documented in more detail below.
Status
Tasks can either be Waiting for their next run, currently Running or Disabled.
Schedule
The Schedule column shows the Task frequency e.g., Daily, Monthly, Manual and others.
Next run
This column displays date and time of the next execution of the task based on the configured schedule.
Last run and Last result
These columns display the date and time as well as the result and duration of the last execution of the specific task.

When creating or updating a scheduled task, you can configure the following additional properties:

Task enabled
Enable or disable a specific task with the checkbox.
Notification Email
Configure a notification email for task execution failures. If a scheduled task fails a notification email containing the task identifier and name as well as the stack trace of the failure will be sent to the configured email recipient.
Task frequency
Selecting the task frequency allows you to configure the schedule for the task executions. Available choices are Manual, Once, Hourly, Daily, Weekly, Monthly and Advanced (provide a CRON expression). Apart from Manual, all choices trigger display of a custom user interface for scheduling the specific recurrence. Weekly scheduling requires at least one day of the week to be selected. The advanced setting allows you to provide a CRON expression to configure more complex schedules.

The syntax used for Advanced (provide a CRON expression) follows the UNIX-style CRON syntax. CRON expressions are comprised of 6 required fields and one optional field separated by white space as described in Table 4.1, “Fields of a CRON Expression from Left to Right” and the following paragraphs. A simple expression example is 0 0 9 * * ?. This configuration triggers a task execution every day at 9:00 in the morning. Further examples are available in Table 4.2, “CRON Expression Examples”.

Table 4.1. Fields of a CRON Expression from Left to Right

Field Name Allowed Values Allowed Special Characters

Seconds

0-59

, - * /

Minutes

0-59

, - * /

Hours

0-23

, - * /

Day-of-month

1-31

, - * ? / L W

Month

1-12 or JAN-DEC

, - * /

Day-of-Week

1-7 or SUN-SAT

, - * ? / L #

Year (Optional)

empty, 1970-2099

, - * /


The * character is used to specify any value. For example, * in the minute field means every minute.

The ? character is allowed for the day-of-month and day-of-week fields. It is used to specify no specific value. This is useful when you need to specify something in one of the two fields, but not the other.

The - character is used to specify ranges. For example 10-12 in the hour field means "the hours 10,11 and 12".

The , character is used to specify additional values. For example MON,WED,FRI in the day-of-week field means "the days Monday, Wednesday, and Friday".

The / character is used to specify a start value and increments. For example "0/15" in the seconds field means "the seconds 0, 15, 30, and 45". And "5/15" in the seconds field means "the seconds 5, 20, 35, and 50". Specifying * before the / is equivalent to specifying 0 as the value to start with. Essentially, for each field in the expression, there is a set of numbers that can be turned on or off. For seconds and minutes, the numbers range from 0 to 59. For hours 0 to 23, for days of the month 0 to 31, and for months 1 to 12. The / character simply helps you turn on every "nth" value in the given set. Thus "7/6" in the month field only turns on month "7", it does not mean every 6th month, please note that subtlety.

The L character is allowed for the day-of-month and day-of-week fields. This character is short-hand for "last", but it has different meaning in each of the two fields. For example, the value L in the day-of-month field means "the last day of the month" - day 31 for January, day 28 for February on non-leap years. If used in the day-of-week field by itself, it simply means 7 or SAT. But if used in the day-of-week field after another value, it means "the last xxx day of the month" - for example 6L means "the last Friday of the month". When using the L option, it is important not to specify lists, or ranges of values, as you will get confusing results.

The W character is allowed for the day-of-month field. This character is used to specify the weekday (Monday-Friday) nearest the given day. As an example, if you were to specify "15W" as the value for the day-of-month field, the meaning is: "the nearest weekday to the 15th of the month". So if the 15th is a Saturday, the trigger will fire on Friday the 14th. If the 15th is a Sunday, the trigger will fire on Monday the 16th. If the 15th is a Tuesday, then it will fire on Tuesday the 15th. However if you specify 1W as the value for day-of-month, and the 1st is a Saturday, the trigger will fire on Monday the 3rd, as it will not jump over the boundary of a months days. The W character can only be specified when the day-of-month is a single day, not a range or list of days.

The L and W characters can also be combined for the day-of-month expression to yield LW, which translates to "last weekday of the month".

The # character is allowed for the day-of-week field. This character is used to specify "the nth" XXX day of the month. For example, the value of "6#3" in the day-of-week field means the third Friday of the month (day 6 = Friday and #3 is the 3rd one in the month). Other examples: 2#1 is the first Monday of the month and 4#5 is the fifth Wednesday of the month. Note that if you specify #5 and there is not 5 of the given day-of-week in the month, then no firing will occur that month.

The legal characters and the names of months and days of the week are not case sensitive.

Table 4.2. CRON Expression Examples

Expression Description

0 0 12 * * ?

Fire at 12pm (noon) every day

0 15 10 ? * *

Fire at 10:15am every day

0 15 10 * * ?

Fire at 10:15am every day

0 15 10 * * ? *

Fire at 10:15am every day

0 15 10 * * ? 2015

Fire at 10:15am every day during the year 2015

0 * 14 * * ?

Fire every minute starting at 2pm and ending at 2:59pm, every day

0 0/5 14 * * ?

Fire every 5 minutes starting at 2pm and ending at 2:55pm, every day

0 0/5 14,18 * * ?

Fire every 5 minutes starting at 2pm and ending at 2:55pm, AND fire every 5 minutes starting at 6pm and ending at 6:55pm, every day

0 0-5 14 * * ?

Fire every minute starting at 2pm and ending at 2:05pm, every day

0 10,44 14 ? 3 WED

Fire at 2:10pm and at 2:44pm every Wednesday in the month of March.

0 15 10 ? * MON-FRI

Fire at 10:15am every Monday, Tuesday, Wednesday, Thursday and Friday

0 15 10 15 * ?

Fire at 10:15am on the 15th day of every month

0 15 10 L * ?

Fire at 10:15am on the last day of every month

0 15 10 ? * 6L

Fire at 10:15am on the last Friday of every month

0 15 10 ? * 6L 2002-2005

Fire at 10:15am on every last Friday of every month during the years 2002, 2003, 2004 and 2005

0 15 10 ? * 6#3

Fire at 10:15am on the third Friday of every month


The Start date and Start time allow you to configure a specific date and time from when the schedule should be activated. The Time to run this task settings is used to configure the actual time of the task execution.

Task-type specific configuration is displayed below the notification email input field and differs for each scheduled task.

The following task types are available to perform specific maintenance:

Compact blob store
Content deleted from a blob store is not physically deleted from the storage device. Instead it is only internally marked for deletion. This task performs the actual deletion of the relevant files, and therefore frees up the storage space.
Export configuration & metadata for backup
This task performs a full back up of the underlying Nexus Repository Manager databases, including access logs, repository manager configuration, and security configuration. You must choose a location for the backup data for this task. When you run the backup, the task adds a timestamp to the backup files that are created in the backup data location. It is important to note that this backup only includes the data just listed, actual repository content is not backed up using this task.
Execute script
Scripts can be provided in the Source field and have to be written using the Groovy programming language. These scripts can use the APIs of the repository manager to perform maintenance and other modification tasks. Please consult the Javadoc and source for further information.
Publish Maven indexes
Maven indexes can be used to download an index of available components to a client including a developer’s IDE, for example. The task publishes the index for all or a specific Maven repository.
Purge incomplete docker uploads
Docker uploads to a repository can be hundreds of MB in size. It is possible to have incomplete uploads or orphaned files remain in temporary storage as a result of incomplete or interrupted uploads. The temporary storage consumed by these incomplete or orphaned uploads can be cleaned up with this task. You can configure the minimum age of incomplete uploads to be purged and have them deleted by the task execution. In addition, any incomplete uploads from docker that have been orphaned by a repository manager restart will be cleaned up whenever the task executes.
Purge orphaned API keys
This scheduled task deletes old, unused API keys. These keys are generated, for example, when using the User Token feature or publishing to NuGet repositories. A key becomes unused, when the user account is deleted. The task purges these orphaned API keys and should be scheduled to run regularly to remove these redundant keys.
Purge unused components and assets
This task can be used to remove components and assets in proxy repositories. Any component that has not been requested in the configured number of days will be purged.
Purge unused docker manifests and images
This task will handle purging content that is no longer referenced. As new manifests are created and associated with a tag, previous manifests will still sit around in the repository providing no use. This also applies to any images that are no longer referenced by a tagged manifest. V1 layers that are no longer referenced by a tagged layer will also be removed.
Purge unused Maven snapshot versions
This task can be used to remove unused snapshots from Maven repositories. Any snapshot that has not been requested in the configured number of days will be purged.
Rebuild Maven repository metadata
This task rebuilds the maven-metadata.xml files with the correct information and will also (optionally) validate and fix any incorrect checksums (.md5/.sha1) for all files in the specified maven2 hosted repository. The Group Id, Artifact Id and Base Version parameters allow you to narrow down the section of the repository that will be repaired. Typically this task is run manually to repair a corrupted repository.
Rebuild repository index
With support for hosted and proxy repositories, this task can rebuild the index. It inspects actual components and assets found in the repository and rebuilds the index to reflect the true content for supporting search and browse actions.
Remove Maven indexes
This task is the counter-part to the task Publish Maven indexes and can remove the index.
Remove snapshots from Maven repository

This task can be scheduled to remove SNAPSHOT-versioned components from a Maven repository. Typically this is useful to preserve storage space, as old SNAPSHOT versions are not accessed after deployment of a new snapshot and no longer added value. The tasks removes all metadata about the components and assets affected, while it does not reclaim disk space used by the binary assets. This can be achieved by running a Compact blob store task afterwards. When you create a scheduled task to remove snapshots, you can specify the Repository/Group to affect, as well as:

Minimum snapshot count
This configuration option allows you to specify a minimum number of snapshots to preserve per component SNAPSHOT version. For example, if you configured this option with a value of 2, the repository manager will always preserve at least two time-stamped SNAPSHOT versions. A value of -1 indicates that all snapshots should be preserved.
Snapshot retention (days)
This configuration option allows you to specify the number of days to retain component SNAPSHOT versions. For example, if you want to make sure that you are always keeping the last three day’s worth of snapshots, configure this option with a value of 3. The Minimum snapshot count configuration overrides this setting.
Remove if released
If checked, all SNAPSHOT versions that match any released component found with the same groupId and artifactId coordinates will be removed. For example, if a release version of com.example:hello-world:1.0.0 is found, all com.example:hello-world:1.0.0-SNAPSHOT assets are deleted.
Grace period after release (days)
This parameter allows you to specify a number of days before released snapshots are purged. If a release associated to a snapshot has an updated timestamp and falls within the set grace period, it will not be purged. This setting will give the respective project that references the snapshot dependency time to upgrade to the release component or the next snapshot version.
[Caution]

The deletion of Maven snapshots when Remove if released is checked takes precedence over the number you select in the Minimum snapshot count field. Also, it is possible to configure the task in such a way that the results may be unexpected. For example, if configured to keep 0 minimum snapshots older than 0 days, all snapshots everywhere will be deleted, despite whether or not a grace period is configured for releases.

Beyond these tasks any plugin can provide additional scheduled tasks, which will appear once you have installed the plugin.

Setting up tasks execution adapted to your usage of the repository manager is an important first step when setting up a Nexus Repository Manager instance. Go through the list of task types and consider your usage patterns. In addition update your tasks when changing your usage. E.g., if you start to regularly deploy snapshots by introducing continuous integration server builds with deployment.

4.3. Repository Management

Available in Nexus Repository OSS and Nexus Repository Pro

Repositories are the containers for the components provided to your users as explained in more detail in Chapter 1, Concepts. Creating and managing repositories is an essential part of your Nexus Repository Manager configuration, since it allows you to expose more components to your users.

It supports proxy repositories, hosted repositories and repository groups using a number of different repository formats.

The binary parts of a repository are stored in blob stores, which can be configured by selecting Blob stores from the Repository sub menu of the Administration menu.

To manage repositories select the Repositories item in the Repository sub menu of the Administration menu.

4.3.1. Blob Stores

A blob store is a storage mechanism for the binary parts of the components and their assets. Each blob store can be used by one or multiple repositories and repository groups. A default blob store that is based on a file system storage within the data directory configured during the installation is automatically configured.

The Blob stores feature view available via the Blob stores item in the Repository sub menu of the Administration menu displays a list of all configured blob stores. The columns provide some detail about each blob store:

Name
the name of the blob store as displayed in the repository administration
Type
the type of the blob store backend, currently only File is available representing a file system-based storage
Blob count
the number of blobs currently stored
Total size
the size of the blob store
Available space
the overall space available for the blob store

Click on a specific row to inspect further details of the selected blob store. The details view displays Type and Name and the absolute Path to the file system storage.

The Create blob store button allows you to add further blob stores. You can configure the Type and Name for the blob store. The Path parameter should be an absolute path to the desired file system location. It has to be fully accessible by the operating system user account running the Nexus repository manager.

Once a blob store has been created it can no longer be modified and any blob store used by a repository or repository group can not be deleted.

Blobs deleted in a repository are only marked for deletion. The Compact blob store task can be used to permanently delete these soft-deleted blobs and therefore free up the used storage space.

Choosing the Number of Blob Stores

You will need to choose how many blob stores to create, and how you allocate repositories to these blob stores. This decision should be based on:

  • the size of your repositories
  • the rate at which you expect them to grow over time
  • the storage space available to your Nexus Repository Manager
  • the options you have available for adding storage space

For the time being, once a repository is allocated to a blob store, it is there permanently. Blob stores can be moved from one storage device to another (e.g. to a larger storage device) using a manual process, but blob stores cannot be split, nor can repositories span multiple blob stores. For these reasons, your approach to using blob stores should be chosen carefully.

The simplest approach is to create a single blob store per storage device and divide your repositories among them. This is suitable if either:

  • Your repositories are growing slowly enough that you won’t exceed your available storage within a year
  • If you exceed available storage, you will be able to move blob stores to larger storage devices.

You should separate repositories into two or more blob stores per storage device if both:

  • You expect to exceed your currently available storage within a year
  • You cannot move blob stores to larger storage devices, so you must add capacity to Nexus Repository Manager by adding additional storage devices.

The most flexible approach is to create a separate blob store for each repository, although this is not recommended except in extreme cases of unpredictable capacity because of the administrative complexity.

The current repository-to-blob store limitations will be removed in an upcoming release of Nexus Repository Manager, which will make it possible to revise your repository/blob store approach over time.

Estimating Blob Store Size

Blob stores contain two files for each binary component stored in Nexus Repository Manager:

  • The binary component, stored as a .bytes file (whose size is the same as the component)
  • A properties file that stores a small amount of metadata for disaster recovery purposes (<1k)

The total storage size of a blob store is therefore approximately the total size of all of your components, plus an allowance for the properties files and the block size of your storage device. (On average, this will be 1.5 * # of components * block size.)

4.3.2. Proxy Repository

A repository with the type proxy, also known as a proxy repository, is a repository that is linked to a remote repository. Any request for a component is verified against the local content of the proxy repository. If no local component is found, the request is forwarded to the remote repository. The component is then retrieved and stored locally in the repository manager, which acts as a cache. Subsequent requests for the same component are then fulfilled from the local storage, therefore eliminating the network bandwidth and time overhead of retrieving the component from the remote repository again.

By default, the repository manager ships with the following configured proxy repositories:

maven-central
This proxy repository accesses the Central Repository, formerly known as Maven Central. It is the default component repository built into Apache Maven and is well-supported by other build tools like Gradle, SBT or Ant/Ivy.
nuget.org-proxy
This proxy repository accesses the NuGet Gallery. It is the default component repository used by the nuget package management tool used for .Net development.

4.3.3. Hosted Repository

A repository with the type hosted, also known as a hosted repository, is a repository that stores components in the repository manager as the authoritative location for these components.

By default, the repository manager ships with the following configured hosted repositories:

maven-releases
This hosted repository uses the maven2 repository format with a release version policy. It is intended to be the repository where your organization publishes internal releases. You can also use this repository for third-party components that are not available in external repositories and can therefore not be retrieved via a configured proxy repository. Examples of these components could be commercial, proprietary libraries such as an Oracle JDBC driver that may be referenced by your organization.
maven-snapshots
This hosted repository uses the maven2 repository format with a snapshot version policy. It is intended to be the the repository where your organization publishes internal development versions, also known as snapshots.
nuget-hosted
This hosted repository is where your organization can publish internal releases in repository using the NuGet repository format. You can also use this repository for third-party components that are not available in external repositories, that could potentially be proxied to gain access to the components.

4.3.4. Repository Group

A repository with the type group, also known as repository group, represents a powerful feature of Nexus Repository Manager. They allow you to combine multiple repositories and other repository groups in a single repository. This in turn means that your users can rely on a single URL for their configuration needs, while the administrators can add more repositories and therefore components to the repository group.

The repository manager ships with the following groups:

maven-public
The maven-public group is a repository group of maven2 formatted repositories and combines the important external proxy repository for the Central Repository with the hosted repositories maven-releases and maven-snapshots. This allows you to expose the components of the Central Repository as well as your internal components in one single, simple-to-use repository and therefore URL.
nuget-group
This group combines the nuget formatted repositories nuget-hosted and nuget.org-proxy into a single repository for your .Net development with NuGet.

4.3.5. Managing Repositories and Repository Groups

The administration user interface for repositories and repository groups is available via the Repositories item in the Repository sub menu of the Administration menu. It allows you to create and configure repositories as well as delete them and perform various maintenance operations. The initial view displayed in Figure 4.6, “List of Repositories” features a list of all configured repositories and repository groups.

figs/web/admin-repository-repositories-list.png

Figure 4.6. List of Repositories


The list of repositories displays some information for each repository in the following columns

Name
the unique name of the repository or repository group
Type
the type of the repository with values of proxy or hosted for repositories or group for a repository group
Format
the repository format used for the storage in the repository with values such as maven2, nuget or others
Status
the status of the repository as well as further information about the status. A functioning repository would show the status to be Online. Additional information can e.g., be about SSL certification problems or the status of the remote repository for a currently disabled proxy repository
URL
the copy button prompts a dialog containing a direct URL path exposing the repository
Health Check
displays the repository health statistics from a previously run Repository Health Check, or a button to start the analysis

The Create repository button above the repository list triggers a dialog to select the Recipe for the new repository. The recipe combines the format and the type of repository into a single selection. Depending on your repository manager version and installed plugins, the list of available choices differs.

For example to create another release repository in maven2 format, you would click on the row with the recipe maven2 (hosted) in the dialog. If you wanted to proxy a maven2 repository, choose maven 2 (proxy). On the other hand if you want to proxy a nuget repository, choose nuget (proxy). With maven2 (group) you can create a repository group for maven2 repositories.

After this selection, you are presented with the configuration view, that allows you to fill in the required parameters and some further configuration. The exact details on the view depend on the selected repository provider and are identical to the administration for updating the configuration of a repository documented in the following sections.

Once you have created a repository or repository group, it is available in the list for further configuration and management. Clicking on a specific row allows you to navigate to this repository specific administration section. An example for the maven-central repository is partially displayed in Figure 4.7, “Partial Repository Configuration for a Proxy Repository”.

figs/web/admin-repository-repositories-central.png

Figure 4.7. Partial Repository Configuration for a Proxy Repository


The repository administration feature view has buttons to perform various actions on a repository. The buttons displayed depend on the repository format and type. The following buttons can be found:

Delete repository
The Delete repository button allows you to delete the repository and all related configuration and components, after confirming the operation in a dialog.
Invalidate cache

The Invalidate cache button invalidates the caches for this repository. The exact behavior depends on the repository type:

Proxy repositories
Invalidating the cache on a proxy repository clears the proxy cache such that any items cached as available will be checked again for any changes the next time they are requested. This also clears the negative cache for the proxy repository such that any items that were not found within the defined cache period will be checked again the next time they are requested.
Repository groups
Invalidating the cache of a repository group, clears the group cache such that any items fetched and held in the group cache, such as Maven metadata, will be cleared. This action also invalidates the caches of any proxy and group repositories that are members of this group.
Rebuild Index
The Rebuild Index button allows you to drop and recreate the search index for the proxy repository, synchronizing the contents with search index. This button is only available for proxy repositories.

The following properties can be viewed for all repositories and can not be edited after the initial creation of the repository.

Name
The Name is the identifier that will be used in the URL for access to the repository. For example, the proxy repository for the Central Repository has a name of maven-central. The Name must be unique in a given repository manager installation and is required.
Format
Format defines in what format the repository manager exposes the repository to external tools. Supported formats depend on the edition of the repository manager and the installed plugins. Examples are maven2, nuget, raw, docker, npm and others.
Type
The type of repository - proxy, hosted or group.
URL
It shows the user facing URL this means that Maven and other tools can access the repository directly at e.g., http://localhost:8081/repository/maven-central.
Online
The checkbox allows you set whether this repository is available to client side tools or not.

Beyond the generic fields used for any repository, a number of different fields are used and vary depending on the repository format and type. They are grouped under a number of specific headers that include configuration for the related aspects and include:

  • Storage
  • Hosted
  • Proxy
  • Negative Cache
  • HTTP
  • Maven 2
  • NuGet
  • and others

Storage

Every repository needs to have a Blob store configured to determine where components are stored. The drop-down allows you to select from all the configured blob stores. Documentation about creating blob stores can be found in Section 4.3.1, “Blob Stores”.

The Strict Content Type Validation allows you to activate a validation that checks the MIME type of all files published into a repository to conform to the allowed types for the specific repository format.

Hosted

A hosted repository includes configuration of a Deployment policy in the Hosted configuration section. Its setting controls how a hosted repository allows or disallows component deployment.

If the policy is set to Read-only, no deployment is allowed.

If this policy is set to Disable redeploy, a client can only deploy a particular component once and any attempt to deploy a component again will result in an error. The disabled redeploy is the default value, since most client tools assume components to be immutable and will not check a repository for changed components that have already been retrieved and cached locally.

If the policy is set to Allow redeploy, clients can deploy components to this repository and overwrite the same component in subsequent deployments.

Proxy

The configuration for proxy repositories in the Proxy section also contains the following parameters:

Remote Storage
A proxy repository on the other hand requires the configuration of the Remote Storage. It needs to be configured with the URL of the remote repository, that should to be proxied. When selecting the URL to proxy it is beneficial to avoid proxying remote repository groups. Proxying repository groups prevents some performance optimization in terms of accessing and retrieving the content of the remote repository. If you require components from the group that are found in different hosted repositories on the remote repository server it is better to create multiple proxy repositories that proxy the different hosted repositories from the remote server on your repository manager instead of simply proxying the group.
Use the Nexus truststore
This checkbox allows you to elect for the repository manager to manage the SSL certificate of the remote repository. It is only displayed - if the remote storage uses a HTTPS URL. The View certificate button triggers the display of the SSL certificate details in a dialog. The dialog allows you to add or remove the certificate from the certificate truststore maintained by the repository manager. Further details are documented in Section 6.10.1, “Outbound SSL - Trusting SSL Certificates of Remote Repositories”.
Blocked
Setting a repository to blocked causes the repository manager to no longer send outbound requests to the remote repository.
Auto blocking enabled
If Auto blocking enabled is set to true, the repository manager automatically blocks a proxy repository if the remote repository becomes unavailable. While a proxy repository is blocked, components will still be served to clients from a local cache, but the repository manager will not attempt to locate an component in a remote repository. The repository manager periodically retests the remote repository and unblocks it once it becomes available.
Maximum component age
When the proxy receives a request for a component, it does not request a new version from the remote repository until the existing component is older than Maximum component age.
Maximum metadata age
The repository manager retrieves metadata from the remote repository. It will only retrieve updates to metadata after the Maximum metadata age has been exceeded. If the metadata is component metadata, it uses the longer of this value and Maximum component age before rechecking.

Negative Cache

Not found cache enabled/Not found cache TTL
If the repository manager fails to locate a component, it will cache this result for a given number of minutes. In other words, if the repository manager can’t find a component in a remote repository, it will not perform repeated attempts to resolve this component until the Not found cache TTL time has been exceeded. The default for this setting is 1440 minutes (or 24 hours) and this cache is enabled by default.

HTTP

The HTTP configuration section allows you to configure the necessary details to access the remote repository, even if you have to provide authentication details in order to access it successfully or if you have to connect to it via a proxy server.

[Note]

This configuration is only necessary, if it is specific to this repository. Global HTTP proxy and authentication is documented in Section 4.2.6, “HTTP and HTTPS Request and Proxy Settings”.

Authentication
This section allows you to select Username or Windows NTLM as Authentication type. Subsequently you can provide the required Username and Password for plain authentication or Username, Password, Windows NTLM hostname and Windows NTLM domain for Windows NTLM-based authentication.
HTTP request settings

In the HTTP request settings you can change properties of the HTTP requests to the remote repository. The values you can apply to this section are:

User-agent customization
Enter the string to be appended to user-agent HTTP headers.
Connection retries
Enter the total number of connection attempts after an initial timeout.
Connection timeout
Set the timeout interval for requests, in seconds.
Enable circular redirects
Allow proxy repositories to follow redirects indicated by the remote server even if they point to an already processed URL.
Enable cookies
Authorize HTTP cookies sent by the remote server, for future requests.
[Tip]

https://maven.oracle.com is a server that requires both Enable circular redirects and Enable cookies. This is because, when requesting data you are redirected to a queue of different URLs, most of which are involved with authentication. By enabling these options, you allow the repository manager to maintain the authentication state in a cookie that would be sent with each request, eliminating the need for the authentication-related redirects and avoiding timeouts.

Changes made to HTTP request settings are applied to all HTTP requests made from the repository manager to the remote repository being proxied. Enabling these settings will override any general settings defined in Section 4.2.6, “HTTP and HTTPS Request and Proxy Settings”.

Some repository formats include configuration options, such as these formats:

Repository Groups

The creation and configuration for a repository group differs a little from pure repositories. It allows you to manage the member repositories of a repository group. An example for a repository group using the maven2 format is visible in Figure 4.8, “Repository Group Configuration”. In this figure you can see the contents of the maven-public group that is pre-configured in Nexus Repository Manager.

figs/web/admin-repository-repositories-group.png

Figure 4.8. Repository Group Configuration


The Format and Type are determined by the selection of the provider in the creation dialog e.g., maven2 (group) for the maven-public as a maven2 format repository group.

The Name is set during the creation and is fixed once the repository group is created.

The Online checkbox allows you set whether this repository group is available to client side tools or not.

The Member repositories selector allows you to add repositories to the repository group as well as remove them. The Members column includes all the repositories that constitute the group. The Available column includes all the repositories and repository groups that can potentially be added to the group.

Note that the order of the repositories listed in the Member section is important. When the repository manager searches for a component in a repository group, it will return the first match. To reorder a repository in this list, click and the drag the repositories and groups in the Members list or use the arrow buttons between the Available and Members list. These arrows can be used to add and remove repositories as well.

The order of repositories or other groups in a group can be used to influence the effective metadata that will be retrieved by Maven or other tools from a repository group. It is recommended practice to place hosted repositories higher in the list than proxy repositories. For proxy repositories, the repository manager needs to check the remote repository which will incur more overhead than a hosted repository lookup.

It is also recommended to place repositories with a higher probability of matching the majority of components higher in this list. If most of your components are going to be retrieved from the Central Repository, putting maven-central higher in this list than a smaller, more focused repository is going to be better for performance, as the repository manager is not going to interrogate the smaller remote repository for as many missing components. These best practices are implemented in the default configuration.

4.3.6. Repository Management Example

The following sections detail some common steps of your repository management efforts on the example of a maven2 repository.

Adding Repositories for Missing Dependencies

If you’ve configured your Maven settings.xml or other build tool configuration to use the maven-public repository group as a mirror for all repositories, you might encounter projects that are unable to retrieve components from your local repository manager installation.

[Tip]

More details about client tool configuration for Maven repositories can be found in Chapter 8, Maven Repositories with Apache Maven and Other Tools.

This usually happens because you are trying to build a project that has defined a custom set of repositories and snapshot repositories or relies on the content of other publicly available repositories in its configuration. When you encounter such a project all you have to do is

  • add this repository as a new maven2 format, proxy repository
  • and then add the new proxy repository to the maven-public group.

The advantage of this approach is that no configuration change on the build tool side is necessary at all.

Adding a New Repository

Once you have established the URL and format of the remote repository you are ready to configure the repository. E.g. the JBoss.org releases repository contains your missing component. Click on the Create repository button in the Repositories feature view and click on maven2 (proxy) from the list in the dialog.

In the configuration dialog:

  • Set Name to jboss-releases
  • Set Remote storage to https://repository.jboss.org/nexus/content/repositories/releases/
  • For a maven2 format repository, confirm that the Version policy is set correctly to Release.
  • Click on the Create repository button at the end of the form

The repository manager is now configured to proxy the repository. If the remote repository contains snapshots as well as release components, you will need to repeat the process creating a second proxy repository with the same URL setting version policy to Snapshot.

Adding a Repository to a Group

Next you will need to add the new repository jboss-releases to the maven-public repository group. To do this, click on the row of the maven-public group in the Repositories feature view.

To add the new repository to the public group, find the repository in the Available list on the left, click on the repository you want to add and drag it to the right to the Members list. Once the repository is in that list, you can click and drag the repository within that list to alter the order in which the group will be searched for a matching component. Press the Save button to complete this configuration.

In the last few sections, you learned how to add new repositories to a build in order to download components that are not available in the Central Repository.

If you were not using a repository manager, you would have added these repositories to the repository element of your project’s POM, or you would have asked all of your developers to modify ~/.m2/settings.xml to reference two new repositories. Instead, you used the repository manager to add the two repositories to the public group. If all of the developers are configured to point to the public group, you can freely swap in new repositories without asking your developers to change local configuration, and you’ve gained a certain amount of control over which repositories are made available to your development team. In addition the performance of the component resolving across multiple repositories will be handled by the repository manager and therefore be much faster than client side resolution done by Maven each time.

4.3.7. Content Selectors

Available in Nexus Repository OSS and Nexus Repository Pro

Content selectors provide a means for you to select specific content from all of your content. The content you select is evaluated against a JEXL expression. JEXL is an expression library used to script queries along specific paths and coordinates available to your repository manager formats.

Content selectors allow you to identify what selector privilege you can assign to a user. You can define, in a simplified example, a selector named Apache Maven with a search expression of path =^ "/org/apache/maven/". This would match all components that start with the designated component path.

Creating a Query

Before you identify user permissions for your selector, create the query first. Click Content Selectors located in Repository, from the Administration menu. Click Create selector to open a new form.

In the Selector ID section enter a Name and (optional) Description of your selector in the corresponding fields. In the Specification section use the Search expression field to build your query using JEXL syntax.

You can preview your selector and what results it will return by clicking the Preview results button. On click, a modal will appear as shown in Figure 4.9, “Content Selector Preview Modal”. The Expression field will automatically be filled in with anything you had in the Search expression field. Similarly, any changes to Expression will be saved to Search expression when you close the preview.

figs/web/content-selector-preview.png

Figure 4.9. Content Selector Preview Modal


To see results your selector would find, select a repository or grouping of repositories from the Preview Repository dropdown and click the Preview button. Assets that match will be returned in the space below the filter and can be filtered upon if you wish to check on a specific result. The Name column is also sortable in ascending or descending order. Close returns you to the content selector creation screen.

Once you are satisified with your fields, click Create selector to create the Content Selector. All saved selector queries you create will be listed in the Content Selectors screen.

Managing Selector Permissions

As part of your security setup, you can create user permissions to manage the filters you built in the Create Selector form. You can add a new privilege that controls operations such as read, edit, delete, and * (all), for components matching that selector. The privilege can even span multiple repositories.

To create a new content selector privilege, click Privileges in the Security section of the Administration panel. Then click the Create Privilege button. Locate and click Repository Content Selector from the list of options in Select Privilege Type. You will see a form that displays the following:

  • Name: Create a name for the content selector privilege.
  • Description: Add a brief description for the privilege.
  • Content Selector: Use this dropdown to select from a list of selectors you created.
  • Repository: Use this dropdown to select from either a range of all repository contents, all repository contents of an individual format, or repositories created by you.
  • Actions: Grant read, edit, delete, or * (all) privileges for user access control.

To complete the form, save the new privilege by clicking Create privilege. You can use your new privilege to regulate what permissible data you want the user to access. You could group all related privileges into a role as documented in Section 6.4, “Roles”. Ultimately, you could assign your roles to a user, as mentioned in Section 6.5, “Users”.

A practical example might be where you delegate all control of components in org.apache.maven to a "Maven" team. This way, you would not need to create separate repositories for each logical division of your components.

Content Selector Reference

Below are the allowable attributes for content selectors that define path, format, and coordinate as values supported by Nexus Repository Manager.

Attribute Allowed Values

path

The path of your repository content

format

The format of the content for which you query

coordinate

A map of attributes that differ by content format

This table contains a description of attributes that can affect the respective formats. See the examples below, for sample format queries against specific coordinates.

Available Formats Coordinate Attributes

maven2

coordinate.groupId, coordinate.artifactId, coordinate.version, coordinate.classifier, coordinate.extension

raw

(No coordinates)

Content Selector Examples

If, for example, you want to create a pattern that would capture all components within the format maven2 you can define it utilizing the variable format. You can use the syntax available in this JEXL guide as a reference to create your queries.

JEXL examples may include:

Select all raw format content

format == "raw"

Select all maven2 content along a path that starts with org.apache.commons

format == "maven2" && path =^ "/org/apache/commons/"

[Tip]

When writing a content selector, remember that the asset’s path will always begin with a leading slash when the selector is evaluated. This is true even though the leading slash is not displayed when searching or browsing assets.

4.4. License Management

Available in Nexus Repository Pro only

A paid license is necessary to upgrade Nexus Repository Manager OSS to Nexus Repository Manager Pro, and to keep Nexus Repository Manager Pro paid features operational. You must be logged in as a user with sufficient privileges to manage licenses.

4.4.1. Uploading a License

The paid license is a special .lic file that you upload to the Licensing feature view, found in the Administration menu. To install the license:

  • Upload the file from the Select license… button.
  • Select the correct .lic file in the file selection dialog, and press Open.
  • Click the Install license button.
  • Enter your password when the re-authentication dialog appears.
  • Click I agree to the terms stated in the End User License Agreement.
  • Click Authenticate to complete the upload.

After the file is successfully uploaded, you will receive a notification to restart the repository manager. After restart the License type, shown in the Licensing panel, will display the features associated with your license.

4.4.2. Managing Recent Connections

Users with sufficient privileges can generate a record of users who had sessions within the last 7 days in the repository manager. In the Administration menu, go to the Recent Connections feature view, nested below Licensing, to access the table.

The table displays the IP address (IP), last accessed date (Date), user name (User), and client (User agent). To generate the report click Download to produce a CSV file of listed users.

When a Nexus Repository Manager Pro license expires all functionality will be disabled in the user interface, except for the ability to install a new license file. To avoid interruption of service be sure to upload a renewed license before the existing license expires. Nexus Repository Manager Pro will provide a warning when the license is within 30 days of expiry.

4.5. Support Features

Nexus Repository Manager provides a number of features that allow you to ensure your server is configured correctly and provides you with tools to investigate details about the configuration. This information can be useful for troubleshooting and support activities.

All support features are available in the Support group of the Administration menu in the main menu section and include:

4.5.1. Analytics

Available in Nexus Repository OSS and Nexus Repository Pro

The analytics integration allows Sonatype to gather data about of your repository manager usage, since it enables the collection of event data. It collects non-sensitive information about how you are using the repository manager and allows Sonatype to achieve a better understanding of usage overall and therefore drive product innovation following your needs.

The collected information is limited the primary interaction points between your environment and the repository manager. None of the request specific data (e.g., credentials or otherwise sensitive information) is ever captured.

[Tip]

The data is can be useful to you from a compatibility perspective, since it gathers answers to questions such as what features are most important, where are users having difficulties, and what integrations/APIs are actively in use.

You can enable the event logging in the Analytics feature view available via Analytics menu item in the Support section of the Administration menu. Select the checkbox beside Collect analytics events and press the Save button.

You can choose to provide this data automatically to Sonatype by selecting the checkbox beside Enable anonymized analytics submission to Sonatype. It enables Sonatype to tailor the ongoing development of the product. Alternatively, you can submit the data manually or just use the gathered data for your own analysis only.

Once enabled, all events logged can be inspected in the Events feature view available via the Analytics section of the Administration menu displayed in Figure 4.10, “List of Analytics Events”.

figs/web/analytics-events.png

Figure 4.10. List of Analytics Events


The list of events shows the Event type, the Timestamp, the Sequence number and the Duration of the event as well as the User that triggered it and any Attributes. Each row has a + symbol in the first column that allows you to expand the row vertically. Each attribute will be expanded into a separate line allowing you to inspect all the information that is potentially submitted to Sonatype.

The User value is replaced by a salted hash so that no username information is transmitted. The Anonymization Salt is automatically randomly generated and can optionally be configured in the Analytics: Collection capability manually. This administration area can additionally be used to change the random identifier for the repository manager instance.

[Tip]

More information about capabilities can be found in Section 4.2.2, “Accessing and Configuring Capabilities”.

If you desire to further inspect the data that is potentially submitted, you can select to download the file containing the JSON files in a zip archive by clicking the Export button above the events list and downloading the file. The Submit button can be used to manually submit the events to Sonatype.

[Important]

Sonatype values your input greatly and hopes you will activate the analytics feature and the automatic submission to allow us to ensure ongoing development is well aligned with your needs. In addition, Sonatype appreciates any further direct contact and feedback in person and looks forward to hearing from you.

4.5.2. Logging and Log Viewer

Available in Nexus Repository OSS and Nexus Repository Pro

You can configure the level of logging for the repository manager and all plugins as well as inspect the current log using the user interface with the Logging and the Log Viewer feature views.

Access the Logging feature view displayed in Figure 4.11, “The Logging Feature View for Configuring Loggers” with the Logging menu item in the Support section in the Administration main menu.

figs/web/logging.png

Figure 4.11. The Logging Feature View for Configuring Loggers


The Logging feature view allows you to configure the preconfigured loggers as well as add and remove loggers. You can modify the log level for a configured logger by clicking on the Level value e.g., INFO. It will change into a drop-down of the valid levels including OFF, DEFAULT, INFO and others. Press the Update button to apply the change.

The Create logger button can be used to create new loggers. You will need to know the Logger name you want to configure. Typically this corresponds to the Java package name used in the source code. Depending on your needs you can inspect the source of Nexus Repository Manager OSS and the plugins as well as the source of your own plugins to determine the related loggers or contact Sonatype support for detailed help.

If you select a row in the list of loggers, you can delete the highlighted logger by pressing the Delete logger button above the list. This only applies to previously created custom loggers. To disable a default configured logger, set it to OFF.

[Important]

When upgrading the repository manager, keep in mind that some loggers change between versions, so if you rely on specific loggers, you might have to reconfigure them.

The Reset to default levels button allows you to remove all your custom loggers and get back to the setup shipped with a fresh install of the repository manager.

The loggers configured in the user interface are persisted into $data-dir/etc/logback/logback-overrides.xml and override any logging levels configured in the main $install-dir/etc/logback/logback.xml file as well as other logback-* files. If you need to edit a logging level in those files, edit the overrides file. This will give you access to edit the configuration in the user interface at a later stage and also ensure that the values you configure take precedence.

The ROOT logger level controls how verbose the logging is in general. If set to DEBUG, logging will be very verbose, printing all log messages including debugging statements. If set to ERROR, logging will be far less verbose, only printing out a log statement if the repository manager encounters an error. INFO represents an intermediate amount of logging.

[Tip]

When configuring logging, keep in mind that heavy logging can have a significant performance impact on an application and any changes trigger the change to the logging immediately.

Once logging is configured as desired, you can inspect the impact of your configuration in the Log Viewer feature view. It allows you to copy the log from the server to your machine by pressing the Download button. The Create mark button allows you to add a custom text string into the log, so that you can create a reference point in the log file for an analysis of the file. It will insert the text you entered surrounded by * symbols as visible in Figure 4.12, “Viewing the Log with an Inserted Mark”.

figs/web/log-viewer.png

Figure 4.12. Viewing the Log with an Inserted Mark


The Refresh interval configuration on the right on the top of the view allows you to configure the timing for the refresh as well as the size of the log displayed. A manual refresh can be triggered with the general refresh button in the main toolbar.

4.5.3. Metrics

Available in Nexus Repository OSS and Nexus Repository Pro

The Metrics feature view is available in the Support section of the Administration main menu. It provides insight to characteristics of the Java virtual machine JVM running the repository manager and is displayed in Figure 4.13, “JVM Metrics”.

figs/web/metrics.png

Figure 4.13. JVM Metrics


The Memory usage, Memory distribution and Thread states charts provide some simple visualizations. The Download button allows you to retrieve a large number of properties from the JVM and download them in a JSON-formatted text file. Pressing the Thread dump button triggers the creation of a thread dump of the JVM and a download of the resulting text file.

4.5.4. Support ZIP

Available in Nexus Repository OSS and Nexus Repository Pro

The Support ZIP feature view allows you to create a ZIP archive file that you can submit to Sonatype support via email or a support ticket. The checkboxes in Contents and Options allow you to control the content and size of the archive.

The repository manager implements security measures when a support ZIP is generated. Sensitive password related information is removed from generated files. When a support ZIP download is attempted, you may be prompted to verify your repository manager account credentials.

Support ZIP archive files are stored on the server under the $data-dir/downloads directory using a name which includes the time the file was generated.

Creating a Support ZIP

  1. Sign in to the user interface using the default admin account or any account with the nx-admin role.
  2. Click the cog icon in the top toolbar to open the administration interface.
  3. Select Support and then Support ZIP sidebar menu items.
  4. Review the options and click the Create Support ZIP button. A popup dialog will be shown when the support zip generation is complete.
  5. Either download the support ZIP using the Download button or use the file path shown to retrieve the file from the $data-dir/downloads directory.

4.5.5. System Information

Available in Nexus Repository OSS and Nexus Repository Pro

The System Information feature view displays a large number of configuration details related to

Nexus
details about the versions of the repository manager and the installed plugins, install and work directory location, application host and port and a number of other properties.
Java Virtual Machine
all system properties like java.runtime.name, os.name and many more as known by the JVM running the repository manager
Operating System
including environment variables like JAVA_HOME or PATH as well as details about the runtime in terms of processor, memory and threads, network connectors and storage file stores.

You can copy a subsection of the text from the panel or use the Download button to retrieve a JSON-formatted text file.