Sonatype Nexus 2 has "routing" capabilities, so that I can configure my requests for internal artifacts to only be served by certain (internal) repositories.
I've got a version of Nexus 3 running but I don't see any way to implement this capability. There is something called "content selectors" which might be the new mechanism, but there is absolutely no documentation of it, so I can't use it. This is a pretty important security requirement.
Am I missing something? How do I route requests in Nexus 3?
Nexus 3.17 is out. It is the first version to support routing rules. They work differently than in Nexus 2.X, but meet the same need. Things are now rule centered instead of repo centered. I found the Nexus 3 approach to be easier to understand.
This documentation page shows the new routing rules.
And for future readers:
Content selectors: privileges within nexus. Useful if you want to restrict a user to certain paths
Routing rules: which repos are queried for what patterns. Useful if you want to only look up certain paths from certain repos.
From support question I asked of nexus team, this feature is not yet in Nexus 3. They are working on a simpler design as feedback on the feature in nexus 2 was that it was confusing.
This question is quite old; I hope this answer helps to document the new implementation or Nexus 2 "routing" in Nexus 3 "Content selector".
It's correct, Sonatype Nexus 2 "routing" capabilities have been substituted by "Content selector" in Nexus 3, based on JEXL queries.
Some notes are now available in Chapter 4 of Nexus Repository Manager 3.1 Documentation.
Basically you have to create a new selector from
Server Administration and Configuration -> Repository Content Selectors.
Define the JEXL query for your scope, e.g. the query below searchs for all path beginning with com/mycompany in maven2 repositories:
format == "maven2" && path =^ "com/mycompany/"
You can test your query using "Preview" buttun.
After that you go on more or less as in Nexus 2.
Server Administration and Configuration -> Security -> Privileges -> Create privilege
Give a name and description, select your "Content selector", select the repositories to apply the privilege and the action (comma separated list), e.g.
read,browse
Next create or modify a Role
Server Administration and Configuration -> Security -> Roles
giving the privilege you just configured.
Finally assign the role to the users you need.
Related
I'm actually managing a Nexus 3 instance for a multi-team compagnie and I want to dedicate some repository to some team.
To be more clear, I have a team A and a team B and npm, pypi and raw repositories for each teams.
Team A can't access team B repositories and vice versa
My repository names are : <team>-<technology>-<maturity>
Like : teamA-pypi-release
What I want to achieve is to create a role for each team that grant Read/Write access to each team repositories.
I don't want to create one privilege per repository (the target is to mange around 130 teams with each 3 to 4 repositories) so I wanted something simple that can use a wildcard like <team>-*, it seems that it's not supported in Repository View Privileges.
Did someone as any tips for this ? or some best practices for multi-tenancy Nexus ?
Maybe I'm thinking it wrong :)
Thanks
For those who have the same questions as me :)
I finally achieved this by creating one repository for all teams (can be duplicated like a release and snapshot repos...), then you need a content selector by teams to filter the view.
I’ve used the following query to filter, teamA example:
path =~ ".*/" or
format == "raw" and path =^ "/teamA/"
Then I’ve created a privilege by the team with the correspondent content selector with * as allowed actions.
And finally I’ve a role for each team with the following privileges:
My content selector privilege previously created
nx-search-read ==> Allow user to search artifacts from Nexus GUI
nc-component-upload ==> Allow user to upload artifacts from the Nexus Gui
With this, all users can browse and upload artifacts only in their dedicated folder.
The search and upload privileges are not mandatory if users don’t use the Nexus GUI.
One limitation is that users can see all folders at the root level but they can’t see ton content of them, which is not an issue for use.
Hope this help :)
I'm trying to get the netty-codec-hhtp going in my maven project. I have a completely standard Sonatype Nexus set up to proxy requests to Maven Central.
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http</artifactId>
<version>4.0.9.Final</version>
</dependency>
This fails when building using maven. If I search for it manually in Nexus I find it, but if I go to download the jar it tells me:
404 - Not Found
Automatic routing filter rejected remote request for path /io/netty/netty-codec-http/4.0.9.Final/netty-codec-http-4.0.9.Final.jar from M2Repository(id=central)
What does this even mean, why am I getting it, and maybe more importantly, how do I fix it?
I am using Nexus 2.5.0-04 with Maven 3.0.4
Downloading other artifacts seems to work just fine.
UPDATE: This turned out to be an issue with CDN configuration that should now be resolved. The steps below for forcing and/or disabling remote discovery are left for reference.
It means that Automatic Routing for Central is active, and that the discovered rules does not contain io.jetty as allowed prefix.
This should not happen, as the default configuration should update the rules on daily basis (as seen on screenshot below, showing the default Automatic Routing configuration for Central).
The remedy is to either force the update of rules (I did check, prefix /io is among rules Central publishes), or disable remote discovery completely.
Try steps as shown below on screenshot:
From Repository Management with Nexus - 6.4. Managing Routing:
Routing can be considered the internal activities Nexus perform in order to determine, where to look for a specific component in a Maven repository. The routing information has an impact on the performance of component retrieval as well as determining the availability of components.
(...) Automatic Routing is handled by Nexus on a per repository basis.(...)The Routing information consists of the top two levels of the directory structure of the repository and is stored in a prefixes.txt file. It allows Nexus to automatically route only component requests with the corresponding groupId values to a repository to avoid unnecessary index or even remote repository access.
Since Maven central repo contains that artifact I assume that the automatic routing rules forbids remote download for that artifact. The error message you posted suggests it also.
You can read how to add a routing rule under 6.4.2. Manual Routing Configuration. If my assumption is correct, this situation shoud be resolved by adding an inclusive rule type with ^/io/netty/.* route for central repo.
I faced the same issue when configuring a bridge between 2 Nexus.
In the first:
I added 2 proxy repo, targeting 2 public repo groups in the second,
then aggregate those 2 proxy repos in a new group,
that I finally added to the repo list of the first Nexus public repo group
Using the first Nexus, each time I requested a dependency only present in the 2nd, I encountered the Automatic routing filter rejected remote request for path... exception.
As mentionned by Tamas, this issue comes from the Routing >> Discovery feature that was enabled in my 2 proxy repos, that were targeting remote Nexus repository groups.
Once disabled, the issue was solved.
The exact explanation of this need is in some way explained in the official Sonatype documentation for Repository Management with Nexus, in chapter 6.4.1 on Automatic Routing:
The Routing tab for a proxy repository displayed in Figure 6.18,
“Automatic Routing for a Proxy Repository” contains the Discovery
section. It displays the Status and a more detailed Message about the
prefix file access. The Last run field displays the date and time of
the last execution of the prefix file discovery. Such an execution can
be triggered by pressing the Update now button. Otherwise, the Update
Interval allows you to trigger a new discovery every one, two, three,
six, nine or twelve hours or as a daily or weekly execution.
[...]
For a proxy repository, the prefix file is either downloaded from the
remote repository or a generation is attempted by scraping the remote
repository. This generation is not attempted for remote Nexus
repository groups, since they are too dynamic in nature and should not
be proxied directly. Scraping of hosted or proxy repositories as well
as Subversion-based repositories is supported.
Regards,
Thomas
I would like to understand how the indexing for the artifact repositories like Nexus and Artifactory works. What benefit does it provide? I mean -- how does it help and what is the logic that's used when resolving artifacts?
My understanding is that the Lucene indexes contain information concerning which artifacts are presents in a given proxied repository or group and that once these indexes have been downloaded, you can easily check if a remote repository contains the artifact you're looking for and you can try to resolve it from the repositories which have it. Is this the only use? Is the index also queried for local resolutions (because each repository does have an index)...? How does this actually work?
Artifactory doesn't use indexes for searching. We believe that indexes are the thing of the past, when machines were slow and couldn't handle large searches on the server side. Here is only partial list of why search indexes are bad:
Client need to download huge files before searching
The indexes are updated too rare to reflect frequent changes
System with search indexes requires special client to perform the search against
The client it toughly coupled with the index format.
Nowdays, when servers like Artifactory can provide real-time searching, exposed via UI for humans an API for tools like IDEs, the indexes are obsolete and supported in Artifactory only for compatibility with tools like m2eclipse.
Repository indexing is all about searching. The Maven Eclipse plugin documentation describes the functionality:
http://books.sonatype.com/m2eclipse-book/reference/repository-sect-repo-view.html#d5e1169
Maintaining a server-side index makes Maven client operation more efficient. Server-side repository managers can use indexes to enable search interfaces and REST APIs for retrieving artifacts (Sonatype Nexus doesn't need a database).
As Mark already said, Maven Index is all about searching (either server side, where search is exposed over UI, or using REST) or client side like for example M2E does (typical example is code completion in POM editor, where context hints uses index to provide you Gs, As and Vs while adding dependencies for example).
Nexus does NOT use index to fulfil it's main functionality: serving up artifacts and/or proxying them, while it DOES maintain the index on the fly. Again, indexes are not used in "resolution" or any other way, except for Search UI and downstream publishing reason (for clients like M2E is).
For example "client side" usage of Maven Indexer, you can look at the examples here.
HTH,
~t~
Do you know a way to configure Nexus OSS so that it publishes the artifact repository to a remote server in a form that can be statically served, e.g. by Apache Httpd? I'd like to use this static copy to serve only my own artifacts, so the nexus server could actively trigger an update in case there is something new published.
Technically, I think it should be possible to create the metadata for the repo and store them in a static file, but I'm not sure with that. Any hints appreciated.
If there is another repo manager to achieve that, it would be fine for me as well.
I clearly understand the advantages to use the repo manager directly, but due to IT rules I can run Nexus only internally and it would be necessary to have these artifacts available in a (private) repo copy on the Internet as well.
A typical way to solve this IT requirement of only exposing known servers like Apache httpd is to setup Apache httpd as a reverse proxy as documented here.
You can use that approach in a more restrictive way by only exposing a specific repository or better repository group (so you can combine snapshots and releases) and tying that together with a specific user or a specifically restricted setup of the anonymous user that is used by default when no credentials are passed through.
Also if you need more help feel free to contact us in the user mailinglist or on hipchat.
I have installed Nexus 2.0.6 and the integration with my LDAP server is working (authentication only). Is there a way to configure Nexus so that only a set of developers are able to deploy a given artifact, or group?
I basically do not want a developer in Team A deploying an artifact that Team B is reponsible for.
You may partition a repository using repository targets, privileges, and roles as described in this Sonatype blog post. I tested this a few months back and it seemed to work well.
Under Nexus 2.0.1, this is the solution that I've worked through and verified.
Caveats:
This allows one to restrict the "Artifact Upload" option to a directory hierarchy.
This is not quite the same as "deploy" or in conjunction with "release prepare".
Steps:
Remove the single privilege of "Artifact Upload" from all that presently have it, that you do not want to have it.
Create the "Repository-Target" that includes the directory mask of where you want to give access. Ex. .*/com/mycompany/target-dir/.* Double check the mask, it starts with period-asterisk AND ends with period-asterisk.
Create the "Repository-Privilege" that maps to the Repository-Target you just created. Typically I include the repo-name in this repository-privilege-name, like "releases.com.mycompany.target-dir". This creates the CRUD entries (4) for said directory.
Next, create the "Role" based on the Repository Privileges you just created (4), plus "Artifact Upload". Total of 5 entries for the role. Use the "Apply Filter" here to help you find these items. I name this role something like "Upload.Role.Releases.Target-Dir". Again, when finished there should be 5 entries for this role:
Artifact Upload
com.mycompany.target-dir(create)
com.mycompany.target-dir(delete)
com.mycompany.target-dir(read)
com.mycompany.target-dir(update)
This is what constrains the upload role to this repo.directory.
Create the User if it does not already exist, assign password.
Give the user the following Roles:
Nexus Deployment
Repo: All Maven Repositories(Read)
UI: Base UI Privileges
Upload.Role.Relases.Target-Dir
Hit save and you've got it. Later on, you can use this same approach to create a new Role for other repos (say Snapshot or 3rd Party), and keep the same directory mask.