Move away from ROOT.war deployments

[jeroen]

As we now have multiple dashboards (frontend, snack, advertisement, snackdemo, etc) for the upcoming deployment and they are all supposed to use the front-end for authentication, we should no longer be deploying the front-end as ROOT.war.

This has been a source of trouble for dashboard creators (i.e. me) because resources in the ROOT.war can conflict with other tomcat applications deployed on the server. It is better to deploy the front-end at e.g. /admin or /ohmage or /frontend.

This is a minor change but can save us a lot of trouble. Instead of the front-end, the root of the server / could either host a redirect to /admin or display a list of dashboards and front-ends available on the server.

[jojenki]

What are some of the issues that it is causing? I am not necessarily opposed to this, but it does feel like our dashboard would logically be at ROOT.

Edit: See #462

[stevenolen]

Alright, someone smack me. After the GWT code is compiled for our frontend, isn't it just static content? If so, we should merge this with a change to how we serve static content on these servers (ie. run nginx as a reverse proxy for tomcat requests at /app, with static content served directly from nginx.

This should result in a significant decrease in page load times (at least at scale). It also makes seperate dashboards a much cleaner affair.

[stevenolen]

Also, I think this and #462 are duplicates, or at least similar enough not to need 2..

[jojenki]

This issue almost certainly doesn't belong here and definitely not under 2.14.

As a note, it does appear that GWT compiles everything into static content. There are a few JARs being packaged with it, but I don't believe they are necessary. I deleted them on my system, restarted, and everything still appears to be running.

[hongsudt]

I totally agree with John that this is definitely not 2.14. Whatever change we make need to go to testing first. On Feb 15, 2013 6:49 AM, "John Jenkins" notifications@github.com wrote:

This issue almost certainly doesn't belong here and definitely not under 2.14.

As a note, it does appear that GWT compiles everything into static content. There are a few JARs being packaged with it, but I don't believe they are necessary. I deleted them on my system, restarted, and everything still appears to be running.

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageServer/issues/517#issuecomment-13609715.

[jshslsky]

It would be good to at least try out nginx as a front-end to Tomcat.

See also cens/ohmageServer#305.

Issues that I foresee:

• SSL must be handled by the web server
• static content must be hosted by the web server
• the build process for the main front-end has to change (and probably other front ends)
• the installers have to be upgraded
• file system changes

[stevenolen]

This definitely wont affect the installers (if you mean @jeroenooms installers). He is already using apache in this fashion, and because his installer expects ohmage-viz as a component, will continue to require apache (which opencpu uses for mod_R).

[jojenki]

The front end was originally built to be at /MobilizeWeb, so, while it's definitely worth testing, it probably won't need many, if any, changes.

I don't think static content must be hosted by the web server.

Any FS changes should be heavily documented and probably should be changed to not have those sorts of impacts.

[jeroen]

Deploying stuff as root.war means that nothing else can be hosted on the server. In contrast, all other apps are deployed under subdirectory on the webhost, e.g. /app for the api, have a clear namespace.

One example: my local development server has a directory /images which I use for several purposes. However, the front-end also includes a directory images. When deploying the front-end properly as MobilizeWeb.war this is no problem, because the dir is namespaced at /MobilizeWeb/images or whatever. However, when using ROOT.war, then both my local webserver and the front-end want to use the /images root directory.

I post this at 2.14 because it is one of those things that is obvious and a minor change, but becomes harder and harder to change over time once it becomes conventional. Initial hacky solutions becoming a permanent liability is a recurring theme in our project. Once other dashboards starting linking to the front-end for the login screen, moving the front-end to a different location is going to be harder as we progress, and turn into a major breaking change.

FYI: the installation packages have been using /ohmage as the location for the front-end and I have done a lot of testing with this, and it works absolutely fine. We can change it now with nothing breaking at all. I think we should change it now because of the introduction of the universal login screen in this release.

[jshslsky]

I think the reason we rooted the front-end at / was because people just wanted to navigate to e.g., test.ohmage.org.

Can we just handle this on a per-deployment basis? It seems like in some cases we need ROOT.war and in other cases we need e.g., ohmage.war.

In the next Mobilize rollout, will they be using the snack dashboard @jeroenooms @hongsudt ?

[jojenki]

I think we should handle that at the web server level. Just have "/" redirect to whatever the primary endpoint is for that deployment / machine.

[jshslsky]

Right, but we do not use a web server. Yet. :door:

[jeroen]

I think the reason we rooted the front-end at / was because people just wanted to navigate to e.g., test.ohmage.org.

It is absolutely fine to make simple 301 redirect that sends people that navigate to test.ohmage.org to test.ohmage.org/frontend. That way nothing changes in the user experience, and there are no conflicts.

Can we just handle this on a per-deployment basis? It seems like in some cases we need ROOT.war and in other cases we need e.g., ohmage.war.

No this will result in problems. Third party dashboards will redirect users to the front-end for authentication. If there is no conventional location for the front-end you are going to have to reconfigure all of your dashboards for where they should send the client for authentication which is a major and avoidable headache. Just like all the dashboards will have to be changed when you decide to move the server from /app/ to /somethingelse/.

We are currently in the position that we can still really easily determine a conventional place to host the frontend that works for everyone. Or we can keep with our hacky solution and get ourselves in trouble once people want to host the front-end on a server that has other purposes as well, and have to start modifying all the dashboards to reflect this change.

In the next Mobilize rollout, will they be using the snack dashboard @jeroenooms @hongsudt

Yes, and it will be using the new universal front-end login for authentication because hongsuda wants to keep the branding consistent.

[jeroen]

I think we should handle that at the web server level. Just have "/" redirect to whatever the primary endpoint is for that deployment / machine.

I will gladly help you create a ROOT.war that does just that and nothing more. But I think steven can also configure this in the tomcat settings.

[jshslsky]

I asked John to take a look at this because your previous comment contains a very simple fix. I think you can also do this in server.xml.

[stevenolen]

Yup. it's a single context line in the tomcat server.xml...

I've made the change on lausd.mobilizingcs.org and removed the ROOT/ and ROOT.war. No effects so far...

[jeroen]

Please note that my test server on https://lausd1.mobilizingcs.org/ is already hosting this sort of configuration. Currently the index page hosts a dull html page, but it could also host a redirect to to the front-end, or a really cool page listing which dashboards and front-ends are available or so.

[stevenolen]

Changing the context doesn't resolve the issue, as it just maps / to /web. We'll need to have a new /ROOT dir that does this:

Open your /webapps/ROOT/index.jsp and add this line:

response.sendRedirect("/frontend");

[jeroen]

Or you can create a /webapps/ROOT/index.html with:

<meta http-equiv="refresh" content="0;url=/frontend"/>

Or you can use UrlRewriteFilter and configure it in /webapps/ROOT/WEB-INF/urlrewrite.xml

[jeroen]

I reapplied the 2.14 label... please reconsider this. This is a completely trivial change to do right now, but once we have dashboards in production that assume the login page is at / it will be much more troublesome to make these changes and perhaps never make it to the top of our priority queue again.

[jojenki]

It's not that this isn't a 2.14 issue as much as it's not a server or code-specific issue. This is at least a frontend issue if not a maintenance issue.

[jojenki]

If anyone knows how to do this in either a default web.xml (optimally) or the server.xml (alternatively), I would appreciate the information. I do not like the ROOT.war file that just contains a redirect.

[jeroen]

Judging from a quickly search and several stack overflow topics, I don't think tomcat supports this. That brings us back to tomcat not being a full blown webserver, but just a servlet container.

sent from my droid On Feb 15, 2013 1:37 PM, "John Jenkins" notifications@github.com wrote:

If anyone knows how to do this in either a default web.xml (optimally) or the server.xml (alternatively), I would appreciate the information. I do not like the ROOT.war file that just contains a redirect.

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageServer/issues/517#issuecomment-13629420.

[jojenki]

Several of us have been racking our brains trying things, but to no avail. It's disappointing. I like the idea of using a real web server (or even web stack) in front of Tomcat, but this just seems like such a basic thing that it should be able to be done.

[jeroen]

Perhaps we can use a root.war with a redirect as a temporary implementation until we decide on a better way to implement this. The ubuntu installation packages use the apache2 redirect directive which works great.

sent from my droid On Feb 15, 2013 2:37 PM, "John Jenkins" notifications@github.com wrote:

Several of us have been racking our brains trying things, but to no avail. It's disappointing. I like the idea of using a real web server (or even web stack) in front of Tomcat, but this just seems like such a basic thing that it should be able to be done.

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageServer/issues/517#issuecomment-13631950.

[jojenki]

A ROOT.war is the best solution and should be our "best practice" recommendation. We will pass it around internally for our installs.

@jeroenooms You may have this if you want it and, maybe, prompt the user to optionally install it. I would be very weary of automatically installing it, however. This is entirely a server administrator's domain and, they can use a ROOT.war or some server.xml/web.xml hackiness/magic or use a real web server. This is way outside of the purview of ohmage, both the server and the front end.

[jshslsky]

^^ agree with this.

The best version of a virtual host I could get working did the redirect, but still showed localhost:8080/ instead of localhost:8080/frontend in the address bar.

[jojenki]

It redirects to /web

http://web.ohmage.org/~jojenki/ROOT.war

[jeroen]

OK great thanks for looking into this.

Not to whine, but so the mount point of the frontend is going to be www.host.com/web? Is everyone OK with that? Shouldn't the path imply that this is app is related to ohmage or so, in order to distinguish it from other stuff hosted on the server? I.e. www.host.com/ohmageweb or www.host.com/ohmage?

On Fri, Feb 15, 2013 at 3:00 PM, John Jenkins notifications@github.comwrote:

http://web.ohmage.org/~jojenki/ROOT.war

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageServer/issues/517#issuecomment-13632794.

[jeroen]

Note that I will adopt whatever path we decide to use for the front-end in all dashboards and installation packages, so it will be a pretty strong convention.

On Fri, Feb 15, 2013 at 3:50 PM, Jeroen Ooms jeroenooms@gmail.com wrote:

OK great thanks for looking into this.

Not to whine, but so the mount point of the frontend is going to be www.host.com/web? Is everyone OK with that? Shouldn't the path imply that this is app is related to ohmage or so, in order to distinguish it from other stuff hosted on the server? I.e. www.host.com/ohmageweb or www.host.com/ohmage?

On Fri, Feb 15, 2013 at 3:00 PM, John Jenkins notifications@github.comwrote:

http://web.ohmage.org/~jojenki/ROOT.war

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageServer/issues/517#issuecomment-13632794.

[hongsudt]

I like www.host.com/web

On Fri, Feb 15, 2013 at 4:00 PM, Jeroen notifications@github.com wrote:

Note that I will adopt whatever path we decide to use for the front-end in all dashboards and installation packages, so it will be a pretty strong convention.

On Fri, Feb 15, 2013 at 3:50 PM, Jeroen Ooms jeroenooms@gmail.com wrote:

OK great thanks for looking into this.

Not to whine, but so the mount point of the frontend is going to be www.host.com/web? Is everyone OK with that? Shouldn't the path imply that this is app is related to ohmage or so, in order to distinguish it from other stuff hosted on the server? I.e. www.host.com/ohmageweb or www.host.com/ohmage?

On Fri, Feb 15, 2013 at 3:00 PM, John Jenkins notifications@github.comwrote:

http://web.ohmage.org/~jojenki/ROOT.war

— Reply to this email directly or view it on GitHub< https://github.com/cens/ohmageServer/issues/517#issuecomment-13632794>.

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageServer/issues/517#issuecomment-13635319.

[jojenki]

It was a Friday evening decision, and I didn't want another giant email thread about what the name should be. I pulled the trigger, and this is what we got. I will publish the code somewhere, so anyone who wants to change it can.

Hongsuda notifications@github.com wrote:

I like www.host.com/web

On Fri, Feb 15, 2013 at 4:00 PM, Jeroen notifications@github.com wrote:

Note that I will adopt whatever path we decide to use for the front-end in all dashboards and installation packages, so it will be a pretty strong convention.

On Fri, Feb 15, 2013 at 3:50 PM, Jeroen Ooms jeroenooms@gmail.com wrote:

OK great thanks for looking into this.

Not to whine, but so the mount point of the frontend is going to be www.host.com/web? Is everyone OK with that? Shouldn't the path imply that this is app is related to ohmage or so, in order to distinguish it from other stuff hosted on the server? I.e. www.host.com/ohmageweb or www.host.com/ohmage?

On Fri, Feb 15, 2013 at 3:00 PM, John Jenkins notifications@github.comwrote:

http://web.ohmage.org/~jojenki/ROOT.war

— Reply to this email directly or view it on GitHub< https://github.com/cens/ohmageServer/issues/517#issuecomment-13632794>.

— Reply to this email directly or view it on GitHubhttps://github.com/cens/ohmageServer/issues/517#issuecomment-13635319.

— Reply to this email directly or view it on GitHub.