When I upgrade PTools, it forces we to create a new WebLogic domain. I would like to avoid this and have it upgrade the existing WebLogic domain instead. Has anyone else tried this before ?
With a higher version of PeopleTools it is possible that a higher version of Weblogic is required. With the new Weblogic installation, you need to recreate the domains:
PeopleTools 8.53 with Weblogic 10
PeopleTools 8.55 with Weblogic 12
Check Oracle support to see for which Weblogic version your new version of PeopleSoft is certified, it's possible you don't need to install new software (example from 8.52 to 8.53)
Within PSADMIN there is an option "7. Refresh Config Home". If your Weblogic domains are setup within the PS_CFG_HOME directory and managed through PSADMIN then this should redeploy your Weblogic domains with the same settings.
In my limited testing it seemed to work fine with a minor tools patch, such as 8.55.09 to 8.55.12. If I recall correctly it retained customizations in certain files, such as configuration.properties, and kept my custom files, but certain other files still had to have settings reapplied, like maybe integrationGateway.properties.
That said, I don't believe this is an approved method so you would probably want to thoroughly test in your own environment. I believe a full rebuild of Weblogic, even for minor patches, is still the recommendation. Additionally, I definitely would not try this for a major upgrade, such as 8.55 to 8.56.
Related
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.
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.
I've been using meteorjs for quite a while now on linux. But when I installed using the relatively new windows installer, I saw that the most basic example doesn't work on properly on my computer - win7.
The example is at: https://www.meteor.com/try/4
which runs perfectly on my ububtu, but on my windows - I see that no information is inserted into the db and all changes I make (add new "tasks") are only local to that page, and other tabs I opened were also local, and there was no "reactivity" (no information was shared between different pages).
I tried to troubleshoot it in some ways:
I made sure that MONGO_URL is not set, and then I set MONGO_URL to another db, and saw that even though that db reported "connection accepted", the oplog nor the collection updated (tasks) have any new information.
Tried different kinds of browsers (chrome, firefox). Both are latest in version.
See no errors in chrome console.
I am assuming that all writes are made to minimongo, which doesn't pass them on.
Is this somehow a known issue?
Any suggestions?
A few things you can try:
uninstall meteor & any separate instance of mongo (including cmd aliases). download a fresh copy & install. Create a new project in a new folder. If the DB had some weird bugged lock on it, this is sure to fix it.
download robomongo (or use meteor mongo) to insert a new doc & see if it sticks. If it does, you know mongo isn't the problem.
Check that autopublish and insecure are installed. If they are, when you complete step 2 you should see a new doc in the app. If you do, then the DB can communicate to the app, so the problem has to be with the client-side saving to DB. Try a meteor method instead of a direct insert. If you don't see a new doc, then the data from the DB can't reach your client, which means your firewall (yes, it can screw up localhost requests, too) is to blame. Turn it off, make sure ports 3000 & 3001 (mongo) are allowed full access & that it doesn't do anything wonky with websockets.
I would try re-installing Visual Studio 2012 and Python 2.6/2.7, then re-installing Node and then Meteor.
I have created a local version of my Drupal website to do dev work on. But when I add new modules to the local version they do install but they do not enable correctly. For example I added the legal module, enabled it, but when I go to site configuration to edit it, the legal section does not appear. Any help please?
The problem is that not enough memory will be allocated to the service to allow for new modules which require more memory to be ran, try putting
ini_set('memory_limit', '256M');
in the sites/default/settings.php file.
This is a really old thread but thought it was worth adding the following.
I had this problem recently on a local dev install (using Acquia Dev Desktop, by the way). Turning off the Memcache module resolved my issue.
I have a Windows 2003 Server with IIS, I installed VisualSVN Server on it.
I have two developers, who are going to use TortoiseSVN.
Since this is my first time ever setting up a SVN server I am kind of confused on how this will all work. The way I see it, each developer would have a copy of the repository on his or her local pc, would each person be required to have IIS installed on their PC as well to test their copies before checking out?
Should I create a testing folder on the server and then a production ready? It seems as if that would cause more issues with copies?
What would you do?
EDIT
I dont know what I was thinking, I forgot that VS has a built in IIS when you debug so the issue about setting up IIS on either client or server is now a non-issue. But I am confused, I imported the site into the repo, it said it was on revision 2 but I dont see any of the files in the repo folder. Do I create a virtual folder in IIS pointing to the repo that I created?
No, each developer uses your repository, and checks out their own copies to do their work. They do not need IIS or svn, etc, installed on their systems.
I recommend reading up on the Subversion FAQ.
Your devs don't have a local repository, they have a Working Copy on their PC. Typically, this is the most recent version of the app with whatever changes have been made by the developers but not committed yet.
As this is a web app, then your developers will need some kind of web server locally to test it - this could be IIS, or Visual Studio's built in web server (although that does behave differently to IIS in subtle ways).
You said in a comment: "My problem is I dont want the devs to commit to the live site in case there was a bug.".
The devs commit to the SVN repository on the server: at some point you will want to export (aka 'publish') a copy from the latest version in your repository to your live site. In order to make sure this works, you can check out a specific version from the server, test it, and if it passes the tests upload it: devs will always check in code with bugs (even though it builds) as it's better to check code in frequently than build up lots of changes locally then commit them, as there are bound to be conflicts with work other developers have done.
Branching and Tagging are useful concepts here: when you have a version which is almost right, you 'branch' it away from the main 'trunk' of the source code tree, fix any issues in the branch (back-porting to the main trunk as required), then when you have a working version you 'tag' it (as version x.y.z) and upload it. This way you can always refer to the particular version of the code you have uploaded, which makes it a lot easier to identify bugs which turn up in production. As others have suggested, read the SVN documentation for more info.
It depends on how you work. There are other discussions about folder structure and such which play directly into how you use version control.
Uh, no, no local repositories. Setting up SVN is easy, well almost. You'll want to look for the svn windows installer and set it up on the server. You'll want to install Apache and then you'll have a little hurdle setting up the http.conf file to expose svn over http. There's a little complexity with setting up security so go with Windows Authentication, you'll need WebDav, google it.
Once that's done, any svn client can hit it and checkout a copy and work with SVN normally. If you get really stuck, comment here and I'll go get a copy of our install and config for you.
The good news is that it's rock solid, once you get it setup it'll run forever.
"Pragmatic Version Control Using Subversion" and the SVN red-bean are the two sources you need to see.
Set up SVN on a single server and have all your developers point to it.
I've installed tortoise on the server and do Updates / Checkouts of the release website. Some people don't like checking in compiled code, but I like having the production compiled site in SVN.
If you use tortoise on the server, Do the initial checkout to the inetpub/website directory and then on rollouts you just need to update the directory using tortoise->update
Of course checkin to rollout is considered bad practice without first rolling out and testing on staging servers, but depends on your team size.
I have used the following resources for learning SVN:
http://www.polymorphicpodcast.com/shows/subversion/
http://www.dimecasts.net/Casts/ByTag/SVN
Found both quite good, and learning by watching can be easier especially for getting started.
No - your central server will maintain the repository. Your developers will get copies of the repository, make changes, and then commit them to your repository.
You actually have quite a few things to figure out if you want to do a successful deployment of subversion.
One really good article about setting up subversion on Windows - https://blog.codinghorror.com/setting-up-subversion-on-windows/
No, SVN server must be installed on a single computer. Each developer point at this computer and get locally (and eventually) a full copy or a partial copy of the repository.
You may also buy a book from O'Reilly about Subversion. Don't remember the title, sorry, but it helps me a lot.
All the best ! Sylvain.