I’m running Nexus OSS 3.64.0, and am wondering if I can monitor for available updates to Nexus itself? The UI does this when I log on and take a look, so I’m trying to do the same thing in my monitoring platform.
My monitoring platform (CheckMK) can run arbitrary scripts to perform checks. I’m trying to make a script that will send me an alert if there’s a new version of Nexus that I should install. I was hoping some part of the Nexus API would tell me if it was up to date, but I can’t find such thing anywhere. Is there a way?
Failing that, are there any other ways I could do this? Perhaps something something at download.sonatype.com that I could query?
If I change the version numbers in that URL to something else, the content includes the “new version available” content. However, the HTML is all but unparseable - it’s got hidden content for all sorts of things in it, which (I assume) some Javascript unhides where it’s required. That’s going to be pretty much impossible to use for this purpose
I assume Nexus makes some sort of requests to Internet servers to get the content shown in this frame, but I don’t seem to be able to get the details of it.
@ralph.bolton Your request makes sense, you’re looking for an API that tells you when a Repository instance can be updated. The HTML content you’re parsing comes as a chunk from our CDN, it’s not produced locally by Repository as a result of REST calls that the server is making. I’m making a note of your request to see if we can garner additional requests for it.
My ideal outcome here would be some sort of endpoint, or callable script or something I can get a ‘status’ from. That status would tell me if an upgrade was possible (ideally tell me the version now available). Also, ideally set a flag or tell me that there’s a critical vulnerability in my current version. For example, if I ask about version"1.1.1", I’d get a response like this:
From this, you can imagine how my monitoring will work. I’d look to see if there’s a bug fix release, and just report this was available if there was (in “OK” state). If there’s a minor release, I’d report this and switch to “warning” state (so it sends an alert). If there’s a major release, then switch to “critical” state, so there’s an alert. If there’s ever a ‘critical_update’, regardless of the version number, then report it as a “critical”. For any “critical” issues, internally there’s an alert and some work has to be done to resolve it.
Not sure how you’ve got Nexus installed, but if it is on Windows and you use Chocolatey to manage the installation you could run choco outdated to see if there is a new version on our Chocolatey Community Repository. The package is auto updating and typically is updated within a day of the release of a new version.
Then it’s just a choco upgrade nexus-repository -y to bring it up to the latest release.
@steviecoaster - that looks like a good solution. Sadly, not possible with my Linux install (where it’s installed via a zip file downloaded from Sonatype).
What you describe is my usual go-to though (essentially, to ask a package manager) - Nexus is the one time I can’t do that though.
I maintain the nexus-repository package on the Chocolatey Community Repository. It’s an automated package so I don’t have to touch it ever. I use the Github Release as the source of truth for a new version.
which will yield just the version number, which as of this writing is 3.64.0-04
This only gets you part of what you’re asking for, but it’s at least closer in that it will tell you “hey this is the current version”, which you can compare to your installed version.
@steviecoaster using Github’s releases is a good idea (in lieu of a solution in Nexus itself). Thanks for the tip - I hadn’t thought about sniffing around Sonatype’s github…
Ultimately, it’s a matter of fetching https://api.github.com/repos/sonatype/nexus-public/releases/latest and looking to see if the release version is different than the current one. The version number isn’t explicitly available, but just like your code does, it’s easy enough to parse it out of something like "name": "release-3.64.0-04", in the Json the endpoint returns. So long as releases always follow the same pattern, it’ll be absolutely fine.
This will do nicely for the time being - at least it’ll be a lot harder to let umpteen releases go by without noticing. Thanks for the tip!
They’ve been following that pattern for years now, so I don’t see any reason why they’d change anytime soon. But that’s why we monitor our monitoring eh?
Hopefully they’ll expose an API in the swagger eventually for this but until then I’m glad you’ve got something you can work with!
