Q/A Does Sonatype Nexus Repository no more support any non pro version?

[iamraj007]

Asking as could not find clear answer.
Does Sonatype Nexus Repository no more support any non pro version?
As standalone version with embedded database(orient) have known issue and external PostgreSQL database dont seems to be configurable in old versions ?

So is there any supported non Pro version?

[fargue]

I'm wondering the same. Is there no way to install the OSS version via the new helm charts?

[florian-besser]

I came here from the previous OSS helm repo: https://github.com/sonatype/nxrm3-helm-repository/tree/main/nexus-repository-manager, which is now archived.

How does this repo achieve the same as before? The readme under https://github.com/sonatype/nxrm3-ha-repository/ clearly states that a pro version is required, thus it seems removing the OSS aspect of the helm chart entirely?

Is this an incorrect documentation issue or was this a deliberate change?

if it was a deliberate change, what is the recommended repo to use for OSS helm charts going forward?

[Meissnerim]

I was wondering the same thing. I was using the OSS version for myself and labs. If this isn't possible anymore, there is no reason to recommend any version (not even the pro) to my customers.

[iamraj007]

I was wondering the same thing. I was using the OSS version for myself and labs. If this isn't possible anymore, there is no reason to recommend any version (not even the pro) to my customers.

Exactly they are forcing user to use pro version as anything else don't seems supported anymore and they don't seems to care if people switch to alternative as pro cost 12$/per user which might not be recommended because of number of user or simply to many other alternative tools.

[florian-besser]

What other tools would you recommend? Other people asking the same question and discovering this thread might profit from recommendations.

I've looked at JFrog Artifactory as an alternative and found their OSS support to be basically unusable for our usecase (NPM packets).

[narek01]

Well, the fastest and easiest way to run OSS-version with this chart is to deploy it and edit the StatefulSet manually cutting -Dnexus.licenseFile=${LICENSE_FILE} from INSTALL4J_ADD_VM_PARAMS environment variable.

[ideastation-x]

Is there a plan to release the official Helm Chart OSS version after this ?

[mpiggott]

Unfortunately Kubernetes doesn't always allow for the graceful shutdown of pods which can lead to corruption on embedded databases.

[florian-besser]

K8s absolutely allows for graceful shutdown, see e.g.:

• The official Google blog: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace
• The official docs: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
• Helpful blogs: https://learnk8s.io/graceful-shutdown

But I'm not sure why K8s graceful shutdowns play a role here. All we would need is a OSS version that can be tied to an external DB and we're good to go. An internal DB is nice for quick setup & playing around but probably a poor idea for a production rollout. This is where an external DB would make sense, which many many other OSS tools support without any fuss.

[rei-izumi]

After too long, I have understood the difference:

• nexus-repository-manager chart deploy the OSS version with an embedded H2.
• nxrm-ha chart deploy the PRO version with an external PostgreSQL.

Nexus people says that the embedded database is too dangerous when making updates and that is why they have deprecated the original and moved to the ha version.

As indicated, you can modify the values to deploy the OSS removing the -Dnexus.licenseFile=${LICENSE_FILE} and adding -Dnexus.loadAsOSS=true, but OSS is NOT compatible with PostgreSQL,
Because of this, you also have to remove the PostgreSQL variables to avoid an error when starting:
-Dnexus.datastore.nexus.jdbcUrl=jdbc:postgresql://${DB_HOST}:{{ .Values.statefulset.container.env.nexusDBPort }}/${DB_NAME}{{ .Values.statefulset.container.env.jdbcUrlParams }} -Dnexus.datastore.nexus.username=${DB_USER} -Dnexus.datastore.nexus.password=${DB_PASSWORD}

This turns the ha into the original, with the same database problem. So they neither can accept the proposal nor can they create a solution.

So, the OSS users have 2 "real" options:

• Deploy the original nexus-repository-manager, updating the image.tag with the latest image version (indicated in the Artifact for example). Simpler and more automatic than deploying the new one with the patches. Of course, you have to accept the database corruption risk (in 3 years updating each month I have never seen it, maybe I have been lucky?).
• Switch to your cloud artifact repository or GitHub/GitLab registries. Being realistic, if I have to pay for the maintenance of the Nexus service + PostgreSQL + the PRO license, I lose money comparing with the other options, and I also have to maintain/update the Nexus.

I hope it helps to save time for the next person.

[mpiggott]

But I'm not sure why K8s graceful shutdowns play a role here. All we would need is a OSS version that can be tied to an external DB and we're good to go. An internal DB is nice for quick setup & playing around but probably a poor idea for a production rollout. This is where an external DB would make sense, which many many other OSS tools support without any fuss.

Note the documentation mentions Kubernetes waits for a grace period if shutdown exceeds the grace period then step 5 occurs and the container is killed which can lead to corruption.