"Your web application is not configured to serve the JSS web interface" message when upgrading JSS 9.81 > 9.96

dlondon
Valued Contributor

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

1 ACCEPTED SOLUTION

dlondon
Valued Contributor

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:

  1. Stop the tomcat server (sudo /etc/init.d/jamf.tomcat8 stop)
  2. move the ROOT folder aside ( sudo mv /usr/local/jss/tomcat/webapps/ROOT /usr/local/jss/tomcat/webapps/ROOT.bak )
  3. restart the tomcat server (sudo /etc/init.d/jamf.tomcat8 start) and allow couple minutes to unpack the war file
  4. You can check on progress probably in a smart way but I just did a: du -sh /usr/local/jss/tomcat/webapps/ROOT
  5. go to the web page https://my_test_server_ip:8443 and if prompted for the database connection info (which you will be if the database is not local) enter that info.
  6. Once you feed it that info the app should update the database structure and finish at the logon page

Regards,

David

View solution in original post

2 REPLIES 2

dlondon
Valued Contributor

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:

  1. Stop the tomcat server (sudo /etc/init.d/jamf.tomcat8 stop)
  2. move the ROOT folder aside ( sudo mv /usr/local/jss/tomcat/webapps/ROOT /usr/local/jss/tomcat/webapps/ROOT.bak )
  3. restart the tomcat server (sudo /etc/init.d/jamf.tomcat8 start) and allow couple minutes to unpack the war file
  4. You can check on progress probably in a smart way but I just did a: du -sh /usr/local/jss/tomcat/webapps/ROOT
  5. go to the web page https://my_test_server_ip:8443 and if prompted for the database connection info (which you will be if the database is not local) enter that info.
  6. Once you feed it that info the app should update the database structure and finish at the logon page

Regards,

David

Isgjamfservice
New Contributor

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.