Hi All,
We’re currently PoCing sonatype nexus and I’m trying to understand if it can help on our usecase.
So we have an apt server where we are uploading several debian packages very similarly to archive.ubuntu.com, let’s call it onprem-archive
To keep it simple, lets say this onprem-archive only has 1 distribution (mydist) and 1 package ( mypackage)
At start (timeA) we have 1 Release file that looks like this
mydist->mypackage->version1.0
Similarly to the official archive.ubuntu.com, the onprem-archive when it releases a new version of mypackage the Release file gets updated, a new version gets uploaded, and the previous version gets deleted, which looks like this (timeB)
mydist->mypackage->version2.0
I have 1 nexus sonatype server that points to this onprem-archive , its configured as a debian proxy configuration, with a cache of -1 because I want to keep all the versions of mypackage, it has a metadata time of 1 hour.
Now here is the question.
Assuming at timeA, I go and install mypackage(1.0) via nexus, it means that nexus now puts it on its storage blob and the nexus has now cached mypackage
I repeat the same at timeB, so now I should have mypackage (2.0)
If I understand correctly, if I do timeA, then later on timeB, I should have mypackage(1.0,2.0) on nexus, but what happens to the release file? Does nexus creates its own release file? or does it just caches the one on onprem-archive and serves that?
The specifics vary for different ecosystems, but general, Nexus makes its own metadata, index, or release files of this sort. There are a few reasons:
Sometimes these files refer to the binaries with absolute URLs, which Nexus needs to rewrite so clients will request them from Nexus instead of bypassing it.
If a binary goes missing upstream for whatever reason, Nexus needs to be able to relay that it still exists in the local cache. These must be merged into the list of what’s available upstream.
This last scenario is similar to group repositories, where the indices from multiple member repositories need to be merged and represented as a single list.
Is there some particular behavior you’re hoping for or concerned about?
The behavior I would like is to be able to keep several artifacts that the upstream has long removed.
and I wanted to verify that the metadata cache under the proxy repo configuration wouldn’t affect the Release file that nexus serves after a package has already been cached.
In this case, if I understand correctly, the nexus proxy apt creates an internal Release file, then it also Fetches the upstream Release file, then it merges them both and serves the new merged Release file as part of an ‘apt-get update’ ?
Under that case with the same scenario layed out,
if I’m on timeA, with my package already cached by nexus
and the metadata cache expires , and it (nexus-server) notices that onprem-archive has a new version (2.0)
then nexus gives both versions to be available(1.0, 2.0) on the ReleaseFile ( one to serve from local storage, one to first fetch from the upstream then store on local storage )
Sorry for the several questions under the same response. I appreciate your input.
Currently, our APT proxy does not make local metadata (unlike we do for most other formats). This is documented in JIRA as NEXUS-20476. As a result, for APT specifically, packages that go missing upstream don’t get served from a Nexus proxy.
Hello, has this issue been transferred to the Github issues ? I could not find it.
We’re using Nexus APT repository for more than 3 year, and I’m using a script that parse data from the proxy and create/send it to a hosted APT proxy. It allows me to switch to the hosted repository if data goes missing from the upstream. This happened before with 3rd party provider such as Ondrej for old versions of PHP.
What’s the use of an APT proxy if it does not provide the caching functionality ?