Posted on 11-17-2016 12:01 AM
Hi,
I've set up a couple of Red Hat Enterprise Server (6.8) VM's to mimic our real VM's for testing before we do a JSS 9.81 to 9.96 upgrade. One server is the Database server and the other is the JSS. The Database Server has MySQL Community 5.5.3 installed.
I've successfully installed JSS 9.81 on one VM with it using the Database server for the JSS database. Everything looks good. Web App is running fine.
I then try to do the upgrade using the linux installer and that all appears fine as well - no errors. I get this message on the command line at the end:
The JSS has been installed.
To complete the installation, open a web browser and navigate to https://is-04155-vm1:8443.
The time it takes to upgrade depends on the version you are upgrading to and the size of your database. Do not restart Tomcat during an upgrade.
I then go to my web browser and connect to the URL with the machine IP which is what I was using before - https://jss_ip_here:8443 but all I get is a message:
Web Application Configuration
Your web application is not configured to serve the JSS web interface.
There are two possible causes of this: The web.xml file has been modified to disable this interface The web.xml is corrupt
I've compared the web.xml file with the previous one and they are identical so I'm scratching my head over the message.
I had tried this before but without the Database on a different machine and the upgrade worked then. Perhaps that's a clue but it's not clear yet.
Any suggestions or ideas would be greatly appreciated.
Regards,
David
Solved! Go to Solution.
Posted on 11-22-2016 12:43 AM
Well I guess it was a bit tough :) I contacted JAMF support and received some really good help.
The solution to this was to stop the tomcat server, move aside the ROOT directory in /usr/local/jss/tomcat/webapps, restart Tomcat and let it recreate the content from the ROOT.war file in the webapps directory. I waited a few minutes for this and then saw that the size of the new ROOT directory was 157M compared with 31M for directory that was suspect. That was the directory that was created in the upgrade. Once I go to the web page https://my_test_server_ip:8443 the web app prompts for the database connection (because it can't find it locally) and I give it the info on the other server hosting the database. After that it chugs through converting the database for the new version and eventually ends at the logon page.
So for those playing along at home the procedure for unpacking the ROOT.war file once again is:
Regards,
David
Posted on 11-22-2016 12:43 AM
Well I guess it was a bit tough :) I contacted JAMF support and received some really good help.
The solution to this was to stop the tomcat server, move aside the ROOT directory in /usr/local/jss/tomcat/webapps, restart Tomcat and let it recreate the content from the ROOT.war file in the webapps directory. I waited a few minutes for this and then saw that the size of the new ROOT directory was 157M compared with 31M for directory that was suspect. That was the directory that was created in the upgrade. Once I go to the web page https://my_test_server_ip:8443 the web app prompts for the database connection (because it can't find it locally) and I give it the info on the other server hosting the database. After that it chugs through converting the database for the new version and eventually ends at the logon page.
So for those playing along at home the procedure for unpacking the ROOT.war file once again is:
Regards,
David
Posted on 04-02-2019 04:12 AM
Yes, this solved the issue to me too!!! After upgrading the DMZ server, the webpage was stuck on database connection on the same old ip address (previously i changed the main server ip address). I tryed to change the ip on the database connection webpage on the dmz server without success may times.
Reloaded the ROOT war for apache fixed the issue and the page loaded on localhost and not on the old ip address, and the Jamf Pro console web page loaded correctly.