Available in Nexus Repository OSS and Nexus Repository Pro
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.
Accessing Information About Bundles
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.
Find out more about OSGi and OSGi bundles on the website of the OSGi Alliance.
Accessing and Configuring Capabilities
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: “'Outreach: Management' Capability Settings”.
Figure: 'Outreach: Management' Capability Settings
The list of existing 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:
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.
The Type column provides the specific type of a capability in the list.
The Category is optional and details the wider context the capability belongs to.
The Description column contains further descriptive information about the capability.
The Notes column can contain user created text about the capability.
Every existing capability can be inspected and configured by selecting it in the list. The resulting view displays 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.
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.
Email/SMTP Server Configuration
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: “Email Server Configuration”.
Figure: Email Server Configuration
The following configuration options are available:
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 Configuring SSL.
Username and Password
The credentials of the user of the SMTP server to use for authentication.
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.
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] .
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.
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
- Socket Address, the address corresponding to the server
If you run multiple nodes the Nodes screen displays all synchronized nodes in the table. 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:
- Click Nodes, under System in the Administration menu
- Click Enable read-only mode
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.
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.
The UI Settings allow you to configure a few settings around UI usage, via a capability as displayed in Figure: “UI Setting Capability Configuration".
Figure: UI Settings Capability Configuration
The text that will be displayed in the browser as the page title.
Whether the ?debug flag will be allowed, to put the User Interface in debug mode.
Authenticated user status interval
The number of seconds to wait between sending status requests to the server.
Anonymous user status interval
The number of seconds to wait between sending status requests to the server for non-authenticated users.
The number of minutes to wait before expiring the UI session of an inactive user.
Standard request timeout
The number of seconds to allow a request to process before terminating the connection.
The number of seconds to allow long running requests to process before terminating the connection. This applies to certain requests that may take considerably longer than others, including the upload of assets as well as generating a support zip.
HTTP and HTTPS Request and Proxy Settings
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: “Configuring HTTP Request Settings”.
Figure: Configuring HTTP Request Settings
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: “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.
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.
Figure: 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
Figure: “Configuring HTTP Proxy Settings” shows the HTTP Proxy administration interface. The HTTPS configuration interface looks the same and is found below the HTTP configuration.
Configuring and Executing Tasks
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: “Managing Tasks”, that allows you to manage your Tasks.
Figure: 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:
A user-defined name for the task to identify it in the user interface and log files.
The type of action the scheduled task executes. The list of available task types is documented in more detail below.
Tasks can either be Waiting for their next run, currently Running or Disabled.
The Schedule column shows the Task frequency e.g., Daily, Monthly, Manual, and others.
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:
Enable or disable a specific task with the checkbox.
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.
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”.
Allowed Special Characters
|Month||1-12 or JAN-DEC|
|Day-of-Week||1-7 or SUN-SAT|
|Year (Optional)||empty, 1970-2099|
Table 4.1. Fields of a CRON Expression from Left to Right
This character is used to specify any value. For example, * in the minute field means every minute.
This 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.
This character is used to specify ranges. For example 10-12 in the hour field means "the hours 10,11 and 12".
This 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".
This 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.
This 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.
This 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.
W characters can also be combined for the day-of-month expression to yield
LW, which translates to "last weekday of the month".
This 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.
|Fire at 12pm (noon) every day|
|Fire at 10:15am every day|
|Fire at 10:15am every day|
|Fire at 10:15am every day|
|Fire at 10:15am every day during the year 2015|
|Fire every minute starting at 2pm and ending at 2:59pm, every day|
|Fire every 5 minutes starting at 2pm and ending at 2:55pm, every day|
|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|
|Fire every minute starting at 2pm and ending at 2:05pm, every day|
|Fire at 2:10pm and at 2:44pm every Wednesday in the month of March.|
|Fire at 10:15am every Monday, Tuesday, Wednesday, Thursday and Friday|
|Fire at 10:15am on the 15th day of every month|
|Fire at 10:15am on the last day of every month|
|Fire at 10:15am on the last Friday of every month|
Fire at 10:15am on every last Friday of every month during the years 2002, 2003, 2004 and 2005
|Fire at 10:15am on the third Friday of every month|
Table 4.2. CRON Expression Examples
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.
Types of Tasks and When to Use Them
The following tasks are available to perform specified maintenance:
|Task Name||Task Id||Description||Typically Scheduled|
Admin - Cleanup Tags
This task will allow you to cleanup tags once they reach a certain age, haven't been modified in a certain period, or using a regular expression on the name.
You can also choose to delete the components along with those tags, as well as restrict this component deletion to a particular format or repository.
See additional details on the tagging page.
Admin - Compact blob store
|blobstore.compact||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.||Yes|
|Admin - Delete orphaned API keys||security.purge-api-keys|
This task deletes old, unused API keys. These keys are generated, for example, when using the User Token feature and become orphaned when the associated user account is deleted.
|Admin - Export databases for backup|
This task performs a full backup of the underlying 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 this task does not backup actual repository content.
|Admin - Execute script||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 related documentation for writing scripts and additional information/references to the Javadoc and source.||Optional|
Admin - Log database table record counts
This task logs clustered database record counts for each node. The task is automatically added when clustering is enabled and can be disabled by including an additional property in the nexus.properties file:
|Admin - Remove a member from a blob store group||blobstore.group.memberRemoval||This task removes a blob store from a group. Each blob within the removed store is written back to the group and then deleted from the removed blob store.||No|
|Docker - Delete incomplete uploads||repository.docker.upload-purge|
This task cleans up orphaned files that may exist in temporary storage as result of a restart or incomplete/interrupted uploads.
The Age in hours parameter allows you to configure the minimum age of incomplete uploads to be deleted.
|Docker - Delete unused manifests and images||repository.docker.gc||This task will handle deletion of content that is no longer referenced, images that are no longer referenced by a tagged manifest and V1 layers that are no longer referenced by a tagged layer.||Yes|
|Maven - Delete SNAPSHOT**|
This task can be scheduled to delete SNAPSHOT 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 add value. When you create a scheduled task to delete snapshots, you can specify the repository to affect, as well as set the following parameters:
Minimum snapshot count: This configuration option allows you to specify a minimum number of snapshots to preserve per component SNAPSHOT version.
Snapshot retention (days): This configuration option allows you to specify the number of days to retain component SNAPSHOT versions.
Remove if released: If checked, all SNAPSHOT versions that match any released component found with the same groupId and artifactId coordinates will be removed.
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 deleted. This setting will give the respective project that references the snapshot dependency time to upgrade to the release component or the next snapshot version.
The deletion of Maven snapshots when Remove if released is checked takes precedence over the number you select in the Minimum snapshot count field. NOTE: It is possible to configure the task in such a way that the results may be unexpected. 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.
|Maven - Delete unused SNAPSHOT**|
This task can be used to delete unused SNAPSHOT files from Maven repositories. Any SNAPSHOT that has not been requested in the configured number of days will be purged.
In the event the component has never been requested this task will use the uploaded date instead.
|Maven - Publish Maven Indexer files||repository.maven.publish-dotindex|
The task publishes the indexer files for all or a specific Maven repository.
|Maven - Unpublish Maven Indexer files||repository.maven.unpublish-dotindex||This task is the counterpart to the task Maven - Publish Maven Indexer files and can remove the indexer files.||Optional|
|Repair - Rebuild Maven repository metadata (maven-metadata.xml)|
|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 only run manually to repair a corrupted repository.||No|
|Repair - Rebuild repository browse|
|This task rebuilds the tree browsing data based upon current information in the database.||No|
|Repair - Rebuild repository search|
With support for hosted and proxy repositories, this task rebuilds the search index. It inspects actual components and assets found in the selected repository and thus reflects the true content for supporting search and browse actions.
Cancelling this task before completion could result in a partially rebuilt search index showing incomplete component search results until it is run again and allowed to complete.
|Repair - Reconcile component database from blob store|
This task allows you to recover lost asset/component metadata from a chosen blob store. The task is useful in cases where you want to recover lost information from corrupt databases. When executed, the task searches the selected blob store for blobs missing their associated metadata. The asset/component metadata is restored based on the information contained in the blob store.
Currently, this task only recovers metadata for Docker, Maven, npm, PyPI, Raw, RubyGems and Yum repositories.
npm and Yum
npm and Yum search and tree view browsing will not work after running this task unless you run the respective metadata repair tasks ( Repair - Reconcile npm /-/v1/searchmetadata and Repair - Rebuild Yum repository metadata (repodata) ) first. Builds will work however.
Running these tasks before restore is complete will likely cause incomplete search and browse results.
NOTE: To avoid resultant possible errors in search and browse, we recommend running Repair - Rebuild repository browse and Repair - Rebuild repository search tasks when your component database repair is complete.
|Repair - Reconcile date metadata from blob store|
This task reads the blobstore and updates the assets in the database with date information.
|Repair - Reconcile npm /-/v1/searchmetadata|
This task extracts search metadata from all npm packages in all npm hosted repositories to enable support for the new /v1/ search endpoint that replaced the /all/ endpoint.
|Repair - Rebuild Yum repository metadata (repodata)|
|This task rebuilds the metadata for a chosen Yum hosted repository. This task runs automatically 60 seconds (configurable) after an RPM is uploaded, deleted or redeployed.||No|
|Repository - Delete unused components**||repository.purge-unused||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.||Yes|
* *NOTE: Tasks deleting components only removes metadata for the components and assets they affect, they do not reclaim disk space used by the binary assets. This is achieved by using the Admin - Compact blob store task afterward.
Tasks with the prefix "Repair -" are only intended to be run if you are having specific trouble with your system. These tasks should only be run manually, not scheduled, and should usually only be run at the advice of a Sonatype staff member.
Beyond these tasks, any plugin can provide additional scheduled tasks, which will appear once you have installed the plugin.
Setting up task execution adapted to your usage of the repository manager is an important first step when setting up a Nexus Repository Manager instance. It is also important to update your tasks when changing your usage patterns. For example, adjustments to your tasks may be required if you start to regularly deploy snapshots by introducing continuous integration server builds with deployment.
The output of every task run will go to a separate log file. By default these task logs are stored in
$data-dir/log/tasks. The file name of each task log is the type followed by the full date and time the task started. For example:
Generally the output of the task will go to both the
nexus.log and the specific task log, however some tasks will only go to the
For long running tasks, progress will be logged back to the
nexus.log every 10 minutes as the work continues. Most commonly this will appear as a contextual update relevant to that particular task such as the number of items that have been processed, updated, deleted, etc.
Task log files are removed after 30 days.