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 4.1, “Outreach: Management Capability Settings”.
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:
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 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 4.2, “Email Server Configuration”.
Figure 4.2. 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.
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 4.3, “Configuring HTTP Request Settings”.
Figure 4.3. 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 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.
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 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
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.
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 4.5, “Managing Tasks”, that allows you to manage your Tasks.
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:
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 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.
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.
Rebuild Yum metadata
This task rebuilds the metadata for a chosen Yum repository.
Reindex npm repository
This task takes all the metadata from npm packages in the specified Repository and uses it to populate what will show in the UI and be available against the command line search. This procedure is normally done when there are additions or updates to your repositories and should not need to be regularly scheduled.
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 storetask 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.
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.
Restore Asset/Component metadata from Blob Store
This task allows you to recover lost asset/component metadata from a chosen blob store. The task is useful in cases as where you want to recover lost information from corrupt OrientDB 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, Restore Asset/Component metadata from Blob Store only recovers metadata for Maven and npm repositories.
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.
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.