I have inherited two Nexus Repo servers, both running CentOS 7.4, one with access to the internet, and the other which is on an air gapped network (AG) with no internet access. I’ve recently updated both Nexus servers from version 3.5.x to 3.14.x. Everything seems to be running fine, our developers can still perform all of their builds, etc on the AG Repo server.
The Nexus repo with internet access (UDEV) is where I pull down new Maven and NPM artifacts and install into the appropriate repos. The Nexus repo server on the AG network has a central/public repo which is a mirror of our UDEV repo and a local/private instance where our developers have their private repos (snapshots, releases, etc). The local repo has proxies to the central side so the developers have access to all of those shared artifacts.
Please keep in mind that all of this was configured by someone else and handed off to me and I don’t know a lot about NXRM in general. So, previously on NXRM 3.5 to perform artifact updates on the AG server, which has no internet access, I would do the following:
On the UDEV Repo server:
- run the backup task in the NXRM gui
- stop the nexus service
- tar up the blobs directory
- start the nexus service
- move those .bak files and the tarball of the blobs to the other Repo server on the AG network.
On the AG Repo server, performed on the central/public repo:
- stop the nexus-c (central/public repo) service
- remove everything (.bak files) in the nexus3/backup directory and the nexus3/blobs directory
- remove /nexus3/db/accesslog,analytics,audit,component,config,security directories (6 total) * I understand these are the directories backed up when using the db backup task in the NXRM gui?
- extract the .bak files to the nexus3/backup directory (these will populate the nexus3/db subdirectories, correct?)
- extract the blobs tarball into nexus3/blobs directory
- start the nexus-c service (central repo that was just updated)
The above process on the previous NXRM 3.5 version has worked fine for about a year and a half.
Has anything changed with the db directory contents with RXRM 3.14 or has the NXRM db backup task changed? The process listed above does not work any more. The first time I followed the above process on our new NXRM 3.14 AG Nexus repo, the central/public nexus service would not start, in fact it looked like it was trying to upgrade again. There were errors in the nexus.log regarding upgrades to config, component, and the other directories in the nexus3/db directory. I’m assuming this is because there were files missing in the nexus3/db/subdirectories because I previously removed them? I noticed that there were not many files in the nexus3/db subdirectories after unsuccessfully starting the nexus service. I compared it to a tarball that I created of everything under nexus3/db/ prior to doing this update.
What I did to make it work was instead of using the .bak files from my UDEV server I just tarred up the nexus3/db/accesslog,analytics,audit,component,config,security directories and extracted those into the nexus3/db/ directory on the AG Repo server. I left the OSystem directory and the other two files alone. The nexus service started successfully and it didn’t try to upgrade anything. Is it okay to just tar up those six directories (on UDEV Repo server) from nexus3/db or should I use the NXRM backup task from the gui to back up the contents of nexus3/db? What else does the backup task do?
Should I continue to use the NXRM backup task, but then on the AG Repo server, mabye instead of removing the 6 directories in nexus3/db maybe I should just use the .bak files and let them overwrite the files it cares about in nexus3/db?
What’s the best practice or recommended way to move repositories and the blobs to an air gapped Nexus Repo, with NXRM 3.14?
Sorry for all of the info, I went with more vs. less.
Thanks!
Kris