I'm planning to upgrade Nexus 3.15.2 (containing nexus2 proxy repos running in same server as different instance) to 3.26.1
Thinking to follow https://support.sonatype.com/hc/en-us/articles/115000350007-Upgrading-Nexus-Repository-Manager-3, but this doesn't explicitly say any thing on existing nexus2 proxy repos.
Would like to know upon upgrading from 3.15.2 to 3.26.1 will there be any issues to existing nexus2 proxy repos? or after upgrade of 3.26.1, should I need to once again undergo enabling 'Upgrade capabilities' followed by perform 'upgrade by choosing nexus 2 repos' from Nexus 3.26.1 to restore those proxy connections for accessing those artifacts?
All your proxies should remain intact in the upgrade.
Note, if you have any doubt carefully review the release notes and try in a testing environment. We recommend this for big upgrades anyway, such as yours, over 10 versions difference.
And always recommend backup before any upgrade as well in case it goes awry.
Related
I have an existing JFrog/Artifactory Pro 7.27.10 RPM-based install (on a CentOS 8 VM) that I recently migrated to a new (Centos Stream 8 VM) running JFrog/Artifactory Pro 7.31.13 (also installed via RPM).
After copying my existing master.key file from the original JFrog install to the relevant directory, I started up the Artficatory Pro service on the new VM and proceeded to migrate my data using the "Simple migration with downtime" process described in this JFrog whitepaper. Everything worked fine, Artifactory is running as expected on the new VM and all my data appears good. I moved my frontend proxy DNS aliases over to the new VM and shut down the proxy on the old VM.
One problem I am now noticing is that in the Artifactory admin UI, the Monitoring > Service Status now doesn't appear to report my Artifactory/JFrog platform microservice status any more. It does show Artifactory with the correct backend IP address (running on port 8082) but then the "Status" shows "Online" with (0 of 0 nodes) and the ">" fold down arrow shows nothing when clicked. I went back to my old Artifactory instance and checked and it was still showing the single node with all of the individual JFrog platform service statuses properly.
My guess is that I missed something in the migration process and/or something else needs to be configured to allow the services to show up on the monitoring page, however I'm at a loss as to what this is or even where to look for it. I looked through the system.full-template.yaml but nothing seems obvious there. And while the Artifactory docs are usually fairly comprehensive, the page about monitoring doesn't seem to give much insight about how this is configured or what to do if it's missing. Also not sure if the initial startup of Artifactory on the new VM before I migrated by data affected how the monitoring was configured such that it now doesn't work with the imported data (unfortunately I didn't check the monitoring UI in the new VM before I did the data migration so I can't say for sure if it was initially working)
A couple of other details which may be relevant:
when migrating my VM, I kept the same (FQDN) hostname, but the IP address was different
I used the same frontend (nginx) proxy configurations on both the old/new VMs though I'm not sure if this is relevant here or not.
With the exception of going from CentOS 8 to Stream 8, the VM configurations themselves should be nearly identical as I create them from a kickstart (which was only updated for the new stream repo paths). Again not sure whether this is relevant at all here.
Any ideas on where I should be looking to figure out how to fix this?
We want to upgrade Artifactory OSS version from 5.4.4 to latest 7.15.3. Is there documentation for how to proceed? And can upgrade be done directly between these version, or is intermediate upgrade necesssary first?
The OSS version behaves pretty much the same as the Pro when it comes to upgrading. You should follow the official documentation. In general, you will want to upgrade to 6.10.0 and then you can upgrade to the latest 7.x.
The upgrade to 6.x should not result in any major changes but the final upgrade to 7.x does have big changes you should review. The most obvious is that the application now needs two ports to run (8081 and 8082). If you have a reverse proxy, that will need to be updated when you jump to 7.x to accommodate this change, as well as potentially having to modify firewall rules.
I have an app that's been running on MariaDB 10.1.41 for a while now. Recently a dev database was upgraded to 10.2.33, and now it won't allow us to use self-signed certificates for SSH. We need inter-server communication for replication, and up until now these certs have been fine.
I've been trying to find out what in this upgrade might have caused this, but everything I've been able to find so far suggests that self-signed certificates probably shouldn't have worked at all.
We did have some other issues following the update - mostly caused by strict mode being enabled by default - these have been resolved, but I've been unable to find anything suggesting why our certs no longer work.
so i just started working on a project, and my task is to upgrade sonatype nexus 1.9.x running on CentOS6 to 2.11.x. The old version is currently deployed via a war file. The goal is to get the new version deployed while not breaking builds when devs try to build their project.
My plan of attack is to download nexus. Make the current nexus that is deployed via tomcat, run on a different port, make the new nexus run on the current port, then proxy the old nexus.
Im running into a couple problems though. the old nexus uses java 1.6. If update java to 1.8, would this break the current running nexus?
Would I be able to run two version of nexus on the same vm? If so, how would i do that and minimize the change of messing something up?
Thanks everyone. Im just starting out and this is all very new to me.
Since you Nexus install is very old you have to consider your options:
You could upgrade the existing instance. 1.9 is VERY old so you have to upgrade in multiple steps. First to 2.0, then 2.7 and then 2.11. This is necessary due to data storage changes for configuration and removed upgrade steps.
You could just reconfigure a new server from scratch with the same configuration in terms of repositories and other things and simply rsync the repsitories over to the new storage. You really only have to do this for hosted repositories since the proxy repositories will hopefully still be online and you will just download whatever is requested anew.
If your setup is not too complex I would personally go with option 2. It gives you a chance to revisit things and clean up your setup.
For that setup the steps are roughly.
Install Java 8 in parallel to Java 6
Install Nexus 2.11 from the bundle so it runs with Eclipse Jetty. Do NOT try to run on Tomcat.
Configure it to run on port 9081 or some other non-conflicting port with your original setup and do all the other config including creating the repositories as desired as well as security setup.
Now you should be able to have both servers running.
Create a script that rsyncs the repositories (located in sonatype-work/nexus/storage) and run it with the new server offline
Start the new Nexus in parallel and run a number of tests against it.
Once you have confirmed everything is working plan for a specific time for the cutover and do this
Disable any deployment to Nexus (CI servers, tell people, switch hosted repositories to read only)
Run the rsync script one last time
Turn the old Nexus server off
Configure the new server to use the port of the old one
Start the new one up
You are done. Everything should be good now so the last step is to delete the old Nexus and Tomcat setup.
There are various variations for this process of course. Here are some tips for the rsync.
Also feel free to ping us on the mailing list or chat for further help and check out the comprehensive documentation as well.
Why do I ask:
the server (Ubuntu 14.04) does not only run gitlab but other services (based on node.js) for testing purposes (I only got the one server)
therefore I want to configure mainly nginx and other gitlab-omnibus dependencies the way I am used to
I have to migrate from a manual installation (7.3 MySQL) to a [manual|omnibus] based one
(MySQL won't be used any more unless GitLab will be configured so for any reason you might wanna give me regarding migration)
Since you have a fairly recent Ubuntu, you could consider building a GitLab container image, using Docker.
It scripts a manual installation into an independent light-weight VM (a container).
That way, you can isolate your GitLab setup from your other services, and easily replicate that setup.
An omnibus setup is about installing the full stack needed to run GitLab (ruby, nginx, mysql, ...)