I would like to migrate all the data from a OSS Nexus 3.19.1-01 to a Nexus 3.25.1-04 without service interruption (impossible to shutdown the Nexus 3.19 during the procedure)
I only find procedures for migrating from Nexus2 to Nexus3 and apparently the import/export solution will only work from 3.24 versions. Additionally it seems that this is only applicable to Nexus PRO versions: Link
The formats I need to migrate are: Maven2, docker, yum, raw, npm and nuget.
Is there any official procedure for performing this task?
Another ideas? Maybe API?
Check the links below, it might help you. But in all cases they recommend to shutdown Nexus so you don't have to deal with any integrity issues.
https://community.sonatype.com/t/nexus-to-nexus-migration/3608/3
https://support.sonatype.com/hc/en-us/articles/360010352014-Moving-a-Nexus-Repo-3-Installation-to-a-New-Location
Related
Does any one know how to install NebulaGraph on my Mac book?
I searched their docs but found only ways to install on Linux hosts.
NebulaGraph's core part assumed it's running on Linux distros only for now.
But we could leverage virtualization tooling in macOS to do so.
Options are like
Deploy in VMs with different hypervisors like (virtualbox, vmware player lima etc.)
Leverage Docker Desktop(or equivalent things like rancher desktop, then deploy it with Nebula-Docker-Compose, following this doc
note, the link for the doc is versioned(now, 3.3.0), for future ones who visit this, please choose the latest version in the documentation version drop-down menu.
I need to migrate an enterprise production database from a Windows source machine running Postgres 9.5 to an Ubuntu destination machine running Postgres 11.6 with < 15 mins downtime. I plan to do this with pglogical, which requires the extension being loaded on both source and destination. I am having trouble with the source side because it is Windows.
I have very little Postgres-Windows experience and can neither find any helpful literature on the specific situation nor can I figure out for myself how to presumably install from source.
I've dug and dug and so far the only answer I've been able to find is "ugh... Windows". It seems like the only way to build from source is using Visual Studio, which I don't have or know how to use.
Sources:
https://www.2ndquadrant.com/en/blog/compiling-postgresql-extensions-visual-studio-windows/
https://postgrespro.ru/list/thread-id/1835275
Alex, the 2ndQuadrant article you link to in your own comment solves this. A few of the project or build options noted there have moved a little bit in the newer VisualStudio Community editions, so I can see where you got hung-up.
Just for kicks I compiled 32-bit DLL on my oldest Windows instance. I included the /Release path so you can grab my DLL & see if it works for you. It's (a) 32-bit because I'm assuming worst-case for an old v9.5 install, and (b) targets Postgres 9.6 because that's what I had installed. Unless there were major API changes though, it should connect to v9.5 without any issues:
https://github.com/mbijon/winpglogical/tree/master
If you find you need a version that entirely matches Postgres 9.5, grab my solution files & VS Community 20xx. Load the project & update the Additional Include Directories in Project Config to target your v9.5 paths. That should be all that's needed to link v9.5 Postgres libs.
this is related to the last question I posted on the subject:
SBT Publish to Visual Studio Team Services (Web) Packages Plugin Repo
At the time I wrote that I was running SBT 0.13.16, and was able to make everything work.
My team has attempted since then to upgrade to SBT 1.0.x, and while for a while it seemed to work, it turns out that was only thanks to the cached versions of our libraries in ivy.
Attempting a clean setup using the same technique that worked in SBT 0.13.16 results in no attempt to send authentication information to the servers (and thus, no library download and frustrated devs); verified with Fiddler.
PUBLISHING does work and seems to make proper use of the credentials, but DEPENDENCY RESOLUTION does not, any longer.
Any idea what I'm doing wrong, or how I can replicate the old behavior?
Thanks!
Apparently this was resolved at some point before sbt 1.1.6.
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.
Do we have any cli/api to check openstack development version..i mean whether my system installed havana or grizzly.I searched the openstack cli/api docs but i don't find any relevant.
OpenStack has a number of elements if you want to verify state.
Each of the component projects and each of the python-client api bindings have their own versions. Then there are configurable options for addressing API versions in REST queries.
I took a crack at building an API for the very purpose of verifying this data as well as all python dependencies a while back with the aim of cross verifying that against a vulnerability database but I simply haven't had the time to bring it to completion.
This would be a very useful feature I think.
You might look at your pip requires if you installed from source. Alternatively you can follow the debian package version chain from dependencies and that should provide good insight into what is installed on your system though it's not exactly verified.